I have tried to reach the zen of address book synchronisation for many years. However, I have always experienced that some contact information, especially instant messaging and social networking addresses, gets lost or corrupted during the synchronisation.
The most adopted format for representing contact information is the vCard, whose last version is the 4.0 (see IETF’s RFC 6350, 2011), while the most adopted protocol for accessing contact information is the CardDAV (see in the IETF’s RFC 6352, 2011), which is based on the vCard format. Therefore, I performed a little empirical study of the actual interoperability of the vCard format.
First, I defined a sample contact:
Joe Bloggs me@joebloggs.com +44 20 1234 5678 1 Trafalgar Square, WC2N London, United Kingdom Web: https://joebloggs.com Skype: joe.bloggs Twitter: @joebloggs
Second, I added this contact to four different address books:
- Apple Contacts (formerly Address Book)
- Cobook
- Google Contacts
- Memotoo
Third, I exported each of the address books to a vCard file.
Fourth, I created a sample vCard file based on the vCard format 4.0.
Finally, I compared the exported vCard files and the sample vCard file among each other. The differences between these files blew my mind.
In the following, I show these vCard files and discuss the properties that are not interoperable. Note that I stripped the irrelevant properties and rearranged the remaining properties to make the comparison easier.
Sample vCard file
BEGIN:VCARD VERSION:4.0 N:Bloggs;Joe;;; FN:Joe Bloggs EMAIL;TYPE=home;PREF=1:me@joebloggs.com TEL;TYPE="cell,home";PREF=1:tel:+44 20 1234 5678 ADR;TYPE=home;PREF=1:;;1 Trafalgar Square;London;;WC2N;United Kingdom URL;TYPE=home;PREF=1:https://joebloggs.com IMPP;TYPE=home;PREF=1:skype:joe.bloggs X-SOCIALPROFILE;TYPE=home;PREF=1:twitter:https://twitter.com/joebloggs END:VCARD
In my opinion, the specification of the vCard is substandard. Believe or not, it does not support social networking addresses yet. Even worse, it supports constructs that prevent interoperability, namely grouped properties and non-standard properties.
Grouped properties are properties prefaced with the same group name. They should be grouped together when displayed by an application. I will show examples of grouped properties later.
Non-standard properties are properties defined unilaterally or bilaterally outside the standard. They may be ignored by an application.
For instance, I was forced to represent the Twitter address by a non-standard X-SOCIALPROFILE
property:
X-SOCIALPROFILE;TYPE=home;PREF=1:twitter:https://twitter.com/joebloggs
Apple Contacts (version 7.1)
BEGIN:VCARD VERSION:3.0 N:Bloggs;Joe;;; FN:Joe Bloggs EMAIL;type=INTERNET;type=HOME;type=pref:me@joebloggs.com TEL;type=CELL;type=VOICE;type=pref:+44 20 1234 5678 ADR;type=HOME;type=pref:;;1 Trafalgar Square;London;;WC2N;United Kingdom item1.URL;type=pref:https://joebloggs.com item1.X-ABLabel:_$!<HomePage>!$_ IMPP;X-SERVICE-TYPE=Skype;type=HOME;type=pref:skype:joe.bloggs X-SOCIALPROFILE;type=twitter:https://twitter.com/joebloggs END:VCARD
The vCard file exported by Apple Contacts is only partially based on the vCard format 3.0 (see IETF’s RFC 2425 and RFC 2426, 1998) and its extension for instant messaging (see IETF’s RFC 4770, 2007).
The web address is represented by a standard URL
property grouped together with a non-standard X-ABLabel
property:
item1.URL;type=pref:https://joebloggs.com item1.X-ABLabel:_$!<HomePage>!$_
This issue can be solved by changing the type of the web address from “home page” to “home”. This leads to a vCard file where the web address is represented by a standard URL
property:
URL;type=HOME;type=pref:https://joebloggs.com
The Twitter address is represented by a non-standard X-SOCIALPROFILE
property:
X-SOCIALPROFILE;type=twitter:https://twitter.com/joebloggs
Cobook (version 1.1.6)
BEGIN:VCARD VERSION:3.0 N:Bloggs;Joe;;; FN:Joe Bloggs item1.EMAIL;type=INTERNET:me@joebloggs.com item1.X-ABLabel:_$!<Home>!$_ item2.TEL;type=VOICE:+44 20 1234 5678 item2.X-ABLabel:_$!<Mobile>!$_ item3.ADR:;;1 Trafalgar Square;London;;WC2N;United Kingdom item3.X-ABLabel:_$!<Home>!$_ item4.URL:https://joebloggs.com item4.X-ABLabel:_$!<Home>!$_ item5.IMPP;X-SERVICE-TYPE=Skype:x-apple:joe.bloggs item5.X-ABLabel:_$!<Home>!$_ X-SOCIALPROFILE;type=Twitter;x-user=joebloggs:https://twitter.com/joebloggs END:VCARD
The vCard file exported by Cobook is only partially based on the vCard format 3.0. With the exception of the name, all the contact information is represented by either grouped properties or non-standard properties.
Google Contacts (15 November 2012)
BEGIN:VCARD VERSION:3.0 N:Bloggs;Joe;;; FN:Joe Bloggs EMAIL;TYPE=INTERNET;TYPE=HOME:me@joebloggs.com TEL;TYPE=CELL:+44 20 1234 5678 ADR;TYPE=HOME:;;1 Trafalgar Square;London;;WC2N;United Kingdom item1.URL:https\://joebloggs.com item1.X-ABLabel:_$!<HomePage>!$_ X-SKYPE:joe.bloggs item2.URL:https\://twitter.com/joebloggs item2.X-ABLabel:Twitter END:VCARD
Google Contacts does not support social networking addresses natively, so I was forced to add them as URLs.
The vCard file exported by Google Contacts is only partially based on the vCard format 3.0 (see IETF’s RFC 2425 and RFC 2426, 1998).
The colon in all the URLs is unnecessarily escaped.
Similar to Apple Contacts, the web address is represented by a standard URL
property grouped together with a non-standard X-ABLabel
property:
item1.URL:https\://joebloggs.com item1.X-ABLabel:_$!<HomePage>!$_
I guess this is because Google Contacts specifically targets Apple Contacts when exporting to a vCard file. This issue can be solved by changing the type of the web address from “Home Page” to “Home”. This leads to a vCard file where the web address is represented by a standard URL property:
URL;TYPE=HOME:https\://joebloggs.com
The Skype address is represented by a non-standard X-SKYPE
property:
X-SKYPE:joe.bloggs
The Twitter address is represented by a standard URL property grouped together with a non-standard X-ABLabel
property:
item2.URL:https\://twitter.com/joebloggs item2.X-ABLabel:Twitter
Memotoo (15 November 2012)
BEGIN:VCARD VERSION:2.1 N:Bloggs;Joe;;; FN:Joe Bloggs EMAIL;INTERNET;HOME:me@joebloggs.com TEL;HOME;CELL:+44 20 1234 5678 ADR;HOME:;;1 Trafalgar Square;London;;WC2N;United Kingdom URL;HOME:https://joebloggs.com X-SKYPE-USERNAME:joe.bloggs X-TWITTER:https://twitter.com/joebloggs END:VCARD
The vCard file exported by Memotoo is only partially based on the vCard format 2.1.
The Skype address is represented by a non-standard X-SKYPE-USERNAME
property:
X-SKYPE-USERNAME:joe.bloggs
The Twitter address is represented by a non-standard X-TWITTER
property:
X-TWITTER:https://twitter.com/joebloggs
Conclusion
Given the results of this study, it is not surprising that the import/export of vCard files as well as the synchronisation via CardDAV do not behave as expected most of the time.
Common contact information such as email addresses, telephone numbers, postal addresses, web addresses, and instant messaging addresses can be represented in two ways: using standard properties, or using standard properties grouped together with non-standard properties. The second way is currently used by Apple (and other vendors targeting Apple); it is unnecessary, prevents interoperability, and promotes vendor lock-in.
Other common contact information such as social networking addresses are not supported at all.
So what should be done? Here is my suggestion:
First, the IETF should remove grouped properties and non-standard properties from the specification, since open standards should promote rather than prevent interoperability. Second, the IETF should add social networking properties to the specification. Third, the IETF should provide an official validator for vCard files. Finally, the vendors should implement the last version of the vCard format, and they should do it right.
Update 22 November
I have shared my concerns in IETF’s vCardDAV mailing list. You can follow the thread here.