Re: [VCARDDAV] wg concensus to publish? NO

[Cyrus Daboo <[e-mail]>]

Hi Rohit,

--On September 28, 2010 8:32:35 PM -0700 Rohit Khare <[e-mail]> 
wrote:

>> I am a little confused by this statement. What "brand name" and
>> which "non-IETF" standard are you referring to?
>
> You are correct, and I should be more careful. The pre-XML vCard3
> standard (RFC 2425/6) is a fairly direct mapping of the work of the
> Versit Consortium, as acknowledged in the RFC (as was vCard 2.1 at the
> IMC, in turn).
>
> You are also correct that I shouldn't call vCard "non-IETF", since rev
> 3.0 is a Proposed Standard regardless of its origins. vCard4 is a
> significant improvement (but all the same, a significant departure) from
> the line-by-line encoding that's in the marketplace today.
>
> The sense in which I believe my observation was intended to be fair and
> helpful is that the term "vCard" as used by range of products, from
> embedded hardware to the latest in social Web services in the cloud, all
> refer to the loosely interoperable line-by-line encoding that's been in
> use for almost 20 years.

OK, so let's go over a little history here. Yes the versit/IMC version 2.1 
has had wide spread use across a gamut of devices and platforms. The IETF 
v3 effort has also had wide spread use. However, certain groups choose not 
to "upgrade" to v3 because they saw no significant advantage in doing so - 
those groups were approached at the beginning of the IETF v4 effort and 
asked what key features they wanted to see changed. That input lead to a 
number of the changes present in v4.

As to whether v3->v4 is a "dramatic" change, let us look at Appendix A in 
the v4 spec which enumerates the changes:

A.1 Describes mostly structural changes of the specification, a switch to 
utf-8 as the default, and a proper MIME type. All of these are important to 
improve the spec.

A.2 Items removed - 5 bullets. I think the only controversial one here is 
the N property change which Joseph Smarr called out. I have not yet gone 
back and looked at the list archives to see why that change was made, but 
it is definitely an "incompatible" change to v3.

A.3 Items added - 6 bullets. Two of these involve pulling in new 
definitions added by IETF specs after v3 was published. Another set was for 
the new property-level synchronization feature (which was a key requirement 
to fix at the outset of this WG's work). One you called out is "DEATH". 
This is a cultural thing. In some cultures the date of death is very 
significant - e.g., certain religious ceremonies need to be performed on 
the anniversary of a death. So I think we are fully justified in adding it. 
I believe there were also genealogy use cases mentioned, that justify its 
presence.

A.4 Changes - 5 bullets. The biggest one here is the switch to use tel: URI 
for the TEL value. I absolutely believe this is the right thing to do - we 
should take the opportunity to "modernize" data values where possible. tel: 
URIs are in wide spread use and make it much easier for machines to handle 
phone numbers for things like auto/speed-dial etc without all the ambiguity 
of an arbitrarily formatted "human" generated string.

All-in-all I don't see anything "dramatic" here. If anything the WG has 
been conservative in its approach. Right now it seems like others are 
saying we have been too conservative and in fact what is needed is a much 
more dramatic change!

So here is the question: are people willingly to throw everything out - 
everything includes vCard, PoCo, OMA CAB, W3C work etc - and come together 
on a single contact schema (which can have text, xml, json etc bindings)? 
(Obviously "throw everything out" is an over statement here, but I want it 
to be clear that all the different communities have to be willing and able 
to make changes in their own environments to accommodate the new schema).

The key problem is that the different communities have different use cases. 
Clearly vCard is meant to be much more of a comprehensive "directory" 
record solution - providing information for not just personal contacts, but 
groups, resources, locations etc. PoCo is clearly aimed at personal 
contacts and ease of use in web environments. Is it possible to come up 
with a single schema to satisfy all camps? Can we do that and, say, have 
different "profiles" for different use cases?

I think it is clear that a single schema solution is a long way out. Each 
solution is pretty well entrenched right now. The best option is to move 
forward with incremental changes that bring all these into better 
alignment, and once we are close, then we can consider defining the one 
true schema.

So I still believe we should move forward with vcard v4, but perhaps we can 
have some targeted debate on the specific issues that have been raised - 
Joseph's points about the change to N and request to drop some fields from 
ADR. Once vcard 4 is out, lets push to get alignment between the formats. 
Several people have already done work to compare the different formats so 
we have data input already available to help move that forward.

-- 
Cyrus Daboo