VCard4

This article is a stub. You can help MozillaWiki by expanding it.

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 breaks backward compatibility with vCard3.

In addition, 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 Portable Contacts in order to avoid a schism in identity/profile formats on the web.

— Tantek 17:50, 14 August 2010 (PDT)

current draft

http://www.ietf.org/internet-drafts/draft-ietf-vcarddav-vcardrev-13.txt

recent vcarddav meetings

• 2010-07-28 10h30-11h30 IETF Vcarddav working group, IETF 78 meeting, Maastricht, NL
  • http://www.ietf.org/mail-archive/web/vcarddav/current/msg01631.html

issues

divergence from vCard3

• N property
  • dropped 'additional-name's - this makes it non-backward compat with vCard3

divergence from Portable Contacts

• SEX (in vCard4) vs GENDER (in PoCo)
  • different property names and values that don't necessarily map
  • this might actually be ok if we document how to keep and use *both* properties, each for a specific purpose, that is:
    • SEX - biological value (enum: (M)ale, (F)emale, (O)ther, (N)one)
    • GENDER - gender identity value (a string)

new properties not used by address books

New properties in vCard4 were supposed to have some basis in existing address book features. The following properties do not appear to meet this criteria:

• DDAY - date of death
  • opinion: +0 - 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). mostly harmless, may be interesting to include. I'm ok with this property going into the public last call and seeing what implementations do with it, but want to point out that there is no basis for inclusion based on existing address book features / interfaces. Tantek 18:36, 14 August 2010 (PDT)
• BIRTH - birth location
  • opinion: -1 - this seems like a bad idea. many sites use birth location as a pseudo-security question/answer. What is the use case for keeping track of other people's birth locations in your address book? (nevermind that this property is also poorly worded - something like BLOCATION - reusing B prefix from BDAY and LOCATION property from iCalendar - would be better) vCard4 should drop this property. Tantek 18:36, 14 August 2010 (PDT)
• DEATH - death location (this is not their grave location, but rather the place they died)
  • opinion: -1 - again, seems like a bad idea. What is the use case for keeping track of other people's death locations in your address book? (nevermind that this property is also poorly worded - something like DLOCATION - reusing D prefix from DDAY and LOCATION property from iCalendar - would be better) vCard4 should drop this property. Tantek 18:36, 14 August 2010 (PDT)

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)
  • a "thing" (like a conference room projector
  • 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 to be evaluated

The following new properties are not fully understood and need additional analysis to determine if they have problems.

• XML - this seems like a total hack.
• MEMBER - related to GROUPs - doesn't seem to belong in vCard
• RELATED
• CLIENTPIDMAP
• FBURL
• CALADRURI
• CALURI

draft 13 section by section review

section 3.1

3.1. Line Delimiting and Folding

Editorial comment:

Examples use "DESCRIPTION" property - which is not in vCard.

Suggestion: use "NOTE" property instead.

related

• Standards