Subject: Re: [VCARDDAV] wg concensus to publish? NO

From: Rohit Khare <[email-masked]>
Date: Tue, 28 Sep 2010 17:00:56 -0700

Hi, I’m Rohit Khare, and I apologize for being so late to this list.  
Perhaps like other folks, I was aware that there was some work going  
on under the brand name of “vCard”; and checked in on the drafts and  
this listserv from time to time; but didn’t realize the community was  
at WG Last Call until now.

I am concerned that vCardDAV is reusing the brand name and credibility  
of a very widely used non-IETF ‘standard’ to advance several dramatic  
changes, without taking full advantage of the unique opportunity to  
solve some extremely important adjacent problems at the same time.

Almost every successful data storage format has been human-readable  
and incrementally editable (see also ‘ASN.1’). Merely using XML  
doesn’t make that so, especially when there are opportunities to learn  
from formats fielded for exporting 100M+ contacts that could be  
considered and rejected for better reasons than “Standards are  
good” (w.r.t. sex=1 vs. gender ‘male’ — we’re dealing with social data  
rather than medical data, and there are far, far more culturally- 
defined gradations of gender than sex alone).

Similarly, DEATH. I stand ready to be corrected, but I don’t know of a  
significant fielded system for “contacts” or “social graphs” that has  
user experience with such fields. Names are defined by their uses, so  
we ought to be able to identify more utility than merely demonstrating  
round-trip interop to accept an expansion of the core vocabulary.

Finally, there’s the role of standards as a social forum to solve  
industry-wide problems. There are a lot of “investors” in the existing  
vCard, but I haven’t been convinced by my (admittedly cursory!)  
readings of the list and docs that organizations controlling large  
amounts of contact data have put these new ideas through their paces  
by exporting (much less, importing) data in vCard4. In this, I appeal  
to the circular fact that this work is trying to brand itself as a  
vCard successor, so it bears the additional burden of soliciting  
support from existing vCard users before it can assume that mantle.

Of course, there’s no end to demands to “coordinate” with other groups  
and standards, especially for something as foundational as contact  
information. I realize that volunteers who have poured their time and  
effort into this process deserve better than an endless stream of  
objections or complaints.

I am speaking for myself, in the IETF tradition of individual  
participation. Yes, I’ve worked with Tantek on microformats.org ; I  
currently work with Joseph Smarr; and I recently worked for the  
division of BT that Kevin Marks is at. Heck, DAV itself came out of  
our Web research group at UCI (as did REST).

In each of these cases, though, my role was based on more than a  
passing familiarity with standards, markup, Web architecture, and  
“social” computing.  It has been a few years since I’ve authored an  
IETF standard, but I don’t believe the norms have changed enough to  
believe that ‘voting’ is any way to come to ‘rough consensus and  
running code.’

I’m under no illusion that toting up YES and NO replies to the list is  
definitive, or even deserving of equal weight. I also have a lot of  
sympathy for the years of work that have gone into these docs and the  
frustration that might result from a late-comer voicing ‘principled’  
concerns.

However, and with sincere apologies to folks I haven’t even met f2f  
yet (including Cyrus, Marc, and the rest of the WG) I have to state  
that NO, I’m not comfortable with a Last Call for these two documents  
at this time.

Respectfully,
Rohit Khare
[email-masked]
Hacker, KNX.to (former)
Product Manager, Google (current)

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 28 Sep 2010 23:03:24 -0400

Hi Rohit,

--On September 28, 2010 5:00:56 PM -0700 Rohit Khare <[email-masked]> 
wrote:

> I am concerned that vCardDAV is reusing the brand name and credibility of
> a very widely used non-IETF ‘standard’ to advance several dramatic
> changes, without taking full advantage of the unique opportunity to solve
> some extremely important adjacent problems at the same time.

I am a little confused by this statement. What "brand name" and which 
"non-IETF" standard are you referring to?

-- 
Cyrus Daboo

---

From: Rohit Khare <[email-masked]>
Date: Tue, 28 Sep 2010 20:32:35 -0700

On Sep 28, 2010, at 8:03 PM, Cyrus Daboo 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.

Best,
   Rohit

http://en.wikipedia.org/wiki/VCard
> Versitcard was originally proposed in 1995 by the Versit Consortium,  
> which consisted of Apple, AT&T Technologies (later Lucent), IBM and  
> Siemens. In December 1996, ownership of the format was handed over  
> to the Internet Mail Consortium, a trade association for companies  
> with an interest in Internet e-mail.
See also the press release handing off to Paul Hoffman, http://www.imc.org/pdi/versit-to-imc.html

