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
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.
section 4.1
4.1. TEXT
Editorial comment:
Examples use "DESCRIPTION" property - which is not in vCard.
Suggestion: use "NOTE" property instead.
section 4.4
4.4. BOOLEAN
Editorial comment:
TYPO:
"boolean": The "boolean" value type is used to express boolen values.
Should be:
"boolean": The "boolean" value type is used to express boolean values.
section 5.1
5.1. LANGUAGE
Editorial comment:
Please provide a simple example use of the LANGUAGE property parameter, e.g.
ROLE;LANGUAGE=en:teacher ROLE;LANGUAGE=tr:hoca See below ALTID property parameter for how associate these two ROLE properties as being alternatives for the same property instance.
section 5.4
5.4. PREF
Preferred value between 1 and 100 seems a bit arbitrary.
What is the use-case for this?
Also, from a synchronization perspective, picking absolute numbers for indicating preference would seem to make little sense, as the values themselves only make sense relative to other values.
Suggestion: drop this property parameter - it seems like a bad design, and unnecessary.
section 5.5
5.5. ALTID
This seems like a good mechanism for publishing multilingual alternatives on a per-property basis.
I'm interested to see how implementations support this, but overall optimistic about its potential.