Subject: Re: [VCARDDAV] contact format coordination - next steps

From: Joseph Smarr <[email-masked]>
Date: Wed, 8 Sep 2010 12:08:59 -0700

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

On Wed, Sep 8, 2010 at 9:12 AM, Joseph Smarr <[email-masked]> 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 <[email-masked]> 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  <[email-masked]>  (@roessler)
>>
>>
>>
>>
>>
>>
>>
>>
>>
>

---

From: Renato Iannella <[email-masked]>
Date: Thu, 9 Sep 2010 10:31:23 +1000

On 9 Sep 2010, at 05:08, Joseph Smarr wrote:

>  For instance, compare the representations of gender in Portable Contacts and the proposed vCard XML:
> <gender>male</gender>
> vs. 
> I think it's hard to argue that the first version (PoCo) is far more readable and semantically clear. 

I agree strongly here - which I have posted in the past [1] [2]
We must provide *easy and non-verbose* XML encodings.

>  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.

Can you give some examples of the types of new social networking fields that were added to PoCo?

Do you mean the ones taken from OpenSocial? (eg tvShows, pets....) ?

Cheers...
Renato Iannella
Semantic Identity
http://semanticidentity.com
Mobile: +61 4 1313 2206

[1] http://www.ietf.org/mail-archive/web/vcarddav/current/msg01368.html
[2] http://www.ietf.org/mail-archive/web/vcarddav/current/msg01288.html

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 08 Sep 2010 20:37:03 -0400

Hi Renato,

> We must provide *easy and non-verbose* XML encodings.

No - not at the expense of making the conversion between XML and native 
vCard much harder to implement (with the likelihood of significantly 
impacting interoperability). The current format trivially maps the 
semantics of the vCard data model to XML element structure. There is no 
special casing of any property or value type, so writing a converter is 
easy. Also, this is more extensible because any new type of property 
extension on the vCard side can immediately be converted to XML.

-- 
Cyrus Daboo

---

From: Joseph Smarr <[email-masked]>
Date: Wed, 8 Sep 2010 17:38:21 -0700

We added the following singular fields from OpenSocial:

aboutMe, bodyType, currentLocation, drinker, ethnicity, fashion,
happiestWhen, humor, livingArrangement, lookingFor, profileSong,
profileVideo, relationshipStatus, religion, romance, scaredOf,
sexualOrientation, smoker, and status

and the following plural fields:

activities, books, cars, children, food, heroes, interests, jobInterests,
languages, languagesSpoken, movies, music, pets, politicalViews, quotes,
sports, turnOffs, turnOns, and tvShows.

The spec authors of OpenSocial researched and documented all the major
social networks at the time, and these were the fields that they decided
were common enough to merit a "canonical field name". Of course, some are
more common and useful than others, but the thinking is: the cost to
specifying a field name is very low (if you don't need it, don't use it),
but the cost to not agreeing on a field that many sites want to expose is
high (they probably will each invent a non-compatible field name), so it's
better to err on the side of saying "*if* you want to represent this field,
here's the agreed-upon way to do it", which is the approach we've taken in
general with PoCo, which seems to have worked out well. It also defends
against the "oh, looks like this spec isn't for me because it doesn't
support fields X, Y, or Z that are common for my use case" problem, which I
worry vCard as currently proposed will face, at least in the broader social
web space.

On Wed, Sep 8, 2010 at 5:31 PM, Renato Iannella <[email-masked]> wrote:

>  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.
>>
>

---

From: Mike Douglass <[email-masked]>
Date: Wed, 08 Sep 2010 21:34:41 -0400

And to support that I've just written the parser for the xcalendar 
format - very compact. Almost no special cases to handle - and probably 
no changes if extra properties are added

On 09/08/2010 08:37 PM, Cyrus Daboo wrote:
> No - not at the expense of making the conversion between XML and 
> native vCard much harder to implement (with the likelihood of 
> significantly impacting interoperability). The current format 
> trivially maps the semantics of the vCard data model to XML element 
> structure. There is no special casing of any property or value type, 
> so writing a converter is easy. Also, this is more extensible because 
> any new type of property extension on the vCard side can immediately 
> be converted to XML.
>