---

From: Mike Douglass <[email-masked]>
Date: Wed, 29 Sep 2010 01:11:46 -0400

My experience as a user is that current address book implementations 
are a completely non-interoperable disaster.

I have had the unhappy experience of moving my wifes contacts 3 times - 
which has largely led her back to a paper address book - and i 
completely concur with her decision. I cannot, as an implementor, defend 
the current state of affairs. If you never have to move your contacts 
you may be fine. If you do, they will end up misordered, duplicated or 
just missing - I don't even move my own contacts - it almost never works.

I mostly keep quiet at home about being a vcard 4/carddav implementor.

This is all to say that we have nothing to congratulate ourselves on 
with the current state of affairs.

One of the important questions for the short term - still unanswered - is:

If we go ahead and publish vcard 4 core, what will prevent us getting 
better alignment with PoCo/W3c etc within some reasonable period of time 
in say version 4.1?

On 09/28/2010 11:32 PM, Rohit Khare wrote:
>> Siemens. In December 1996, ownership of the format was handed over to 
>> the Internet Mail Consortium, a trade association for companies with 
>> an interest in Internet e-mail.
> See also the press release handing off to Paul Hoffman, 
> http://www.imc.org/pdi/versit-to-imc.html
> _______________________________________________
> VCARDDAV mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vcarddav
>

-- 

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: Joseph Smarr <[email-masked]>
Date: Tue, 28 Sep 2010 23:01:21 -0700

Mike-I agree with you assessment, which is why I would ask the flip-side of
your question: why publish vcard 4 unless/until we think it will materially
solve the problems you point out? Publishing a new spec always has a
cost--it will add confusion and consume time and increase legacy, as there's
one more version of one more spec to learn and support--and if the immediate
next step is to work on 4.1 with better alignment, more simplicity, etc.--as
you and others have often suggested--then I thing it begs the question of
what we gain by publishing now, other than "it's been 2 years, so people
would like to see a result", which i don't think is a good enough reason. :)

On Tue, Sep 28, 2010 at 10:11 PM, Mike Douglass <[email-masked]> wrote:

>  My experience as a user is that current address book implementations are a
> completely non-interoperable disaster.
>
> which has largely led her back to a paper address book - and i completely
> concur with her decision. I cannot, as an implementor, defend the current
> state of affairs. If you never have to move your contacts you may be fine.
> If you do, they will end up misordered, duplicated or just missing - I don't
> even move my own contacts - it almost never works.
>
> This is all to say that we have nothing to congratulate ourselves on with
> the current state of affairs.
>
> better alignment with PoCo/W3c etc within some reasonable period of time in
> say version 4.1?
>
>
>> 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.
>>
>> Best,
>>  Rohit
>>
>>> which consisted of Apple, AT&T Technologies (later Lucent), IBM and Siemens.
>>> In December 1996, ownership of the format was handed over to the Internet
>>> Mail Consortium, a trade association for companies with an interest in
>>> Internet e-mail.
>>>

---

From: Julian Reschke <[email-masked]>
Date: Wed, 29 Sep 2010 09:20:24 +0200

On 29.09.2010 05:32, Rohit Khare wrote:
> ...
> significant improvement (but all the same, a significant departure) from
> the line-by-line encoding that's in the marketplace today.
> ...

Rohit, could you clarify what you mean by "line-by-line encoding" here?

Best regards, Julian

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 29 Sep 2010 10:11:29 -0400

Hi Rohit,

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

> 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

---

From: Mike Douglass <[email-masked]>
Date: Wed, 29 Sep 2010 10:43:30 -0400

Mostly because I believe that vcard 4 is an honest - though maybe not 
perfect - attempt to build on the experience of vcard3.

The discussion over the use of SORT-AS is a case in point. Vcard 3 
implementations implement ordering in almost as many ways as there are 
applications. My experience with vcard 3 has been that importing data 
from one application into another almost always leads to misordered and 
duplicated data - some will insist on the data being written they way 
they want to order it, others try to parse it and order according to the 
result and so on. The end result is that I almost always end up 
reentering fields.

I don't believe vcard4 is the answer to everything but it's a good start 
and my experience suggests that the mismatch between v4 and what follows 
will be much less than between almost any 2 current v3 implementations.

Filip Navara  has pointed out some of the specific remaining issues - 
there's still time to discuss these in the context of a last call but I 
still don't believe that publishing as an RFC should hinder the efforts 
at alignment. It might even help as we can concentrate on that issue 
rather than essentially restarting the whole process.

