VCardDAV BoF 1. Cyrus Daboo presented "VCard Issues". Even though VCARD 3.0 has been around for nine years, many mobile devices still use the old 2.1 specification, either alone or with non-IETF extensions. Some of the issues a WG could deal with include a lack of internationalization support, a few issues that have been found to be ambiguous, and a clear extensibility model. Cyrus proposes to do one new document merging RFC2425 and RFC2426 into one, in which extensions become part of the core proposal. A new MIME type could advertise proper UTF/8 support. An XML-based variant of vCard would be good to define -- one in which the semantics are identical and mapping can be automated -- because XML-formatted vCards are already in use at least in XMPP. Announcement: vCard workshop is planned by the CalConnect consortium, September 18th 2007 (see http://www.calconnect.org/vcardworkshop.shtml ). 2. Cyrus Daboo on CardDAV Generally, an access protocol for vCard could easily follow the model of CalDAV. There's already been some comments leading to somewhat different syntax, but no argument over the basic architecture. Some of the longstanding WebDAV functional alternatives come up here again, like HTTP caching and whether the data of a vcard should be treated as resource content (body) or properties (metadata). Both CalDAV and CardDAV could use better synchronization functionality. One approach is described in draft-daboo-webdav-sync-00, which also covers non-application-specific use cases. A feature that would avoid polling the server to see changes would be good too. Otherwise, CardDAV would actually be simpler than CalDAV because there are fewer complicating issues such as recurrences and timezones. A mailing list has been set up at vcarddav@ietf.org. Comments: - Rohan Mahy pointed out the draft he authored with notification mechanisms for HTTP resources, which could apply to WebDAV collections or CardDAV resources. 3. Alexey Melnikov: LDAP and vCard Could we use LDAP as an access protocol for vCards? It's good for partial retrieval of this kind of information. Many vCard properties map one-to-one to standard LDAP attributes already. On the other hand, vCard allows all kinds of extensibility which LDAP does not. Similarly there are LDAP attributes that can't be represented in vCard. The InetOrgPerson is the closest LDAP object class to a vCard, and this is not a standard (although that could be fixed). Perhaps most importantly on the "con" side of using LDAP for this purpose, write access is not common on LDAP servers. It's a matter of policy often to keep corporate directory information carefully regulated. We assume that we'll need write access so that people can store their address books containing all kinds of arbitrary entries, not just corporate directory entries. People's address books, today commonly stored locally in vCard format and varations, commonly contain not only cards for people and organizations and places well beyond just one organization, but they also contain more than one contact number or address for certain people. LDAP is more tailored to one organization, so it does not provide a natural way of providing both a "work" and a "home" address for an individual. Comments - Cyrus Daboo pointed out that we will need vCard mapping. A system where the LDAP directory is exposed as a read-only address book in CardDAV is quite easy to imagine. Alexey added that there are already email clients that can fetch address books from LDAP although they can't edit those. - Kurt Zeilenga says that LDAP is good for storing blobs, but as soon as you want to do stuf with blobs it's not as good. - Dave Crocker asked a clarification of whether we were proposing of defining a generic vCard/LDAP mapping to support existing use cases, but not turn LDAP into a data model for storing an address book because it would be a crippled mechanism. Asked for clarification of the LDAP writeability issue. - Leif Johansen asked about whether mappings can be completely automated? 4. Discussion of Proposed Charter The charter was posted to the Apps Discuss mailing list. Chris asked that it be reposted to the vcarddav mailing list. Kurt pointed out that we may get participation from people not yet in this room, at the CalConnect workshop and from OMA. Comments: - ??? questioned - Cyrus Daboo points out that there will be OMA people at the CalConnect workshop. - Rohan Mahy: The charter needs to say whether synchronization is in or out of scope. CONSENSUS CALLs: CALL: Is this work that is appropriate for the IETF to undertake? Consensus in favour. CALL: Who in this room will actively contribute to the effort if it becomes an IETF effort? Significant portion of the room was interested in contributing. CALL: Is the LDAP mapping appropriate IETF work? Consensus yes. CALL: Who would contribute? Only a couple hands. CALL: Is developing a vCard access protocol IETF work? Consensus yes CALL: Who would contribute? half dozen hands. Pete Resnick, Alexey Melnikov and Dave Crocker volunteered to edit the vCard base spec. Eliot asked also for volunteers for a chair of the WG to speak to Chris Newman. Chris will be looking for a process chair and a newbie chair.