vCard and CardDAV strawman Charter

[Chris Newman <[e-mail]>]

Given the upcoming BOF deadline, I wanted to get this proposal circulating now.

I've had several people contact me interested in work on vCard and CardDAV.  So 
I'm contemplating a BOF on the topic at the Chicago IETF.  I'm interested in 
volunteers for the following roles:

1. BOF chair / co-chair (responsible for charter editing and running a BOF)
2. WG chair / co-chair (responsible for running the WG)
3. vCard revision document editor

Volunteers for 1 & 2 may be the same or different people.  A BOF will not 
happen unless I get volunteers to do the work.

I've written a first strawman for the charter to get discussion going (very 
much subject to change).

                - Chris Newman
                Applications Area Director

---
vCard and CardDAV strawman charter (vcarddav)

A personal address book (PAB) contains a read/write copy of attributes 
describing a user's interpersonal contacts.  This is distinct from a directory 
which contains a primarily read-only copy of users within an organization. 
While these two data objects share a large number of common attributes, their 
use and access patterns are fundamentally different.  The IETF has a 
standards-track data format (vCard) which has been successfully used to 
interchange both personal-address-book and user directory entry data objects. 
However, due to the lack of a standard access control model for LDAP, the lack 
of a standard LDAP schema and DIT-model for vCard PAB objects, and the 
different access patterns for PAB data (as opposed to directory data), the use 
of LDAP as an access protocol for PABs has had mixed results in practice.

If the deployed protocols related to interpersonal communication are viewed as 
a component-based system, there are a number of points in the system that would 
benefit from a standards track access protocol for personal address book data. 
This includes:

* Mail User Agents use PAB data to assist outgoing email addressing and may
  use vCard attachments to transport PAB data between users.
* Calendar User Agents use PAB data to invite attendees to events
* Instant Messaging User Agents can provide additional information about
  a user's buddies if they can be associated with a user's PAB entry.
* A server-side Sieve engine with the spamtest/virustest extension would
  benefit from access to a user's PAB to provide per-user white list
  capabilities.
* Various deployed challenge-response mechanisms for email present
  in Mail Transfer Agents, such as TMDA, would be improved by a PAB-based
  white list.
* Mobile device synchronization software might be simplified by a
  single cross-platform PAB access protocol.
* A voice conference or IP telephony system could access a user's PAB to
  provide name-based or nickname-based dialing.

This WG will produce the following two primary outputs:

* A revision of the vCard spec (RFC 2426) likely at proposed standard
  status.  The WG will attempt to avoid adding new features, with two
  exceptions: 1. The WG may consider including other proposed standard vCard
  extensions (e.g., RFC 4770, RFC 2739).  2. The WG may evaluate extensions
  that would assist synchronization technologies (for example, a per-entry
  UUID or per-attribute sequence number).
* An address book access protocol leveraging the vCard data format.  The
  Internet-draft draft-daboo-carddav will be the starting point.
  The WG is explicitly cautioned to keep the base specification feature set
  small with an adequate extension mechanism, as failure to do so was a
  problem for previous PAB efforts (ACAP).  The WG will consider arguments
  of the form "feature X must be in the base feature set because ..."
  with great skepticism.

These documents will consider security implications carefully.  The WG will 
consider developing a mechanism that provides the ability to check if an email 
address (or im address, etc) is in the user's PAB without providing 
unrestricted access to all of the user's PAB data.  The WG should also consider 
developing a mechanism that allows the user to grant this limited permission to 
a third-party service (such as a server-based Sieve engine) for white-list 
purposes.

Once the primary outputs are complete, the WG may consider the following 
secondary outputs:

* An XML schema which is semantically identical to vCard in all ways and can
  be mechanically translated to and from vCard format without loss of data.
  While vCard has deployed successfully and will remain the preferred
  interchange format, a standard XML schema which preserves vCard semantics
  might make vCard data more accessible to XML-centric technologies such as
  AJAX and XSLT.  Such a standard format would be preferable to multiple
  proprietary XML schemas, particularly if vCard semantics were lost by some
  of them and a lossy gateway problem resulted.
* Identifying useful deployed vCard vendor extensions and creating standards
  track versions of those extensions.
* Cooperate with the Sieve WG to produce a Sieve extension for address book
  Sieve tests.
-----