diff --git a/xep-0292.xml b/xep-0292.xml
index d42910c9..2532bff9 100644
--- a/xep-0292.xml
+++ b/xep-0292.xml
@@ -31,6 +31,12 @@
Described how to use the vCard format for storing private data about one's contacts; added XMPP Registrar considerations. The vCard XML format defined at the IETF specifies that the root element is <vcards/>, where the only defined child element is <vcard/>. For use in XMPP, we specify that the root element shall be <vcard/>, not <vcards/>. As in XEP-0054, the primary method for publishing and retrieving vCards is the XMPP &IQ; stanza. An XMPP entity retrieves the vCard of another entity (or itself) by sending an IQ-get to the target entity containing a <vcard/> child element (note the lowercase "c"!) qualified by the 'urn:ietf:params:xml:ns:vcard-4.0' namespace. If a vCard exists for the target entity, the responsible entity (e.g., the XMPP server that hosts the account for a bare JID) MUST return the data in an IQ-result: If no vCard exists, the server MUST return an IQ-result containing an empty <vcard/> element. This section describes the use of the vCard format for self-publication and retrieval of publicly-accessible information about any entity on an XMPP network, thus fulfilling all the use cases of the old vcard-temp format. As in XEP-0054, the primary method for publishing and retrieving vCards is the XMPP &IQ; stanza. (Although it would have been possible to use &xep0222; for public storage and retrieval, community consensus is that storage via IQ is more backward-compatible with XEP-0054, and that publish-subscribe is more appropriate only for event notifications.) An XMPP entity retrieves the vCard of another entity (or itself) by sending an IQ-get to the target entity containing a <vcard/> child element (note the lowercase "c"!) qualified by the 'urn:ietf:params:xml:ns:vcard-4.0' namespace. If a vCard exists for the target entity, the responsible entity (e.g., the XMPP server that hosts the account for a bare JID) MUST return the data in an IQ-result: If no vCard exists, the server MUST return an IQ-result containing an empty <vcard/> element. An XMPP entity publishes or updates its vCard by sending an IQ-set to itself, containing a <vcard/> child element qualified by the 'urn:ietf:params:xml:ns:vcard-4.0' namespace. The publication request needs to include the entire vCard, not a "diff" against the prior data (if any). If no error occurs, the responsible entity returns an IQ-result. Note: An entity MAY have authorization to update the vCard of another entity (e.g., a server administrator might have authorization to modify the server's vCard). An XMPP entity publishes or updates its vCard by sending an IQ-set to itself, containing a <vcard/> child element qualified by the 'urn:ietf:params:xml:ns:vcard-4.0' namespace. The publication request needs to include the entire vCard, not a "diff" against the prior data (if any). If no error occurs, the responsible entity returns an IQ-result. Note: An entity MAY have authorization to update the vCard of another entity (e.g., a server administrator might have authorization to modify the server's vCard). &xep0060; provides a way to subscribe to events, and &xep0163; defines a pubsub profile for events associated with instant messaging (IM) accounts. If PEP is supported by an IM server, it can be used to automatically generate event notifications when a user's vCard is modified. The canonical location for notifications regarding a user's vCard is a pubsub node whose name is "urn:xmpp:vcard4". Let us imagine that Juliet wishes to receive the updates that Romeo publishes to his vCard. She has two options:
+ 80202
- 80210
- 80202
+ 80210
+
+
+
Because Juliet has sent presence to Romeo including Entity Capabilities data that includes the "urn:xmpp:vcard4+notify" feature, Romeo's XMPP server will send a PEP notification to Juliet. The notification can include an XMPP message body for backwards-compatibility with XMPP clients that are not pubsub-capable (see Message Body). This is in accordance with XEP-0060, second 6.1.7.
+Note: There is no payload, because this is a pure notification (the receiver needs to retrieve the vCard using an IQ-get as described earlier.
+&xep0060; provides a way to subscribe to events, and &xep0163; defines a pubsub profile for events associated with instant messaging (IM) accounts. If PEP is supported by an IM server, it can be used to automatically generate event notifications when a user's vCard is modified.
-The canonical location for notifications regarding a user's vCard is a pubsub node whose name is "urn:xmpp:vcard4".
+In addition to enabling the publication and retrieval of vCards about any entity on an XMPP network, the vCard format can also be used to store information about an entity's contacts.
+ +A contact is simply a vCard about someone else (or something else, in the case of automated entities). If the other person or entity is in the user's roster &rfc6121;, the vCard SHOULD contain the Jabber ID of the person or entity. This enables a user to store information about the contact outside of the roster, thus obviating the need for changes or extensions to the roster namespace itself (as in &xep0145;).
+Let us imagine that Juliet wishes to receive the updates that Romeo publishes to his vCard. She has two options: -
Because Juliet has sent presence to Romeo including Entity Capabilities data that includes the "urn:xmpp:vcard4+notify" feature, Romeo's XMPP server will send a PEP notification to Juliet. The notification can include an XMPP message body for backwards-compatibility with XMPP clients that are not pubsub-capable (see Message Body). This is in accordance with XEP-0060, second 6.1.7.
-Because contact vCards are private information, they are best stored using &xep0223;. The canonical location is a well-known pubsub node "urn:xmpp:contacts". In accordance with XEP-0223, this node MUST have an access type of "whitelist" by default. When a client stores items at this node, it SHOULD NOT include an ItemID, so that the pubsub service can assign those identifiers.
+When a contact's vCard is stored in a private node, it is pushed out to all of the user's resources that have included in their entity capabilities (XEP-0115) data a service discovery feature of "urn:xmpp:contacts+notify" (in the following example those resources are "squire" and "roundabout").
+Note: There is no payload, because this is a pure notification (the receiver needs to retrieve the vCard using an IQ-get as described earlier.
This document does not require interaction with &IANA;.
The ®ISTRAR; shall include 'urn:xmpp:contact' in its registry of Nodes for Service Discovery and Publish-Subscribe at &NODES;.
+This section provides a more detailed description of mapping vcard-temp properties to vcard4 properties.