%ents; ]>
vCard4 Over XMPP 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. &LEGALNOTICE; xxxx ProtoXEP Standards Track Standards Council XMPP Core draft-ietf-vcarddav-vcardrev draft-ietf-vcarddav-vcardxml XEP-0054 NOT_YET_ASSIGNED Samantha Mizzi samizzi@cisco.com samizzi@cisco.com &stpeter; 0.0.3 2011-02-12 psa

Third draft.

 0.0.2 2011-01-31 srm

Second draft.

 0.0.1 2010-11-30 srm

First draft.

Since 1999, the Jabber/XMPP community has used an interim, unofficial XML representation of vCard data for personal contacts. Recently, the IETF has upgraded vCard from version 3 to version 4, and at the same time has defined 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.

This specification was designed with the following documents in mind.

  1. Reuse vCard4 as defined in &vcardrev;.
  2. Reuse the vCard4 XML format as defined in &vcardxml;.
  3. Ensure that clients and servers can easily migrate from &xep0054; to the new encapsulation format.
  4. Notify interested parties of changes to vCard data using standard XMPP extensions, specifically &xep0163;.
  5. Enable XMPP servers to store vCard4 XML data in LDAP directories if desired.

Because there is now an XML namespace for the official vCard format, we can simply re-use that namespace: "urn:ietf:params:xml:ns:vcard-4.0".

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

When the &xep0163; "flavor" of XMPP publish-subscribe is used, the canonical location for a user's vCard is a pubsub node whose name is "urn:ietf:params:xml:ns:vcard-4.0". For instance, if the Shakespearean character Romeo has a JabberID of 'romeo@montague.lit' then his vCard would be located at that JID with a node of "urn:ietf:params:xml:ns:vcard-4.0".

When "raw" &xep0060; is used, the location is a generic publish-subscribe node that is not attached to an user's IM account.

Use of PEP is RECOMMENDED to simplify the process of discovering and subscribing to the vCard information.

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:ietf:param:xml:ns:vcard-4.0+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:ietf:param:xml:ns:vcard-4.0" 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).

Romeo can publish/update a vCard via XMPP pubsub. Currently there is no method for partial updates of a vCard, and the entire vCard must be sent to the server in order to update any part of the vCard. Publish-subscribe is done in accordance with XEP-0060, section 7.1.

Romeo Montague Montague Romeo Sir --0203 15000808T1430-0500 0 love Juliet love 123 Capulet Way Verona Italy work romeo@montague.lit PUBLIC 2010-11-08T18:30:02Z 2010-11-08T18:30:02Z ]]>

Because Juliet has sent presence to Romeo including Entity Capabilities data that encapsulates the "urn:ietf:param:xml:ns:vcard-4.0+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.

Romeo Montague Montague Romeo Sir --0203 15000808T1430-0500 0 love Juliet love 123 Capulet Way Verona Italy work romeo@montague.lit PUBLIC 2010-05-08T18:30:02Z 2010-05-08T18:30:02Z ]]>

Implementations of pubsub that choose to persist items MAY allow entities to request existing items from a node (e.g., an entity may wish to do this after successfully subscribing in order to receive all the items in the publishing history for the node). This is in accordance with XEP-0060, section 6.5. The subscriber may request all items by specifying only the Node ID without restrictions.

]]>

  1. 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).
  2. There are security considerations around XEP-0060, please see section 14.
  3. There are security considerations around XEP-0115, please see section 9.
  4. There are security considerations around XEP-0163, please see section 8.

This document does not require interaction with the Internet Assigned Numbers Authority (IANA) [35]

The following open issues are yet to be addressed:

  1. Do we need to define an IQ binding as in XEP-0054?
  2. The mapping from XEP-0054 to vCard4 is not yet specified.
  3. It would be helpful to provide an XSLT for automated translation of vcard-temp to vCard4.