W3C home > Mailing lists > Public > public-contacts-coord@w3.org > July to September 2010

Re: contact format coordination - next steps

From: Joseph Smarr <jsmarr@gmail.com>
Date: Wed, 8 Sep 2010 09:12:30 -0700
Message-ID: <AANLkTikGrPZ3LAY4uHa7+UJ2pYcJv-cTyKybp0a+1M_m@mail.gmail.com>
To: Thomas Roessler <tlr@w3.org>
Cc: public-contacts-coord@w3.org
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)
>
>
>
>
>
>
>
>
>
Received on Wednesday, 8 September 2010 16:14:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 8 September 2010 16:14:04 GMT