vCard and CardDAV strawman Charter
Chris Newman <Chris.Newman@Sun.COM> Sun, 20 May 2007 22:57 UTC
Return-path: <discuss-bounces@apps.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpuL3-0006Qw-Iv; Sun, 20 May 2007 18:57:21 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HpuL1-0006Qj-Q6 for discuss-confirm+ok@megatron.ietf.org; Sun, 20 May 2007 18:57:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpuKz-0006Qb-Mp for discuss@apps.ietf.org; Sun, 20 May 2007 18:57:18 -0400
Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HpuKz-0004v3-9W for discuss@apps.ietf.org; Sun, 20 May 2007 18:57:17 -0400
Received: from fe-amer-10.sun.com ([192.18.108.184]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4KMvGK4010630 for <discuss@apps.ietf.org>; Sun, 20 May 2007 22:57:16 GMT
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JID00M013OH2E00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for discuss@apps.ietf.org; Sun, 20 May 2007 16:57:16 -0600 (MDT)
Received: from [10.0.1.21] (216-165-236-126.championbroadband.com [216.165.236.126]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JID00D933RD4H00@mail-amer.sun.com>; Sun, 20 May 2007 16:57:16 -0600 (MDT)
Date: Sun, 20 May 2007 15:57:10 -0700
From: Chris Newman <Chris.Newman@Sun.COM>
Subject: vCard and CardDAV strawman Charter
To: discuss@apps.ietf.org
Message-id: <AFD8F8BC1C0185492E28E4AE@446E7922C82D299DB29D899F>
MIME-version: 1.0
X-Mailer: Mulberry/3.1.6 (Mac OS X)
Content-type: text/plain; format="flowed"; charset="us-ascii"
Content-transfer-encoding: 7bit
Content-disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
Cc: Cyrus Daboo <cyrus@daboo.name>
X-BeenThere: discuss@apps.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <discuss.apps.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@apps.ietf.org>
List-Help: <mailto:discuss-request@apps.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=subscribe>
Errors-To: discuss-bounces@apps.ietf.org
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. -----
- Re: vCard and CardDAV strawman Charter Cyrus Daboo
- vCard and CardDAV strawman Charter Chris Newman
- Re: vCard and CardDAV strawman Charter Julian Reschke
- Re: vCard and CardDAV strawman Charter Cyrus Daboo
- Re: vCard and CardDAV strawman Charter Julian Reschke
- Re: vCard and CardDAV strawman Charter Julian Reschke