XEP-: VCard4 over XMPP

Abstract:This specification defines an XMPP protocol extension for sharing vcards between users. The protocol enables users to publish their vcard, share it with other users, and query other users for their vcard. The vcard is supporting a fine grained privacy extension: users can assign access control rules on a field per field basis. In addition, users can delegate write access rights to elements of their vcard to other entities. This protocol aims at providing a flexible platform for social profile management in a decentralized social network, thus enabling all social network use cases related to user profiles. This extension is part of the OneSocialWeb suite of XMPP extensions. The xml data model for vcards is based on the upcoming vcarddav-vcardxml standard (also known as vcard4).
Author:Laurent Eschenauer
Copyright:© 2010 Vodafone Group R&D.
Status:
Type:
Version:0.2
Last Updated:2010-04-09


Table of Contents


1. Introduction
    1.1. Overview
2. Requirements
3. Glossary
4. Publisher Use Cases
    4.1. Publish Profile
    4.2. User add or update fields to his vcard
    4.3. Entity removes fields from its vcard
5. Reader Use Cases
    5.1. Query VCard
6. Application Use Cases
7. Data Model
    7.1. Implementation details
    7.2. Extensions
       7.2.1. Access control
8. Business Rules
9. Implementation Notes
10. Accessibility Considerations
11. Internationalization Considerations
12. Security Considerations
13. IANA Considerations
14. XMPP Registrar Considerations
15. XML Schema

Appendices
    A: Document Information
    B: Author Information
    C: Legal Notices
    D: Relation to XMPP
    E: Discussion Venue
    F: Requirements Conformance
    G: Notes
    H: Revision History


1. Introduction

1.1 Overview

The XMPP Extension defined in this document is part of a collection of XMPP extensions that forms the OneSocialWeb (OSW) protocol. The purpose of the OneSocialWeb protocol is to enable free, open, and decentralized social applications on the web. In particular, this protocol can be used to turn any XMPP server into a full fledged social network, participating in the OneSocialWeb federation. The suite of extension covers all the usual social networking use cases such as user profiles, relationships, activity streams and third party applications. In addition, it provides support for fine grained access control, realtime notification and collaboration.

The vCard4 extension defined in this document addresses the requirement for publishing, sharing, and retrieving a user social profile (expressed in vcard). By profile, we mean a document describing an entity with details such as name, birthday, address, avatar picture, but also things like favorite movies, latest location, or in fact any other attribute that a user would like to have in its profile.

The data model used in this extension is vcard, and in particular its XML representation, as described in the ongoing IETF work on vcard-xml. [1].

This protocol fills similar needs than the VCard (XEP-0054) currently in use by most Jabber/XMPP servers. However it also represents a major evolution by supporting vcard extensions, fine grained privacy, select queries and merging of vcards.

2. Requirements

STRONGLY RECOMMENDED.

3. Glossary

OPTIONAL.

4. Publisher Use Cases

This section defines the use cases for and protocols to be used by any entity that wishes to manipulate its own profile, stored at its server. In particular to create and update its whole profile or a specific field in its profile.

4.1 Publish Profile

An entity can publish its profile (and thus overwrite any previously published profile) by sending an IQ-set to the bare domain containing a <publish/> element with a <vcard/> child. The vcard syntax should conform to the data model.

In the following example, <hamlet@denmark.lit> wants to publish his vcard. It consists of a fullname, the url of his photo, his birthdate, and a short bio. He uses his favorite xmmp client and publishes the following:

Example 1. User publishes his vcard

<iq type='set'
    from='hamlet@denmark.lit/client'
    to='denmark.lit'
    id='id1'>
  <publish xmlns="http://onesocialweb.org/spec/1.0/vcard4#publish">
    <vcard xmlns="urn:ietf:params:xml:ns:vcard-4.0">
      <fn>
        <text>Lord Hamlet</text>
        <acl-rule xmlns="http://onesocialweb.org/spec/1.0/">
          <acl-action permission="http://onesocialweb.org/spec/1.0/acl/permission/grant">
            http://onesocialweb.org/spec/1.0/acl/action/view
          </acl-action>
          <acl-subject type="http://onesocialweb.org/spec/1.0/acl/subject/everyone"/>
        </acl-rule>
      </fn>
      <photo>
        <uri>http://denmark.lit/hamlet.jpg</uri>
      </photo>
      <note>
        <text>Philosopher, dreamer, writer...</text>
      </note>
    </vcard>
  </publish>
</iq>

    

4.2 User add or update fields to his vcard

An entity can add or update fields to its vcard by sending an IQ-set to the bare domain containing a <merge/> element with a <vcard/> child. All fields of this new vcard will be merged in the existing one following the vcard merging strategy. [2]

Example 2. Entity add a fields to its profile and updates another one

