VCard4
vCard 4 is work in progress (by the vcarddav group in IETF) on an update/replacement to/for vCard 3, RFC 2426.
In many ways vCard4 is a big step forward from vCard3 in terms of a standard for exchanging contact information.
Backward compatibility with vCard3 is still a concern and one that we're working hard to help improve.
Also, in some ways vCard4 appears to be evolving in a different direction from (and in some way incompatibly with) the nascent Portable Contacts standard, which itself evolved incrementally and fairly cleanly/compatibly from hCard which was based on vCard3.
This page documents known vCard4 issues from our analysis of the work in progress, in comparison to hCard/vCard3 and in comparison to Portable Contacts.
Our goal is to encourage vCard4 to converge with (or at least become compatible with) Portable Contacts in order to avoid a schism in identity/profile formats on the web.
— Tantek
vcarddav
The IETF VCARDDAV was formed to develop vCard4 among other things.
Mailing list:
Wiki: unknown. Unofficial vCard related wiki documentation has been maintained by microformats.org (and was incorporated as feedback into early drafts of vCard4)
current draft
2010-12-09: draft 15:
NOTE: draft 15 is greatly improved over draft 13 and I'm in the process of updating the rest of this page accordingly. Tantek 18:44, 15 December 2010 (PST)
Changes made since draft 13:
recent vcarddav meetings
IETF Vcarddav working group meetings and meeting notes
- 2010-11-10 15h10-16h10 IETF 79 meeting, Beijing, China
- 2010-07-28 10h30-11h30 IETF 78 meeting, Maastricht, NL
high level proposal for improving vCard4
Based on a thorough section by section review, the changes and feedback I have for vCard4 fall into a general outline as follows:
1. Explicitly state as a goal to have vCard4 be reasonably backward compatible (i.e. with current implementations) of vCard3, both syntactically, and from a schema perspective (e.g. don't mess with structure of properties like N). This kind of practical backward compat enabled publishers to start posting vCard3 even when most consuming applications still only supported vCard2.1. The presence of vCard3 data then encouraged consuming applications over time to adopt it as well. I'd like to see the same successful adoption occur for vCard4.
2. Keep the vCard4 core set of properties down to a minimum that has been well established either in:
- Popular address book programs (e.g. ANNIVERSARY)
- Current well adopted mature RFCs (e.g. IMPP)
- Common additions by OpenID / Portable Contacts that have seen adoption (e.g. SEX/GENDER, LANGUAGE, ACCOUNTS)
I believe this too will encourage better vCard4 adoption.
3. Drop other new vCard4 properties from the core and if they seem to make sense, move them to extension specifications instead where they can prove themselves out, e.g.:
- KIND - vCard should not expand scope like this. For new kinds of objects new vThings should be created, and can be, outside the vCard spec.
- XML - obsolete bad idea. From a programmatic perspective the web has moved on from XML to JSON. See James Clark: XML vs the Web (2010-11-24)
Potential Extensions:
- social networking extension (MEMBER, RELATED, maybe more from PoCo)
- calendar contact extension (FBURL, CALADRURI, CALURI)
4. Improvements to Potential Extensions The following have been dropped from vCard4 because there is little/no implementation or real world examples of address book user interfaces using them. Nonetheless, they may be considered for development as extension specifications and as such deserve some feedback.
- genealogy extension (BIRTH location, DEATH location, DDAY datetime of death, maybe more from GEDCOM)
- DDAY
- Use case: this is parallel to the existing BDAY field, and could help solve longstanding UI problems with address book entries for people who have passed away (and social network profiles as well that are memorialized).
- ISSUE: bad name. "DDAY" already has a commonly known meaning of the Normandy Landings (usually written "D-Day". Here are some suggested alternatives
- DECEASED - term is used in the fictional profile user interface of a government accounting department in the movie "Hackers". And even though this is a fictional example (there are others, like in the movie "Amelie" a scene is shown where a weeping gentleman is erasing a recently deceased friend from his address book).
- ISSUE: No real world implementation. There is no documentation of any basis for inclusion based on existing address book features / interfaces.
- DEATH - death location (this is not their grave location, but rather the place they died)
- ISSUE: Lack of address book use case. What is the use case for keeping track of other people's death locations in your address book?
- ISSUE: bad name, too generic, this property is poorly worded. What does genealogy software currently use for the label for the location of death? (assuming any genealogy software actually supports that - which should be documented)
- maybe something like DLOCATION - using D prefix and reusing LOCATION property from iCalendar - would be better.
- BIRTH
- ISSUE: Lack of address book use case. What is the use case for keeping track of other people's birth locations in your address book?
- ISSUE: again bad name, too generic, this property is poorly worded. What does genealogy software currently use for the label for the location of birth? (assuming any genealogy software actually supports that - which should be documented)
- maybe something like BLOCATION - reusing B prefix from BDAY and LOCATION property from iCalendar - would be better
- ISSUE: hurts security. many sites use birth location as a pseudo-security question/answer.
- DDAY
issues
This is a rough list of issues that is incomplete.
Please see the section by section review below that has both a much more detailed and comprehensive coverage of the problems in the current vCard4 draft13 with suggestions for improvement too.
divergence from GENDER proposal
- GENDER property as proposed in feedback on draft 13 included 2 components, an enum and an plain text field. draft 15 GENDER property is only a single plain text field.
- Summary of previous proposal:
- SEX - biological value (enum: (M)ale, (F)emale, (O)ther, (N)one, (U)nknown)
- GENDER - gender identity value (a string)
see also 2009 Joseph Smarr post
Joseph Smarr wrote about Portable Contacts and vCardDAV (IETF 74) on his blog in March of 2009 also covering challenges/issues around vCard4 vs PoCo.
- need to review that post to see if draft 15 handles the problems mentioned.
other properties and problems
- KIND property - this seems like the wrong way to add new data types. vCard4 appears to be extended to represent (in addition to people and organizations)
- a group (of vCard items)
- opinion: -1 - this seems like a bad way to extend type information. shoehorning all types of objects into being "vCards" seems like a really bad design decision. the MIME/Content type mechanism should be used instead. e.g. create a vGroup and vThing if necessary instead. it is also unnecessary for differentiating a person vs organization - that is organization is already inferred by FN == ORG. thus vCard4 should drop this property. Tantek 18:36, 14 August 2010 (PDT)
other new properties that should go into extension instead
The following new properties should not be in core vCard and should be considered for extensions instead.
Social Networking extension:
- MEMBER - related to GROUPs
- RELATED
Synchronization extension:
- CLIENTPIDMAP
- PID paramater
Calendar contact extension:
- FBURL
- CALADRURI
- CALURI
draft 13 section by section review
Moved to separate page:
draft 15 section by section review
section 5.6
5.6. TYPE
Same issue(s) as draft 13 section 5.7. No specific comments. General comment - type seems like a catch-all of sorts - not very well designed. Some of the uses are quite flawed. E.g. the notions of "work" and "home" have not worked well in practice. In particular "work" doesn't make much sense given that there is an "ORG" property with which any work email/phone/address should be associated, rather than just implied.