<abstract>This document specifies an XMPP extension for use of the vCard4 XML format in XMPP systems, with the intent of obsoleting the vcard-temp format.</abstract>
<remark><p>Updated to track base vCard4 specs; defined IQ transport, with pubsub for notifications; added examples for server vCards; specified mapping from vcard-temp.</p></remark>
<p>Since 1999, the Jabber/XMPP community has used an interim, unofficial XML representation of vCard data for personal contacts, called &xep0054;. Recently, the IETF has upgraded vCard from vCard3 to &vcardrev;, and at the same time has defined &vcardxml; as an official XML format for vCard4. This document specifies an XMPP extension for use of the vCard4 XML format in XMPP systems, with the intent of obsoleting the vcard-temp format. Primarily this document defines the encapsulation method itself; secondarily it also defines transport methods and a mapping to the vcard-temp format for migration by clients and servers.</p>
<p>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/>.</p>
<section1topic='IQ-Based Publication and Retrieval'anchor='iq'>
<p>As in <cite>XEP-0054</cite>, the primary method for publishing and retrieving vCards is the XMPP &IQ; stanza.</p>
<section2topic='Retrieval'anchor='iq-retrieval'>
<p>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.</p>
<p>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:</p>
<p>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.</p>
<p>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).</p>
</section2>
</section1>
<section1topic='Event Notifications'anchor='pep'>
<p>&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.</p>
<li>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.</li>
<li>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).</li>
<p>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.</p>
<section1topic='vCards of Automated Entities'anchor='things'>
<p>Traditionally, vCards have been used on the XMPP network for entities other than human users, e.g. by XMPP servers and chatrooms. When such automated entities use vCards, it is RECOMMENDED to specify a value of "thing" for the vCard4 KIND property &vcardthing;. An example follows.</p>
<section1topic='Mapping from vcard-temp to vCard4'anchor='mapping'>
<p>The following sections mention non-obvious aspects of the migration from vcard-temp to vCard4. A future version of this specification might provide a more detailed mapping.</p>
<p>However, the JABBERID field was not part of the vCard3 schema. &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.</p>
<examplecaption="IMPP property"><![CDATA[
<impp>
<uri>xmpp:stpeter@jabber.org</uri>
</impp>
]]></example>
</section2>
<section2topic='DESC'anchor='mapping-desc'>
<p>The vcard-temp specification defined a <DESC/> element. This element too was not part of the vCard3 schema. There is no mapping of the vcard-temp <DESC/> element to vCard4.</p>
<p>The vCard information published to one's XMPP server is world-readable; therefore, users should exercise due caution when determining what information to include (e.g., street addresses, personal telephone numbers, or email addresses).</p>
