Re: contact format coordination - next steps

+vcarddav (marc requested we share this discussion more broadly).

On Wed, Sep 8, 2010 at 9:12 AM, Joseph Smarr <jsmarr@gmail.com> wrote:

> Hi guys, sorry again to have missed the call, and thanks for setting up
> this group!
>
> The main thing that's changed since I last talked to the IETF about
> Portable Contacts in March '09 (see
> http://josephsmarr.com/2009/03/25/portable-contacts-and-vcarddav-ietf-74/)
> is that PoCo has been adopted by a lot more companies and open-source
> projects. See
> http://wiki.portablecontacts.net/Software-and-Services-using-Portable-Contacts for
> a pretty up-to-date list, which now includes Google, Yahoo, Microsoft,
> MySpace, Plaxo, hi5, Mozilla, the W3C, and others, as well as open-source
> libraries in most popular languages. The spec itself hasn't changed much (if
> at all), mainly because it seems to have served the needs of everyone that
> wanted a standard way to expose access to contact data. This shouldn't be
> too surprising, since we designed PoCo in collaboration with many of the big
> contact providers, and based the design off of their existing (proprietary)
> APIs, as well as basing it off vCard 3 and OpenSocial, but nevertheless I
> think it's good evidence of "rough consensus and running code" for PoCo.
>
> At the last IETF meeting I attended, we focused on trying to align the
> contact schemas of vCard 4 (and its representation in vCard XML) with the
> PoCo schema. We punted on the "end-to-end protocol" part, which I think is
> reasonable, since CardDAV is tackling a broader set of use cases than just
> accessing contact data, but making sure the underlying representations of
> contact info are identical--or at least trivially transformable between the
> two formats--is still highly desirable from my point of view, since that's
> where most of the pain currently lies when dealing with fragmented schemata
> that are hard to map between. After that meeting, Simon Perreault and I did
> a pretty exhaustive comparison of vCard4/vCardXML vs PoCo, and we most of
> what we found were fairly small differences, but ones that should be ironed
> out nonetheless. It's not clear to me whether changes were made to either
> vCard 4 or vCard XML after that, but looking at the latest drafts of both, I
> still have many of the same concerns I did over a year ago.
>
> For context, the two main design goals of Portable Contacts were "*ease of
> developer adoption*" and "*inclusive of modern uses of social data*", and
> I think vCard could stand to improve significantly in both areas.
>
> To achieve the former goal, we focused on making the schema as simple as
> possible, and eliminated much of the archaic syntax and naming conventions
> that are part of vCard's legacy. We also specified a JSON and XML
> serialization that were as terse and readable as possible, even though this
> limits certain types of extensibility (or rather, just means you have to do
> things a bit differently). For instance, compare the representations of
> gender in Portable Contacts and the proposed vCard XML:
>
> <gender>male</gender>
>
> vs.
>
> <sex><integer>1</integer></sex>
>
>
> I think it's hard to argue that the first version (PoCo) is far more
> readable and semantically clear.
>
> Similarly, we chose to name the list of mailing address fields "addresses"
> instead of vCard's anachronistic "adr", and we dropped the "post-office box"
> and "extended address" sub-fields, which in practice are ill-defined and
> used by none of the major address book providers we're aware of, preferring
> instead a single "streetAddress" multi-line field, which is what almost
> everyone implements anyway and sticks in the third sub-field of adr ("street
> address"). And there are several other examples of attempting to simplify
> and modernize vCard that we adopted in Portable Contacts and that I would
> urge the IETF to consider as part of vCard 4 and vCard XML. I would also
> strongly encourage the publication of a JSON serialization for vCard in
> addition to XML, since it is now a very popular format for APIs, and its
> absence will inevitably lead to incompatible attempts to re-invent it as
> needed.
>
> As for the choice of fields to include, we melded together vCard and
> OpenSocial to provide a schema that was reflective of both traditional
> contact info and modern social networking fields, since the two worlds have
> already collided in many cases (see e.g. Facebook's API, which includes both
> types of info for users' profiles). When I look at the current vCard 4
> schema, it seems to have added several new fields (the appendix lists KIND,
> SEX, LANG, DDAY, BIRTH, DEATH, XML, and CLIENTPIDMAP, plus some
> calendar-related fields), but these are generally not fields I have seen
> either used or requested by most contact services I'm aware of, and vCard
> does not seem to have added many (if any) social networking fields. Again, I
> worry that this will limit the perceived applicability of vCard 4 to only
> traditional contact stores, and misses the opportunity to make vCard the de
> facto standard for "people data" more generally.
>
> Sorry this message got a bit longer than I'd intended, but I think the main
> decision we should make as a group is whether to jump at this opportunity to
> simplify and modernize the vCard spec more, or whether to stick with the
> current design and only entertain minor tweaks. Either way, I'm happy to
> provide more targeted and detailed feedback, but given the larger number of
> parties now on this thread, and given the "field experience" we've
> collectively had over the past couple of years, my personal strong
> suggestion is to not let this opportunity pass us by.
>
> Thanks! js
>
> On Wed, Sep 8, 2010 at 6:51 AM, Thomas Roessler <tlr@w3.org> wrote:
>
>> Hello,
>>
>> first of all, welcome to public-contacts-coord.  This mailing list
>> includes those who were involved in the earlier CC thread on contacts
>> coordination. The purpose of this list is to serve as an informal place for
>> coordination on contact formats among different groups and standards bodies
>> interested in the space.  We currently have people involved with IETF vcard,
>> W3C Device API WG, Portable Contacts, and the OMA Consolidated Address Book
>> effort.
>>
>> If you don't want to be on this list, let me know; if you think we need to
>> get other groups (or individuals) involved, please let me know as well.
>>
>> The list is archived here:
>>        http://lists.w3.org/Archives/Public/public-contacts-coord/
>>
>> Notes from our conference call last week are here:
>>        http://www.w3.org/2010/09/03-contacts-minutes.html
>>
>> The main action items were:
>>
>> - Once the OMA CAB spec has the latest changes folded in, Cristina
>> Badulescu will send a heads-up and a pointer to the spec to this list.
>> - Mac Blanchet wanted to look for volunteers who would review the mapping
>> of OMA CAB to vcard 3 for sanity and report back.
>>
>> We didn't have anybody on the call who could talk in detail about Portable
>> Contacts. Joseph, Chris, Tantek -- perhaps you want to say a few words about
>> the current status on the list?
>>
>> Thanks,
>> --
>> Thomas Roessler, W3C  <tlr@w3.org>  (@roessler)
>>
>>
>>
>>
>>
>>
>>
>>
>>
>