Specified that PEP nodes SHOULD be persistent
An entity SHOULD use &xep0163; to publish all its long-term public keys via its own server.
-If the pubkeys PEP node does not exist already then the entity MUST create it first. In this case, the entity SHOULD specify that the keys will only be pushed to subscribers whenever new keys are published (i.e. not when subscribers become newly available or when a new subscription is created). If the user wants to control access to his/her identity (see Security Considerations) then the entity MUST also specify an appropriate access model other than "Open".
+If the pubkeys PEP node does not exist already then the entity MUST create it first. In this case, the entity SHOULD specify that items published to the node are persistent and that the keys will only be pushed to subscribers whenever new keys are published (i.e. not when subscribers become newly available or when a new subscription is created). If the user wants to control access to his/her identity (see Security Considerations) then the entity MUST also specify an appropriate access model other than "Open".
Once the publishing node has been created, the entity can update the keys at any time. Each public key MUST be wrapped in a <KeyInfo/> element as specified in &w3xmlsig;. Each <KeyInfo/> element MUST contain a <KeyName/> element with a unique (for the user) name to allow the key to be referenced by other protocols. All the <KeyInfo/> elements MUST be wrapped in a single <pubkeys/> element.
- Note: Any change to the list of keys requires all keys to be republished. So clients SHOULD take care to request (see third example below) and then include all keys for the JID that were published previously by other clients (unless the keys have expired).
...
...
...
...
The reliable association between a user or entity and its public keys is beyond the scope of this document. However, it is RECOMMENDED that each client maintains its own secure library of the public keys (or the "fingerprints" of the keys) it associates with other users (not necessarily JIDs).
+The reliable association between a user or entity and its public keys is beyond the scope of this document. However, each client SHOULD maintain its own secure library of the public keys (or the "fingerprints" of the keys) it associates with other users (not necessarily JIDs).
Whenever public keys are published an identity is typically associated with a JID. Although the public keys are public information, it may be critically important for the user of the JID to keep his identity secret from all but a few specified people. Implementors MUST take great care to ensure the identity of the user of a JID is never divulged to anyone except the entities who have been permitted by the user to access the public key.