Re: [VCARDDAV] wg concensus to publish?

[Cyrus Daboo <[e-mail]>]

Hi Joseph,

--On October 1, 2010 7:48:16 AM -0700 Joseph Smarr <[e-mail]> wrote:

> Cyrus-I *did* come to the IETF and ask vCard to be revised! :) 

Yes, I was there too.

>
> See http://josephsmarr.com/2009/03/25/portable-contacts-and-vcarddav-iet
> f-74/ -- I spoke over a year ago in detail with Marc, Simon, etc about
> the opportunities to simplify and modernize and extend what vCard is
> doing. Everyone was polite and thoughtful at the time, but then seems to
> have ignored or rejected all the proposed improvements. I'm also
> frustrated that we're having these more substantive discussions now much
> later, but they still need to be had--not because the rest of us don't
> like vCard or don't want it to succeed, but exactly the opposite--we
> really want vCard to be great and get widespread adoption and end the
> fragmentation that has persisted in the industry for so long. We have a
> lot of experience getting that done, and we want to impart that knowledge
> to your team so that your spec has a better shot at reaching its
> potential.

I want to dispute the perceived lack of wide spread adoption of vcard. I 
believe that to be false. All the major desktop contact systems have 
support for vCard. Many, many mobile systems support it. vCards have been 
sent and processed via email for decades now. Widely adopted by web apps - 
well that is a different and valid question.

> But in order for that to happen, the rest of the WG needs to think
> through some of these fundamental trade-offs and decide where they stand:

> - taking this opportunity to modernize (both in syntax and
> semantics) vs. preserving legacy

Let's leave syntax out - we now have both text and XML variants, and a JSON 
variant would be trivial to do too. As for preserving legacy, vCard does 
have a large legacy just because of how widespread its use is.

> - favoring simplicity/readability of the wire format (esp for XML) vs.
> maximizing flexibility / automaticity of conversion

I guess there is a fundamental difference here over how important 
"readability" is. Personally I find neither XML or JSON all that "readable" 
in the first place. What I care about is having a concrete well-defined 
schema that is easy to implement in code for the use cases I need to 
support. Yes there is a concern about unnecessary size, particularly given 
that we want to send these things to mobile devices, but on-the-wire 
compression is a big help.

> - expanding scope to more fields vs. sticking to "core address book" data

We already have this in v4. The new IANA registry allows for easy 
extensions to the schema. There are already several drafts doing that (one 
for social networking properties, one for calendaring and scheduling 
resource properties).

-- 
Cyrus Daboo