Subject: [VCARDDAV] vCard format and lack of interoperability

From: Alessandro Rossini <[email-masked]>
Date: Fri, 16 Nov 2012 19:19:31 +0100

Dear all,

I performed an empirical study of the interoperability of the vCard format:

http://alessandrorossini.org/2012/11/15/the-sad-story-of-the-vcard-format-and-its-lack-of-interoperability/

This study shows that common contact information is often represented by grouped properties and non-standard properties. These properties are not interoperable and make the import/export of vCard files as well as the synchronisation via CardDAV unreliable.

In my opinion, the IETF should remove grouped properties and non-standard properties from the specification, even if this would break backward compatibility. Moreover, the IETF should add social networking properties to the specification. Finally, the IETF should provide an official validator for vCard files.

Any comments?

Best regards,
--
Alessandro Rossini
http://alessandrorossini.org
http://twitter.com/alerossini

---

From: Doug Royer <[email-masked]>
Date: Fri, 16 Nov 2012 12:33:54 -0700

Non standard properties are not for interoperability. They are so that a 
vendor can put their own extension into an object (vCard or iCal) and 
provide what they see as a value added reason to use their product. By 
allowing these non-standard properties and parameters into both iCal and 
vCard it provides a standard way to add vendor value added data that 
will not crash other vendors. The fact it does not crash them, is a 
great sign for vCard and iCal.

And yes - there is always room for improvement.

Doug Royer
[email-masked]
714-989-6135
http://SoftwareAndServices.NET

On 11/16/2012 11:19 AM, Alessandro Rossini wrote:
> _______________________________________________
> VCARDDAV mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vcarddav
>
>

---

From: Barry Leiba <[email-masked]>
Date: Fri, 16 Nov 2012 19:59:47 -0500

> This study shows that common contact information is often represented by grouped
> properties and non-standard properties. These properties are not interoperable and
> make the import/export of vCard files as well as the synchronisation via CardDAV
> unreliable.