-- 

Mike Douglass                           [email-masked]
Senior Systems Programmer
Communication&  Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

---

From: Renato Iannella <[email-masked]>
Date: Thu, 9 Sep 2010 16:12:30 +1000

On 9 Sep 2010, at 10:38, Joseph Smarr wrote:

> It also defends against the "oh, looks like this spec isn't for me because it doesn't support fields X, Y, or Z that are common for my use case" problem, which I worry vCard as currently proposed will face, at least in the broader social web space.

I think the issue is that someone looks at vCard (for example) and says..."there are no zodiac-sign properties" so I will go and re-invent *all* the same properties, add my zodiac-sign, use a new (different) namespace and....well you know the rest...

I don't think vCard's role is to incorporate all the "social" properties one can think of....it is more the "core" properties that interest vCard.

The problem then is - others are then reluctant to *reuse* the vCard semantics/namespace - preferring to re-invent all the properties again, usually with slight changes to property names etc.

The other good example of this if FOAF - repeats most of the vCard properties - but does not *reuse* them.

Now, just seen the OMA contacts spec and wondering if the moon is made of cheese ;-)

Cheers

Renato Iannella
http://renato.iannella.it

---

From: Simon Perreault <[email-masked]>
Date: Thu, 09 Sep 2010 07:55:55 -0400

(+vcarddav)

(Just trying to reply to the technical points concerning vCard...)

On 2010-09-08 12:12, Joseph Smarr wrote:
> For instance, compare the
> representations of gender in Portable Contacts and the proposed vCard XML:
> 
>     <gender>male</gender>
> 
>     vs. 
> 

more readable: Agreed, but who cares? Users are not going to see this.
more semantically clear: Disagree, the semantics of vCard are very well
defined.

Note that we had exactly <gender>male</gender> at the beginning and
gradually changed it to what we have now, for two reasons:

1. It's better to follow standards. In this case, ISO 5218 applies. It
says that the term "sex" is preferred, and defines the applicable
values. Standards are good.

2. Usage of the <integer> element provides two advantages (which are not
related to the sex property in particular, but apply at large):

  - It allows using parameter elements which would be siblings of the
value text-node otherwise, making the parser much simpler.

  - It facilitates extensibility using XML namespaces.

> Similarly, we chose to name the list of mailing address fields
> "addresses" instead of vCard's anachronistic "adr"

Again, why should anyone care about the names of the elements? Users are
not going to see this.

> 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").

This is also available in vCard. ADR is for formatted addresses whereas
LABEL is for unformatted addresses.

> vCard does not seem to have added
> many (if any) social networking fields.

Not in vCard *core*. A separate RFC will address this. The draft is here:
http://tools.ietf.org/html/draft-george-vcarddav-vcard-extension-02

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: Joseph Smarr <[email-masked]>
Date: Thu, 9 Sep 2010 07:12:32 -0700

> This is also available in vCard. ADR is for formatted addresses
whereas LABEL is for unformatted addresses.

Simon-I think you missed my point here. Even within the *structured*
address, one of the "known bugs" in vCard 3 is the fact that they use 3
different sub-fields just for the street address (pobox, extended-address,
and street-address), but nobody knows what those first two fields are for,
nobody uses them, no UIs expose them separately, and they create a lot of
ambiguity and confusion. I'm all for maintaining backwards compatibility
where you can, but I'd strongly urge you to say "these first two fields are
deprecated and should no longer be used, just put the full street address in
the street-address field".

So for instance, the following address in vCard:

ADR;TYPE=WORK:;;1300 Crittenden Lane\nSuite 300;Mountain View;CA;94043;USA
LABEL;TYPE=WORK:1300 Crittenden Lane\nSuite 300\nMountain View, CA 94043 USA

Would look like this in PoCo:

"addresses": [
  {
    "type": "work,
    "streetAddress": "1300 Crittenden Lane\nSuite 300",
    "locality": "Mountain View",
    "region": "CA",
    "postalCode": "94043",
    "country": "USA",
    "formatted": "1300 Crittenden Lane\nSuite 300\nMountain View, CA 94043"
  }
]

and like this in vCard XML:

<adr>
  <parameters><type>work</type></parameters>
  <pobox/>
  <ext/>
  <street><text>1300 Crittenden Lane\nSuite 300</text></street>
  <locality><text>Mountain View</text></locality>
  <region><text>CA</text></region>
  <code><text>94043</text></code>
  <country><text>USA</text></country>
</adr>
<label>
  <parameters><type>work</type></parameters>
  <text>1300 Crittenden Lane\nSuite 300\nMountain View, CA 94043</text>
</label>

Make sense? Any objections?
Thanks, js

PS: Do you know if there's any way in vCard to say "this 'adr' and this
'label' correspond to the same physical address?". Just saying "they both
have type=work" isn't really sufficient since you might work out of multiple
offices, say, or have a second vacation home. In PoCo, we chose to combine
them by having a "formatted" value for the unstructured address alongside
the structured counterparts. This is very useful for "round-tripping"
complex addresses with programs like Outlook that let you edit both the
structured and unstructured versions of the same address.

On Thu, Sep 9, 2010 at 4:55 AM, Simon Perreault <[email-masked]
> wrote:

---

From: Simon Perreault <[email-masked]>
Date: Thu, 09 Sep 2010 10:27:12 -0400

On 2010-09-09 10:12, Joseph Smarr wrote:
> different sub-fields just for the street address (pobox,
> extended-address, and street-address), but nobody knows what those first
> two fields are for, nobody uses them, no UIs expose them separately, and
> they create a lot of ambiguity and confusion. I'm all for maintaining
> backwards compatibility where you can, but I'd strongly urge you to say
> "these first two fields are deprecated and should no longer be used,
> just put the full street address in the street-address field". 

Got it, I understand now.

> Make sense? Any objections?

Makes sense to me, although I'd prefer to just drop the fields entirely.

The only potential objection I see would be "we're trying to follow
X.520", but that seems pretty weak since ADR right now is some kind of
blend of what they call "Geographical Attributes" and "Postal
Addressing", and some X.520 fields are missing too.

So I personally would have no objection in removing those two fields.

If the working group agrees, I'll remove them.

> 'label' correspond to the same physical address?". Just saying "they
> both have type=work" isn't really sufficient since you might work out of
> multiple offices, say, or have a second vacation home.

Very good observation! There is no such way. We need one.

> In PoCo, we chose
> to combine them by having a "formatted" value for the unstructured
> address alongside the structured counterparts. This is very useful for
> "round-tripping" complex addresses with programs like Outlook that let
> you edit both the structured and unstructured versions of the same address.

How would the working-group feel about merging ADR and LABEL to solve
this issue? LABEL would simply be an additional field in ADR, much like
in PoCo.

(How would these changes affect the last call status of the draft?)

Simon

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 09 Sep 2010 12:32:40 -0400

Hi Simon,

> If the working group agrees, I'll remove them.

This would generate a serious incompatibility with vcard 3. Better would be 
to add a statement that those fields are typically empty and can be ignored 
and should not be used.

Note that in the past I had proposed doing away with ADR and instead having 
a "civic address" field based on the geoprov civic address format. Those 
folks took a lot of time to consider all the various civic addressing 
formats and came up with a comprehensive specification (lots of fields). If 
the real intent is to have an address field that is machine parseable and 
expected to have various field reliably extracted then I think replacing 
ADR would be a better solution than messing with what is there now.

> Very good observation! There is no such way. We need one.

Group prefix can be used for this.

> (How would these changes affect the last call status of the draft?)

Group prefix is sufficient. No need to change.

-- 
Cyrus Daboo

---

From: Simon Perreault <[email-masked]>
Date: Thu, 09 Sep 2010 12:35:37 -0400

> Group prefix can be used for this.

I don't think the group prefix can be used for anything other than
what's in the draft now. It just won't be interoperable. We would need
to add semantics that don't exist now.

Simon

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 09 Sep 2010 15:59:26 -0400

Hi Simon,

> to add semantics that don't exist now.

The current draft says: "The group construct is used to group related 
properties together." I think that adequately describes what we want to do 
with ADR and LABEL.

Just FYI OS X AddressBook.app uses the group prefix in such a way.

-- 
Cyrus Daboo