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).

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:

1. Implicitly subscribe by advertising support for "urn:xmpp:vcard4+notify" in her &xep0115; data. Romeo's PEP service then automatically sends vCard updates to her when it receives presence from her, until and unless she sends presence of type unavailable or stops advertising an interest in vCard updates. This is in accordance with XEP-0060, section 6.1.
2. Explicitly subscribe by sending a formal subscription request to the "urn:xmpp:vcard4" node at Romeo's JabberID. Romeo's PEP service may send her all vCard updates even if she is offline at the time (depending on service policies regarding presence integration).

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.

Several of the properties in vcard-temp are defined differently in vCard3. In fact, the definitions even differ from those provisionally made in the so-called "Dawson drafts" from which vcard-temp was supposedly derived (for reference, the last of these is archived at <http://www.watersprings.org/pub/id/draft-dawson-vcard-xml-dtd-03.txt>). The reasons for these discrepancies are unknown. However, care must be taken in correctly mapping these properties from vcard-temp to vCard4.

The following properties are defined differently in vcard-temp and vCard4. As a result, the mappings are workable but might not preserve all information that could have been contained in vcard-temp data.

The following properties are defined similarly in vcard-temp, vCard3, and vCard4, and the mappings are fairly straightforward (a future version of this document might provide more detailed narrative descriptions of the mappings).

• BDAY
• CATEGORIES
• EMAIL
• FN
• GEO
• LOGO
• N
• NICKNAME
• NOTE
• PHOTO
• PRODID
• REV
• ROLE
• TITLE
• TZ
• UID
• URL

The following properties were defined in vCard3 but were removed from vCard4:

• CLASS
• LABEL
• MAILER

There is no mapping from these properties to vCard4.