WG Action: vCard and vCardDAV (vcarddav)
IESG Secretary <iesg-secretary@ietf.org> Thu, 31 January 2008 15:15 UTC
Return-path: <ietf-announce-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKb85-00066l-7u; Thu, 31 Jan 2008 10:15:05 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKb83-00064v-74; Thu, 31 Jan 2008 10:15:03 -0500
Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKb82-0007oM-DD; Thu, 31 Jan 2008 10:15:02 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 3657A26E69; Thu, 31 Jan 2008 15:15:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JKb82-00033W-49; Thu, 31 Jan 2008 10:15:02 -0500
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
To: ietf-announce@ietf.org
From: IESG Secretary <iesg-secretary@ietf.org>
Message-Id: <E1JKb82-00033W-49@stiedprstage1.ietf.org>
Date: Thu, 31 Jan 2008 10:15:02 -0500
X-Spam-Score: -1.4 (-)
X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0
Cc: Kurt Zeilenga <Kurt.Zeilenga@Isode.com>, vcarddav@ietf.org
Subject: WG Action: vCard and vCardDAV (vcarddav)
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ietf-announce.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
Errors-To: ietf-announce-bounces@ietf.org
A new IETF working group has been formed in the Applications Area. For additional information, please contact the Area Directors or the WG Chairs. +++ vCard and vCardDAV (vcarddav) ============================== Last Modified: 2007-12-26 Current Status: Active Working Group Chair(s): Marc Blanchet <marc.blanchet@viagenie.ca> Kurt Zeilenga <Kurt.Zeilenga@Isode.com> Applications Area Director(s): Chris Newman <chris.newman@sun.com> Lisa Dusseault <lisa@osafoundation.org> Applications Area Advisor: Chris Newman <chris.newman@sun.com> Mailing Lists: General Discussion: vcarddav@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/vcarddav Archive: http://www1.ietf.org/pipermail/vcarddav Description of Working Group: 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. Moreover, the vCard format has been extended by many parties and the current specification is ambiguous for some objects. 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 outputs: (1) A revision of the vCard specification (RFC2426) at proposed standard status. This revision shall include other vCard standardized extensions (RFC 2739, 4770) and extensions assisting synchronization technologies (for example, a per-entry UUID or per-attribute sequence number). Other extensions shall be considered either in the base specification or in additional documents. (2) 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 will consider the following secondary outputs: (3) 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. (4) Identifying useful deployed vCard vendor extensions and creating standards track versions of those extensions. (5) Cooperate with the Sieve WG to produce a Sieve extension for address book Sieve tests. (6) LDAP mapping to the new vCard format without loss of data. Goals and milestones: Q1 2008 Address book access protocol draft Q1 2008 vCard new revision draft Q2 2008 submit to IESG both drafts Q2 2008 XML schema Q2 2008 LDAP schema Q3 2008 vcard extensions Q4 2008 submit to IESG remaining drafts _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
- WG Action: vCard and vCardDAV (vcarddav) IESG Secretary