Re: vCard and CardDAV strawman Charter

Cyrus Daboo <> Thu, 24 May 2007 02:23 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1Hr2yw-000427-5a; Wed, 23 May 2007 22:23:14 -0400
Received: from discuss by with local (Exim 4.43) id 1HqV8L-00082e-Nn for; Tue, 22 May 2007 10:14:41 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1HqV8L-00082W-EB for; Tue, 22 May 2007 10:14:41 -0400
Received: from ([] by with esmtp (Exim 4.43) id 1HqV8K-0001fI-TW for; Tue, 22 May 2007 10:14:41 -0400
Received: from ( []) (authenticated bits=0) by (8.13.6/8.13.6) with ESMTP id l4MEEX79013306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 May 2007 10:14:35 -0400
Date: Tue, 22 May 2007 10:14:27 -0400
From: Cyrus Daboo <>
To: Chris Newman <Chris.Newman@Sun.COM>,
Subject: Re: vCard and CardDAV strawman Charter
Message-ID: <>
In-Reply-To: <AFD8F8BC1C0185492E28E4AE@446E7922C82D299DB29D899F>
References: <AFD8F8BC1C0185492E28E4AE@446E7922C82D299DB29D899F>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.1
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 995b2e24d23b953c94bac5288c432399
X-Mailman-Approved-At: Wed, 23 May 2007 22:23:12 -0400
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Hi Chris,
Some comments:

- Yes I would very much like to see this effort happen.

--On May 20, 2007 3:57:10 PM -0700 Chris Newman <Chris.Newman@Sun.COM> 

> 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

Whilst I currently have limited time to work on the vCard revision as an 
autyhor, I do have an XML version of the original 2426 document for whoever 
wants to take this on.

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

I agree that rolling up all the new properties defined in RFCs into one 
document would be good. Also I think it would make sense to define an IANA 
registry for properties along the lines of what iCalendar has (is) doing.

There has also been some discussion about the lack of a "groups" facility 
in vCard - i.e. the ability to specify a distribution list that references 
other vCards in a list. Many PAB clients have the concept of a "group" of 
addresses, so I think formalizing something like that in vCard would be 
good too.

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

Some things to note:

- The latest CardDAV spec (-02) was just published. This now pretty much 
echoes exactly what is in the CalDAV Spec (RFC4791) and I was planning on 
asking for a last call on it soon.

- One thing did get removed from CardDAV in the last revision - the 
"synchronization" report feature. I removed this because a similar feature 
is also needed by CalDAV, and is arguably applicable to WebDAV as a whole. 
I was planning on writing that up as a separate spec (work under way). I 
would like to see such a specification also be dealt with by this group - I 
think it is in scope on the basis that it does touch on synchronization 
issues (and more specifically for deployment - performance).

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

Interesting. That is something that I had not considered in CardDAV. Though 
we do have something similar in CalDAV - the CALDAV:read-free-busy 
privilege which allows a user (WebDAV principal) to get busy time 
information on another user's calendar without actually exposing the 
underlying calendar data. We could do something similar here: define a new 
report that is used for verifying addresses, and a new WebDAV privilege to 
grant the right to run that report separately from the ability to read the 
content of an address book collection. That way, the third party service 
could be given a principal on the WebDAV server and the right to run that 
report only. I think that would cover this.

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

The jabber community already has a vCard<->XML spec that we could look at. 
I have to say that there has also been some renewed interest within the 
Calendaring and Scheduling Consortium to progress the iCalendar<->XML work 
too. Since the two formats are very close it would make sense to tackle 
both of these in the same way.

> * Identifying useful deployed vCard vendor extensions and creating
> standards
>   track versions of those extensions.

FYI There has been some recent discussion in Calconnect (the Calendaring 
and Scheduling Consortium) about doing some work on vCard. Obviously many 
people that do calendaring also do address books/contact information (in 
particular mobile device vendors) and many of the pain points in iCalendar 
synchronization also exist in vCard.

To that end Calconnect is considering supporting any vCard efforts in the 
same way it has supported iCalendar and related work (e.g. through 
production of recommendation documents, surveys, interoperability testing).

At present Calconnect is discussing the possibility of a one day vCard 
workshop to be held in conjunction with its next Roundtable meeting in 
Boston in September. Certainly if the IETF proceeds with this work, that 
would likely happen - but as with the WG, it really depends on enough 
interested parties coming to the table.

> * Cooperate with the Sieve WG to produce a Sieve extension for address
> book
>   Sieve tests.

In any case, I hope we can progress with this BOF and maybe WG too.

Cyrus Daboo