On 09/29/2010 02:01 AM, Joseph Smarr wrote:
> Mike-I agree with you assessment, which is why I would ask the 
> flip-side of your question: why publish vcard 4 unless/until we think 
> it will materially solve the problems you point out? Publishing a new 
> spec always has a cost--it will add confusion and consume time and 
> increase legacy, as there's one more version of one more spec to learn 
> and support--and if the immediate next step is to work on 4.1 with 
> better alignment, more simplicity, etc.--as you and others have often 
> suggested--then I thing it begs the question of what we gain by 
> publishing now, other than "it's been 2 years, so people would like to 
> see a result", which i don't think is a good enough reason. :)
>
> On Tue, Sep 28, 2010 at 10:11 PM, Mike Douglass <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>      My experience as a user is that current address book
>     implementations are a completely non-interoperable disaster.
>
>     I have had the unhappy experience of moving my wifes contacts 3
>     times - which has largely led her back to a paper address book -
>     and i completely concur with her decision. I cannot, as an
>     implementor, defend the current state of affairs. If you never
>     have to move your contacts you may be fine. If you do, they will
>     end up misordered, duplicated or just missing - I don't even move
>     my own contacts - it almost never works.
>
>     This is all to say that we have nothing to congratulate ourselves
>     on with the current state of affairs.
>
>     If we go ahead and publish vcard 4 core, what will prevent us
>     getting better alignment with PoCo/W3c etc within some reasonable
>     period of time in say version 4.1?
>
>
>             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.
>
>         Best,
>          Rohit
>
>             Versitcard was originally proposed in 1995 by the Versit
>             Consortium, which consisted of Apple, AT&T Technologies
>             (later Lucent), IBM and Siemens. In December 1996,
>             ownership of the format was handed over to the Internet
>             Mail Consortium, a trade association for companies with an
>             interest in Internet e-mail.
>
>         [email-masked] <mailto:[email-masked]>
>     Mike Douglass [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

--

---

From: Rohit Khare <[email-masked]>
Date: Wed, 29 Sep 2010 07:48:27 -0700

> Rohit, could you clarify what you mean by "line-by-line encoding"  

A text file format primarily delimited by [\n:;] with idiosyncratic  
boundary delimiters ("begin:VCARD"), and special cases for nesting  
(the "vcard" value type).

Or, more functionally, something developers are used to shredding with  
grep; and users are able to edit in a plain text editor. There's a lot  
more change under the hood than the version # increment might indicate.

These are not meant to be value judgments that I prefer the old  
approach!

Best,
   Rohit

PS. I really appreciated Mr. Navara's post this morning about  
experience within emClient. I can see how there's some scope-creep  
between the traditional view of "what's best for email (and, perhaps,  
unified communications)" and the newer view of "how can users best  
indicate how to reach other users (across social networks and on the  
Web)"

---

From: Julian Reschke <[email-masked]>
Date: Wed, 29 Sep 2010 16:55:50 +0200

On 29.09.2010 16:48, Rohit Khare wrote:
> boundary delimiters ("begin:VCARD"), and special cases for nesting (the
> "vcard" value type).
>
> These are not meant to be value judgments that I prefer the old approach!

But that isn't different in vCard4 at all. Or am I missing something?

(The XML format is an *alternate* format, and not part of the vCard4 spec).

Best regards, Julian

---

From: Eliot Lear <[email-masked]>
Date: Wed, 29 Sep 2010 17:01:33 +0200

> But that isn't different in vCard4 at all. Or am I missing something?
+1 – I'm confused about the actual objection still.

---

From: Rohit Khare <[email-masked]>
Date: Tue, 28 Sep 2010 16:53:48 -0700

Respectfully,
  Rohit Khare
  [email-masked]
  Hacker, KNX.to (former)

---

From: Simon Perreault <[email-masked]>
Date: Wed, 29 Sep 2010 11:11:43 -0400

> But that isn't different in vCard4 at all. Or am I missing something?

There's no nesting anymore... is that it? ;)

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

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 29 Sep 2010 11:49:01 -0400

Hi Rohit,

> more change under the hood than the version # increment might indicate.

I would consider it a huge bug in any product that exposed a "raw" vcard to 
a user to edit. I would never expect users to know how to deal with 
character escaping/quoting, line folding, structured data formatting, etc. 
It is fine for us developers who are willingly to go read the two existing 
specs (which we have compressed into a much more manageable one in v4) and 
are happy tinkering with things like that, and able to cope with the 
consequences of breaking something.

-- 
Cyrus Daboo