XEP-0292: vCard4 Over XMPP

WARNING: This Standards-Track document is Experimental. Publication as an XMPP Extension Protocol does not imply approval of this proposal by the XMPP Standards Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems are advised to carefully consider whether it is appropriate to deploy implementations of this protocol before it advances to a status of Draft.

Table of Contents

1. Introduction

Since 1999, the Jabber/XMPP community has used an interim, unofficial XML representation of vCard data for personal contacts, called vcard-temp [1]. Recently, the IETF has upgraded vCard from vCard3 to vCard4 [2], and at the same time has defined vCard4 XML [3] 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.

2. Requirements

This specification was designed with the following documents in mind.

1. Reuse vCard4 as defined in draft-ietf-vcarddav-vcardrev.
2. Reuse the vCard4 XML format as defined in draft-ietf-vcarddav-vcardxml.
3. Ensure that clients and servers can easily migrate from vcard-temp to the new encapsulation format.
4. Notify interested parties of changes to vCard data using standard XMPP extensions, specifically Personal Eventing Protocol [4].
5. Enable XMPP servers to store vCard4 XML data in LDAP directories if desired.

3. XML Namespace

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

4. Encapsulation

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

5. PubSub Binding

<iq from='romeo@motague.lit/office
    id='v1'
    to='romeo@motague.lit'
    type='set'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='urn:ietf:param:xml:ns:vcard-4.0'>
      <item>
        <vcard xmlns="urn:ietf:params:xml:ns:vcard-4.0">
          <fn><text>Romeo Montague</text></fn>
          <n>
            <surname><text>Montague</text></surname>
            <given><text>Romeo</text></given>
            <additional/>
            <prefix>
              <text>Sir</text>
            </prefix>
            <suffix/>
          </n>
          <bday><date>--0203</date></bday>
          <anniversary>
            <date-time>15000808T1430-0500</date-time>
          </anniversary>
          <gender><text>male</text></gender>
          <org>
            <parameters><type>home</type></parameters>
            <text>Juliet</text>
          </org>
          <adr>
            <parameters><type>home</type></parameters>
            <pobox/>
            <ext/>
            <street><text>123 Capulet Way</text></street>
            <locality><text>Verona</text></locality>
            <region/>
            <code/>
            <country><text>Italy</text></country>
          </adr>
          <email>
            <parameters><type>work</type></parameters>
            <text>romeo@montague.lit</text>
          </email>
        </vcard>
      </item>
    </publish>
  </pubsub>
</iq>
    

<message from='romeo@montague.lit'
         to='juliet@capulet.lit'
         type='headline'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='urn:ietf:param:xml:ns:vcard-4.0'>
      <item id='foobar'>
        <vcard xmlns="urn:ietf:params:xml:ns:vcard-4.0">
          <fn><text>Romeo Montague</text></fn>
          <n>
            <surname><text>Montague</text></surname>
            <given><text>Romeo</text></given>
            <prefix>
              <text>Sir</text>
            <prefix/>
            <suffix/>
          </n>
          <bday><date>--0203</date></bday>
          <anniversary>
            <date-time>15000808T1430-0500</date-time>
          </anniversary>
          <gender><text>male</text></gender>
          <org>
            <parameters><type>home</type></parameters>
            <text>Juliet</text>
          </org>
          <adr>
            <parameters><type>home</type></parameters>
            <pobox/>
            <ext/>
            <street><text>123 Capulet Way</text></street>
            <locality><text>Verona</text></locality>
            <region/>
            <code/>
            <country><text>Italy</text></country>
          </adr>
          <email>
            <parameters><type>work</type></parameters>
            <text>romeo@montague.lit</text>
          </email>
        </vcard>
      </item>
    </items>
  </event>
</message>
    

<iq type='get'
    from='juliet@capulet.lit/castle'
    to='romeo@montague.lit'
    id='items1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <items node='urn:ietf:param:xml:ns:vcard-4.0'/>
  </pubsub>
</iq>
    

6. Security Considerations

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.

7. IANA Considerations

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

8. Open Issues

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.

9. Acknowledgements

Thanks to Joe Hildebrand, Waqas Hussain, and Matt Miller for their feedback.

Appendices

Appendix A: Document Information

Series: XEP
Number: 0292
Publisher: XMPP Standards Foundation
Status: Experimental
Type: Standards Track
Version: 0.1
Last Updated: 2011-03-02
Approving Body: XMPP Council
Dependencies: XMPP Core, draft-ietf-vcarddav-vcardrev, draft-ietf-vcarddav-vcardxml
Supersedes: XEP-0054
Superseded By: None
Short Name: NOT_YET_ASSIGNED
Source Control: HTML  RSS
This document in other formats: XML  PDF

Appendix B: Author Information

Appendix C: Legal Notices

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Appendix G: Notes

Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

END