Subject: vCard and CardDAV strawman Charter

From: Chris Newman <[email-masked]>
Date: Sun, 20 May 2007 15:57:10 -0700

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

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 22 May 2007 10:14:27 -0400

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 <[email-masked]> 
wrote:

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

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.

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

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.

>   of the form "feature X must be in the base feature set because ..."

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.

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

>   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

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

-- 
Cyrus Daboo

---

From: Julian Reschke <[email-masked]>
Date: Thu, 24 May 2007 10:45:18 +0200

Cyrus Daboo wrote:
> 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.

That registry exists at 
<http://www.iana.org/assignments/text-directory-registrations>; a 
revision of RFC2425 probably should cite that.

> echoes exactly what is in the CalDAV Spec (RFC4791) and I was planning 
> on asking for a last call on it soon.
> 
> "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).

Having that stand-alone sounds right, please do it on the former WebDAV 
WG's mailing list...

 > ...

Best regards, Julian

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 24 May 2007 10:09:59 -0400

Hi Julian,

> revision of RFC2425 probably should cite that.

Hrmm - well that registry does not reference the vCard spec 2426, and 2426 
does not reference it (as you noted). Also the IANA registry is not 
populated with the registrations defined in 2425 itself, and it ought to 
include the items defined in 2426 too. So something definitely needs to be 
fixed.

Also, in CardDAV I used the MIME type text/vcard - but I note that does is 
not the registered type. Instead 'text/directory; profile=vcard' is. 
However, I am pretty sure I have seen text/vcard being used in email - it 
may be we want to register that too as part of vcard-bis.

I also question the utility of text/directory these days. It seems that the 
only thing that actually uses it is vCard. Does it still make sense to have 
that as a separate document, or should it be rolled up into the vCard-bis 
effort? At the very least it may be that 2425 needs some updating as well 
and should be something we discuss at the BOF and potentially include in 
the charter.

> Having that stand-alone sounds right, please do it on the former WebDAV

Whilst this is a "generic" WebDAV extension, both CalDAV and CardDAV really 
need it, so I would like to see this be part of the work items for the 
proposed working group if it gets going.

-- 
Cyrus Daboo

---

From: Julian Reschke <[email-masked]>
Date: Fri, 25 May 2007 14:10:40 +0200

Cyrus Daboo wrote:
> Also, in CardDAV I used the MIME type text/vcard - but I note that does 
> is not the registered type. Instead 'text/directory; profile=vcard' is. 
> However, I am pretty sure I have seen text/vcard being used in email - 
> it may be we want to register that too as part of vcard-bis.

Interesting. Of course I do agree that whatever gets used should be 
registered. Do we have any evidence that 'text/directory; profile=vcard' 
doesn't work in practice?

> I also question the utility of text/directory these days. It seems that 
> the only thing that actually uses it is vCard. Does it still make sense 
> to have that as a separate document, or should it be rolled up into the 
> vCard-bis effort? At the very least it may be that 2425 needs some 
> updating as well and should be something we discuss at the BOF and 
> potentially include in the charter.

Probably true.

> Whilst this is a "generic" WebDAV extension, both CalDAV and CardDAV 
> really need it, so I would like to see this be part of the work items 
> for the proposed working group if it gets going.

It's fine to have it as a work item, but it still may make sense to use 
the more generic mailing list for it (that's what it's for after all).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 25 May 2007 14:31:05 +0200

Julian Reschke wrote:
> Cyrus Daboo wrote:
>> Also, in CardDAV I used the MIME type text/vcard - but I note that 
>> does is not the registered type. Instead 'text/directory; 
>> profile=vcard' is. However, I am pretty sure I have seen text/vcard 
>> being used in email - it may be we want to register that too as part 
>> of vcard-bis.
> 

Speaking of which, it seems that what is in common use is "text/x-vcard" 
- unregistered as well.

So yes, the media type issue probably should be in the WG's charter.

Best regards, Julian