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 (typically its bare JID), 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 might 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 backward-compatibility with XMPP clients that are not pubsub-capable. 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).

The vcard-temp specification defined a <DESC/> element. This element was not part of the vCard3 schema. Mapping the vcard-temp <DESC/> element to the vCard4 NOTE property is appropriate.

The vcard-temp specification defined a <JABBERID/> element:

Although the JABBERID field was not part of the vCard3 schema and was simply hacked into vcard-temp, &rfc4770; defined an IMPP property for instant messaging and presence addresses, which was ported to vCard4. In the vCard4 XML format, the IMPP property for a JabberID would be as follows.

The vcard-temp specification defined a <MIDDLE/> element as the third allowable element within the <N/> ("name") element. This element was not part of the vCard3 schema, although the Dawson drafts did contain an <other/> element in the third position of child elements within the <n/> element. It is appropriate to map the vcard-temp <MIDDLE/> element to the vCard4 "Additional Name" part of the "N" structured property value, which in xCard is the <additional/> child of the <n/> element.

The DTD in XEP-0054 provided this definition for the KEY element:

However, the DTD in the final Dawson draft provided the following definition:

The relevant RelaxNG definition in vCard4 XML is as follows:

The source of the spurious <TYPE/> and <CRED/> elements is unknown. The vcard-temp <CRED/> element is mapped to the vCard4 value-text construction.

The DTD in XEP-0054 provided this definition for the SOUND element:

However, the DTD in the final Dawson draft provided the following definition:

The source of the spurious vcard-temp <PHONETIC/> element is unknown. However, it does not exist in vCard4 and therefore is simply discarded when mapping. The vcard-temp <BINVAL/> element is mapped to the vCard4 b64bin construction and the vcard-temp <EXTVAL/> element is mapped to the vCard4 extref construction.

As explained in XEP-0054, the <VERSION/> element from the final Dawson draft was not used in vcard-temp; instead, the vcard-temp protocol used a 'version' attribute (in fact the Dawson drafts were inconsistent, since the DTD defined a <VERSION/> element and the body of the specification used a 'version' attribute).

The following address type values allowed in vCard3 were removed from vCard4:

• DOM
• INTL
• PARCEL
• POSTAL

In vCard3 and vcard-temp, the AGENT property was allowed to contain the inline vCard of someone who could act as an agent for the primary owner of the referenced vCard. In vCard4, inline vCards are disallowed. Therefore only pointers to external vCard objects are now allowed, by means of a URI.

The ORGUNIT property was removed from vCard4, with the result that the ORGNAME property becomes the only child of ORG.

The SORT-STRING property from vCard3 was renamed to SORT-AS in vCard4.

The following telephony type values allowed in vCard3 were removed from vCard4:

• BBS
• ISDN
• MODEM
• MSG
• PCS

In addition, in vCard4 the telephone number is represented as a tel: URI, not by means of a NUMBER property.