<iq type='set'
    from='hamlet@denmark.lit/snsclient'
    to='denmark.lit'
    id='osw2'>
  <merge xmlns="http://onesocialweb.org/spec/1.0/vcard4#merge">
    <vcard xmlns="urn:ietf:params:xml:ns:vcard-4.0">
      <fn>
        <text>THE Lord Hamlet</text>
        <acl-rule xmlns="http://onesocialweb.org/spec/1.0/">
          <acl-action permission="http://onesocialweb.org/spec/1.0/acl/permission/grant">
            http://onesocialweb.org/spec/1.0/acl/action/view
          </acl-action>
          <acl-subject type="http://onesocialweb.org/spec/1.0/acl/subject/everyone"/>
        </acl-rule>
      </fn>
      <birthday>
        <datetime>1850-04-06T21:23:00-07:00</datetime>
        <acl-rule xmlns="http://onesocialweb.org/spec/1.0/">
          <acl-action permission="http://onesocialweb.org/spec/1.0/acl/permission/grant">
            http://onesocialweb.org/spec/1.0/acl/action/view
          </acl-action>
          <acl-subject type="http://onesocialweb.org/spec/1.0/acl/subject/group">Friends</acl-subject>
        </acl-rule>
      </birthday>
    </vcard>
  </merge>
</iq>

    

In this example, Hamlet is adding a birthday field and updating his full name.

4.3 Entity removes fields from its vcard

An entity can delete fields from its profile by sending an IQ-set to the bare domain containing a <remove/> element with a <vcard/> child. Every field, from the submitted vcard, that can be uniquely identified, will be deleted.

Example 3. Entity remove a field from its profile

<iq type='set'
    from='hamlet@denmark.lit/snsclient'
    to='denmark.lit'
    id='osw4'>
  <remove xmlns="http://onesocialweb.org/spec/1.0/vcard4#remove">
    <vcard xmlns="urn:ietf:params:xml:ns:vcard-4.0">
      <birthday />
    </vcard>
  </delete>
</iq>

    

5. Reader Use Cases

This section defines the use cases for and protocols to be used by any entity that wishes to query the vcard of another entity. In all of the following use cases, the server MUST comply with the privacy settings attached to the fields populating the vcard of the target entity.

5.1 Query VCard

An entity can query the vcard of another entity by sending an IQ-get to the bare JID of the target entity containing a <query/> element. The server replies to this request with a vcard containing all the fields that the requesting entity is allowed to see.

It should be noted that:

In the following example, <romeo@montague.lit> wants to check the profile of <juliet@capulet.lit> to better understand who is this girl that everyone is talking about. He opens his prefered xmpp client and types in Juliet's identifier in the navigation box. The client query for the vcard with the following request:

Example 4. User Query for VCard

<iq type='get'
    from='romeo@montague.lit/orchard'
    to='juliet@capulet.lit'
    id='osw2'>
  <query xmlns="http://onesocialweb.org/spec/1.0/vcard4#query">
  </query>
</iq>

To which Juliet's server replies with a vcard containing all fields that Romeo is allowed to see:

Example 5. Server Reply to vcard Query

<iq type='result'
    from='juliet@capulet.lit' 
    to='romeo@montague.lit/orchard'>
  <query xmlns="http://onesocialweb.org/spec/1.0/vcard4#query">
    <vcard xmlns="urn:ietf:params:xml:ns:vcard-4.0">
      <fn>
        <text>Juliet Capulet</text>
      </fn>
      <photo>
        <uri>http://capulet.lit/juliet.jpg</uri>
      </photo>
      <note>
        <text>Lonely girl,looking for love !</text>
      </note>
    </vcard>
  </query>
</iq>

6. Application Use Cases

This section defines the use cases for and protocols to be used by any third party application that wishes to add/modify/delete fields of a vcard on behalf of a user. For example, a user could authorize the <robot@geolocator.com/> entity to update its <location/> field.

//TODO: I wonder if this should be here, or managed at a more higher level (a broad delegation framework ?). Well.. we are far from tackling these problems anyway.

7. Data Model

The data model used is vcard xml. We precise here some implementation details and extensions.

7.1 Implementation details

To simplify parsing and formating of timestamp, DataTime constructs are always Atom compatible constructs, as specified in RFC 4287 [3]

We leverage the extensibility of the vcard-xml model to add <acl-rule/> elements to a field, describing the visibility of the field to other users in the network.

7.2 Extensions

7.2.1 Access control

The access control element used in this specification is described in a separate document.

8. Business Rules

OPTIONAL.

9. Implementation Notes

OPTIONAL.

10. Accessibility Considerations

OPTIONAL.

11. Internationalization Considerations

OPTIONAL.

12. Security Considerations

REQUIRED.

13. IANA Considerations

REQUIRED.

14. XMPP Registrar Considerations

REQUIRED.

15. XML Schema

REQUIRED for protocol specifications.


Appendices


Appendix A: Document Information

Series: XEP
Number:
Publisher: XMPP Standards Foundation
Status:
Type:
Version: 0.2
Last Updated: 2010-04-09
Approving Body: XMPP Council
Dependencies: XMPP Core, XEP-0030, XEP-0059
Supersedes: XEP-0054
Superseded By: None
Short Name: NOT_YET_ASSIGNED
Source Control: HTML  RSS


Appendix B: Author Information

Laurent Eschenauer

Email: laurent.eschenauer@vodafone.com
JabberID:


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

1. The latest draft being available at <http://tools.ietf.org/html/draft-ietf-vcarddav-vcardxml-02>.

2. Detailed in <http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-09#section-7>

3. RFC 4287: The Atom Syndication Format <http://tools.ietf.org/html/rfc4287>.


Appendix H: Revision History

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

Version 0.2 (2010-04-09)

Evolved to vCard4.

(le)

Version 0.1 (2010-01-25)

First draft.

(le)

END