Your analysis appears to have a major flaw: you're looking at
implementations that do not (yet) support the 4.0 standard, and are
noting that they do not support the 4.0 standard... and you're saying
that the standard has problems because the implementations don't
support it (or aren't using it properly).  Your empirical study is not
of interoperability, but of deployment.

As you've noted (with your own construction of a 4.0 vCard), most of
what you need is representable interoperably in vCard 4.0.  It's just
that the specification is fairly new (and, yes, it has its problems;
we will likely need a revision of the spec (but not of the version
number) to clarify some things and fix some errors), and support for
it isn't out there yet.  We expect that it will be.

As you've also noted, social networking extensions need to be added.
We've tried several times to get work on that started, and there are a
few of us here who would love to try again.  But we've gotten no
interest from the social networking service providers.  Twitter and
Facebook have both declined to work on it, for example.  *No one*
involved with providing social networking services has come forward to
work on a specification and/or to express interest in implementing any
specification that might be written.  That's why nothing's there.

Finally, the system is extensible.  If there are things that are
missing that you think are important, and you have some real hope that
those things would be implemented if they were defined, then come help
us write a definition and publish it.  (But remember that there does
need to be some reasonable evidence that it'll be implemented in order
for it to be of much use.)

Barry

---

From: Simon Perreault <[email-masked]>
Date: Sun, 18 Nov 2012 10:31:28 +0100

In addition to what others said, this part intrigued me:

Le 2012-11-16 19:19, Alessandro Rossini a écrit :
>  Finally, the IETF should
> provide an official validator for vCard files.

If I understand your analysis correctly, the problem is not with vCards 
that break RFC syntax, but rather with non-standard groups and 
properties. If so, what use would this validator be, since it would 
presumably only be able to check for syntax errors?

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Alessandro Rossini <[email-masked]>
Date: Mon, 19 Nov 2012 13:42:54 +0100

On 16 Nov 2012, at 20:33, Doug Royer <[email-masked]> wrote:

> Non standard properties are not for interoperability. They are so that a vendor can put their own extension into an object (vCard or iCal) and provide what they see as a value added reason to use their product. By allowing these non-standard properties and parameters into both iCal and vCard it provides a standard way to add vendor value added data that will not crash other vendors. The fact it does not crash them, is a great sign for vCard and iCal.

I understand that non-standard properties are not meant for interoperability, but I do not see why they should be included in the specification. In my opinion, open standards should first and foremost promote interoperability and prevent vendor lock-in.

By way of an analogy, browser vendors also introduced non-standard HTML tags and CSS properties to provide what they saw as a value-added reason to use their browser. These tags and properties did not crash other browsers, but they did prevent interoperability and promote vendor lock-in, which is exactly the opposite of what open standards should aim at.

Cheers,

---

From: Alessandro Rossini <[email-masked]>
Date: Mon, 19 Nov 2012 13:49:21 +0100

> it isn't out there yet.  We expect that it will be.

Yes, with the exception of social networking addresses, all the contact information in my empirical study can be represented by interoperable properties in the VCard format 4.0. However, most of the same contact information can also be represented by non-interoperable properties in the same VCard format 4.0.

For example, the web address can be represented by a standard URL property, which is interoperable:

URL;TYPE=home;PREF=1:http://joebloggs.com

This address can also be represented by a standard URL property grouped together with a non-standard X-ABLabel property, which are not interoperable:

item1.URL;PREF=1:http://joebloggs.com
item1.X-ABLabel:_$!<HomePage>!$_

These properties are currently used by Apple (and other vendors targeting Apple), and they would still be used in the future even if Apple adopted the last version of the vCard format, unless grouped properties and non-standard properties are removed from the specification. Therefore, I claimed that the vCard format, including the version 4.0, has a problem of interoperability.

Cheers,

---

From: Alessandro Rossini <[email-masked]>
Date: Mon, 19 Nov 2012 13:54:06 +0100

On 18 Nov 2012, at 10:31, Simon Perreault <[email-masked]> wrote:

> If I understand your analysis correctly, the problem is not with vCards that break RFC syntax, but rather with non-standard groups and properties. If so, what use would this validator be, since it would presumably only be able to check for syntax errors?

In the conclusion of my empirical study, I also suggested that the vendors should implement the last version of the vCard format, and that they should do it right. In my opinion, independently of grouped properties and non-standard properties, a validator would facilitate the correct implementation of the vCard format, since the specification alone may be ambiguous.

Cheers,

---

From: Robert Smith <[email-masked]>
Date: Mon, 19 Nov 2012 09:51:48 -0700

Robert Smith
714-989-6135

On 11/19/2012 05:42 AM, Alessandro Rossini wrote:
> I understand that non-standard properties are not meant for interoperability, but I do not see why they should be included in the specification. ...
Because when there is no standard way to put vendor extension in the 
objects, vendors put them in anyway and
break other vendors.

---

From: Alessandro Rossini <[email-masked]>
Date: Tue, 20 Nov 2012 17:42:36 +0100

On 19 Nov 2012, at 17:51, Robert Smith <[email-masked]> wrote:

> Because when there is no standard way to put vendor extension in the objects, vendors put them in anyway and
> break other vendors.

Yes, vendors may introduce extensions anyway, no matter if there is a standard way to do it or not. However, the standard way to introduce extensions to vCard does not really facilitate the correct implementation of a vCard parser, since the parser has to ignore unknown properties anyway, no matter if their names start with "X-" or not. Moreover, the standard way to introduce extensions to vCard may encourage vendors even more to ignore the interoperability issue rather than to cooperate with the IETF to improve the specification.

Cheers,

---

From: Doug Royer <[email-masked]>
Date: Tue, 20 Nov 2012 10:16:19 -0700

On 11/20/2012 09:42 AM, Alessandro Rossini wrote:.
> Yes, vendors may introduce extensions anyway, no matter if there is a standard way to do it or not. However, the standard way to introduce extensions to vCard does not really facilitate the correct…

It sounds to me as if you are arguing all sides here. You do not want a 
standard way to add them. You agree they will add them anyway. And is 
sounded like you agree it can break vendors.

So if your argument is to remove a standard way of adding them, because 
they will add them anyway. If that is your argument, and given that 
there is no protocol police force, why would anyone spend money to 
change their product so that is was not compatible with their legacy 
products? It would be an invitation to their customers to spend time and 
money looking a competitive products. What company would consider that?

That I think is one of the realities of IETF protocols. At the 
engineering level, we want perfect protocols and everyone to comply.

My experience shows me that vendors at the business level want all of 
their extensions and process flow methodology and none of their 
competitors. Not because they are evil, but because their boss wants to 
know why they will be spending a month or few on something that does not 
add sales to their product. After all there product works now.

If you have done all of this work and found that there are common 
objects done differently by different vendors, write an Internet draft 
and propose a standard way to do those common objects. That's how to 
improve the specification.

If you do not want to write an Internet draft, then we agree, there are 
vendor specific extensions in those objects. If that is your point, yes 
you have made it.

Doug Royer
[email-masked]
208-515-0231

---

From: Alessandro Rossini <[email-masked]>
Date: Wed, 21 Nov 2012 20:21:43 +0100

On 20 Nov 2012, at 18:16, Doug Royer <[email-masked]> wrote:

> And is sounded like you agree it can break vendors.

No, actually I think that the standard way to introduce extensions does not guarantee that these extensions do not crash other vendors. A poorly implemented vCard parser may crash with unknown properties, no matter if their names start with "X-" or not; a correctly implemented vCard parser would ignore them.

> So if your argument is to remove a standard way of adding them, because they will add them anyway.

No, my argument is that the standard way to introduce extensions may encourage vendors even more to ignore the interoperability issue.

> If that is your argument, and given that there is no protocol police force, why would anyone spend money to change their product so that is was not compatible with their legacy products? It would be an invitation to their customers to spend time and money looking a competitive products. What company would consider that?

By way of an analogy, Microsoft did exactly this when they committed to comply with the W3C web standards. They cooperated with the W3C to improve some of the web standards, and they rebuilt Internet Explorer almost from scratch to support these standards, breaking the compatibility with older versions of the browser.

> If you have done all of this work and found that there are common objects done differently by different vendors, write an Internet draft and propose a standard way to do those common objects. That's how to improve the specification.

Yes, I found out that common contact information such as email addresses, telephone numbers, postal addresses, web addresses, and instant messaging addresses can be represented in two ways: by means of standard properties, or by means of standard properties grouped together with non-standard properties. The second way is currently used by Apple (and other vendors targeting Apple); it is unnecessary and prevents interoperability. Therefore, I suggested to improve the specification by removing grouped properties and non-standard properties.

Looking at the archives of this mailing list, it seems that the vCard working group was partially aware of this issue, but preferred backward compatibility to interoperability:

http://www.ietf.org/mail-archive/web/vcarddav/current/msg01850.html

Personally, I would have chosen the opposite.

Cheers,

---

From: Simon Perreault <[email-masked]>
Date: Fri, 23 Nov 2012 13:34:39 +0100

Le 2012-11-19 13:54, Alessandro Rossini a écrit :
> In my opinion [...] a validator would facilitate
> the correct implementation of the vCard format

Not arguing about this.

> since the specification alone may be ambiguous.

This is absolutely wrong. The spec MUST NOT be ambiguous. If it is, then 
it's a spec bug.

Simon