MozillaWiki

VCard4

Revision as of 01:15, 14 December 2010 by Tantek (talk | contribs) (→‎draft 13 section by section review: archived to separate page)

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 (or at least become compatible with) Portable Contacts in order to avoid a schism in identity/profile formats on the web.

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

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

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

recent vcarddav meetings

IETF Vcarddav working group meetings and meeting notes

high level proposal for improving vCard4

Based on a thorough section by section review, the changes and feedback I have for vCard4 draft 13 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 - bad idea. Don't violate DRY. This encourages breaking interop by potentially allowing implementations to look only at the XML or at the actual properties in a vCard. Same on the publishing side.

Potential Extensions:

  • genealogy extension (BIRTH location, DEATH location, DDAY datetime of death, maybe more from GEDCOM)
  • social networking extension (MEMBER, RELATED, maybe more from PoCo)
  • calendar contact extension (FBURL, CALADRURI, CALURI)

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 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)
  • XML - this seems like a total hack and encourages DRY violation.

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:

related

Retrieved from "https://wiki.allizom.org/index.php?title=VCard4&oldid=273380"