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 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)

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.

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 to associate these two ROLE properties as being alternatives for the same property value.

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.

section 5.6

5.6. PID

This definition is very short and abstract and is not very useful out of context as it is. There should be at least one concrete example, otherwise move this section to "Section 7" since that's where it says there are "more details on its usage".

My recommendation just reading its description would be to drop this new property parameter.

section 5.7

5.7. TYPE

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.

section 5.8

5.8. CALSCALE

In practice have there been any address books that implement a CALSCALE *other* than the specific default of "gregorian"?

I think this should be dropped until there is at least some evidence produced that there is address book software out there that bothers to even try to support part of the existing vCard3 spec and that provides a non-gregorian calendar scale user interface.

Recommended we drop this property parameter.

section 5.9

5.9. SORT-AS

Having this as a property *parameter* seems like an improvement over the previous 'sort-string' property which I've not really seen used in the wild.

section 5.10

5.10. GEO

This makes sense as an addition/refinement to the ADR property, to assign a specific lat/long to a particular address, especially when multiple addresses are involved. hCard backward compat will be a little interesting but I'm sure we can figure it out.

section 5.11

5.11. TZ

Makes sense in the same way as GEO parameter.

section 5.12

5.12. VERSION

I don't think this is necessary, and in fact encourage future breaking as well as pushing the burden of handling multiple versions of a property onto implementations.

Let's NOT add this, and instead work hard to:

• specify forward compatible parsing rules (i.e. ignore any params you don't recognize)
• keep properties backward compatible in general, just adding detail params (like TZ and GEO) where it progressively enhances the property without breaking any existing semantics.

section 5.13

5.13. FMTTYPE

This seems like a reasonable property parameter addition for binary value types.

section 6.

The current cardinality shorthands are cryptic, please use something more typically readable, e.g.:

• (1) - exactly one instance must be present
• (1-n) - at least one instance must be present
• (0-1) - at most one instance may be present
• (0-n) - any number of instances may be present

section 6.1

6.1. General Properties

no content.

section 6.1.1. BEGIN

no comment. seems compatible.

section 6.1.2. END

no comment. seems compatible.

section 6.1.3. SOURCE

6.1.3. SOURCE

no comment. seems compatible.

section 6.1.4. KIND

6.1.4. KIND

I think this is a really bad idea.

While existing usage of vCard3 for both people and organizations is something we have to support moving forward, I really don't want to see this expanded further (with the possible exception of a named location - which we've found utility for with hCard as well).

Object to: group, thing

Groups should not just be a form of vCard. And thing? I think both of these are horrible abuse of existing vCard semantics.

If you want to add new objects, let's add new objects like a vGroup or a vThing etc. But please let's not bloat vCard with these things.

section 6.1.5. XML

6.1.5. XML

I think this is totally unnecessary and a bad idea because it violates DRY.

Seriously? An XML property that represents all the rest of the data in the same vCard? Ugh. Which do you trust? The XML or the actual vCard properties?

section 6.2. Identification Properties

6.2. Identification Properties

no comment on intro.

section 6.2.1. FN

6.2.1. FN

The possibility of having multiple FNs is introduced, which seems both reasonable and useful in practice from personal experience with developing address book code.

However, there is no advice/guidance given regarding how to treat multiple FNs and thus I fear this new capability may introduce some interoperability problems.

I suggest some wording and examples clarifying what the purpose may be for multiple FNs, e.g. multiple ways of displaying a name (perhaps some with additional names, some without), or multiple ways (character sets? languages?) to write a name (e.g. a Japanese name may be written with Kanji or transliterated Hiragana).

section 6.2.2. N

Not requiring an N is a big improvement.

The new N structure is different enough from vCard3 to be problematic.

Minor change:

• Use "family name" as a primary (perhaps with "also known as surname") since vCard3 referred to "family name", and hCard adopted that wording in the subproperty "family-name".

Major changes:

• Consider allowing multiple family names. In my experience giving microformats workshops around the world, I have found that there are languages/cultures that actually use multiple family names in practice, e.g. in Spain.
• Restore the "additional name" structural component that was in vCard3 for better schematic compatibility.
• Am ok with multiple Given Names as that does reflect common practice.

section 6.2.3. NICKNAME

6.2.3. NICKNAME "belonging to a person, place, or thing" - avoid such itemizations of what a vCard could represent as it will be (is) a maintenance nightmare.

Use "belonging to the object the vCard represents" instead.

section 6.2.4. PHOTO

6.2.4. PHOTO

Seems about the same as vCard3.

Provide a data: URI example as implementations do seem to support that, and note how the data URI may contain the content/MIME-type and thus that can be used instead of the FMTTYPE param. For reference:

http://en.wikipedia.org/wiki/Data_URI_scheme

data:[<MIME-type>][;charset=<encoding>][;base64],<data>

section 6.2.5. BDAY

6.2.5. BDAY

The expansion of permitting month-day only or year only are both very good. Would also suggest permitting year-month as well, e.g. 1996-04

section 6.2.6. DDAY

6.2.6. DDAY

No evidence of address books that support this property have been presented.

This would make more sense as part of a "genealogy" extension to vCard4 rather than part of the core.

That being said:

I for one have personally found it there to be a user-interface challenge in managing the contact information in an address book of people that have passed away.

While some may suggest simply deleting such entries, I don't think that reflects that necessary history/attachment/notes of common usage of such address book entries.

However, given that address books are often used to "auto-fill/suggest" things like email program "To:" fields etc. (e.g. Mail.app on MacOSX with the Address Book app), it makes sense to provide some way to mark a contact as deceased so that they don't show up in auto-fill/suggest user interfaces.

A DDAY property could serve as a proxy for such a "deceased" checkbox on an entry.

It should explicitly allow the same data type as BDAY, and provide examples accordingly.

Thus while there is no existing evidence of address books that provide this kind of user interface feature, I believe this may be an instance where it makes sense to add this field, given the *address book* use cases documented above.

I would also be ok postponing this property to a "genealogy" extension.

section 6.2.7. BIRTH

6.2.7. BIRTH

No evidence of address books that support this property have been presented.

This would make more sense as part of a "genealogy" extension to vCard4 rather than part of the core.

And this is a horrible property name to boot for a "location".

Recommendation: drop from vCard4.

section 6.2.8. DEATH

6.2.8. DEATH

No evidence of address books that support this property have been presented.

This would make more sense as part of a "genealogy" extension to vCard4 rather than part of the core.

And this is a horrible property name to boot for a "location".

Recommendation: drop from vCard4.

related

• Standards