VCard4

From MozillaWiki
Jump to: navigation, search

vCard 4 is defined by RFC6350 (text version) and was developed the vcarddav group in IETF as 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.

Also, in some minor 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.

Finally, vCard4 adds a number of features which would make much more sense as orthogonal extensions (groups, calendaring, syncing).

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 stick to a identity-centric core, and 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

vCard 4 draft 22 has been published as RFC6350 (text version)

Changes made in earlier drafts:

2010-12-09: draft 15

  • http://www.ietf.org/internet-drafts/draft-ietf-vcarddav-vcardrev-15.txt (dead link, how does one view and link to versions of IETF drafts?)

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 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/values 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:GROUP - vCard should not expand scope like this. For new kinds of objects new vThings should be created as iCalendar did (e.g. VGROUP), 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:

  • groups extension (MEMBER property, maybe a new VGROUP object)
  • sync extension (CLIENTPIDMAP, etc.)
  • calendar contact extension (FBURL, CALADRURI, CALURI)

4. Improvements to Extensions: (this subsection needs updating per the recent drafts of the genealogy extension - Tantek 23:35, 11 January 2011 (PST)) 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: impacts security. some sites use birth location as a pseudo-security question/answer.

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

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.

Groups extension:

  • MEMBER - related to GROUPs
  • perhaps a new VGROUP object

Synchronization extension:

  • CLIENTPIDMAP
  • PID paramater

Calendar contact extension:

  • FBURL
  • CALADRURI
  • CALURI

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.

section 6.1.4. KIND

6.1.4. KIND

While not the best of ideas, the introduction of this somewhat meta-property may be inevitable to at least distinguish between the existing real world uses and implementations of vCards for organizations, people, and places.

I still object to: GROUP

GROUP should be dropped from 6.1.4 KIND. It may make sense as an extension (similar to LIST and ROBOT suggested by Kevin Marks).

2010-12-20 email sent to vcarddav list accordingly.

Lots of follow-up on the list and disagreement - no conclusion/consensus.

KIND:GROUP and the entire GROUP feature is premature and not ready for a last call.

section 6.1.5. XML

6.1.5. XML

While it has been clarified that this property is NOT for duplicating any vCard properties/values, this still seems like a bit of a hack.

There haven't been sufficient real world use cases presented to justify this property.

What precise (end user scenario) problem is it necessary to (help) solve?

Frankly, this looks like a hack for a specific implementation and not something that belongs in this generic spec.

For instance, people might be using all kinds of other data around contact info but it's not vCard's job to provide some place to stick it.

You could always invent your own X-STORED-EXTRA-DATA field.

Such proprietary data is unlikely to be interoperable anyway, therefore we shouldn't pretend to make it superficially look like it by putting in a specific property for it. Better to leave implementations to use their own opaque proprietary properties for proprietary extensions.

Also, this property will be very confusing to new implementers who may either not even be aware of or not care about the XML serialization, let alone a need to round-trip it thru this format (c.f. XML is dead on the web, killed by JSON at least for APIs. For formats/documents, HTML(5)+microformats have handily beat XML on the Web).

Recommendation: DROP XML property, and encourage implementers who think they need it or want to implement to propose an extension instead.

section 6.2.1. FN

6.2.1. FN

Issue remains from draft 13:

This property has changed from requiring a single instance in vCard3 to requiring one or more instances in vCard4.

There is no advice/guidance/example 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.5. BDAY

6.2.5. BDAY

Issue remains from draft 13:

The expansion of permitting month-day only or year only are both very good and allowing text based "circa" dates is interesting as well. Would also suggest permitting year-month as well, e.g. 1996-04

Recommend updating examples to: 

Examples:

             BDAY:19960415
             BDAY:1996-04
             BDAY:--0415
             BDAY;19531015T231000Z
             BDAY;VALUE=text:circa 1800

and make any updates to the grammar as needed.

section 6.2.6. ANNIVERSARY

6.2.9. ANNIVERSARY

Issue remains from draft 13:

Should allow same date-and-or-time data type as BDAY, including year-only, month-day, year-month etc.

Recommend updating examples to: 

Examples:

             ANNIVERSARY:19960415
             ANNIVERSARY:1996-04
             ANNIVERSARY:--0415
             ANNIVERSARY;19531015T231000Z
             ANNIVERSARY;VALUE=text:circa 1800

section 6.2.7. GENDER

Overall this is a big improvement over the previous "SEX" property.

However, it appears the feedback/proposal for the GENDER property was mistinterpreted or unintentionally oversimplified to a single text string.

This is insufficient. Here is the proposal again, updated with new conventions for the current draft.

GENDER

Purpose: To specify the components of the sex and gender identity of the object the vCard represents.

Value type: A single structured text value. Each component can have a single value.

Cardinality: *1

Special notes: The structured property value corresponds, in sequence, to the sex (biological), and (optional) gender identity. The text components are each optional and separated by the SEMI-COLON character (ASCII decimal 59).

Sex component: The value M stands for "male", F stands for "female", O stands for "other", N stands for "none or not applicable", U stands for "unknown".

Gender identity component: a single text value.

Gender property examples: 

Examples:
             GENDER:M 
             GENDER:F 
             GENDER:M;Fellow 
             GENDER:F;Bird 
             GENDER:O;intersex 
             GENDER:;queer

When you might you see the 'N' value for the sex component, and organization for example: 

Examples
             BEGIN:VCARD
             FN:IETF
             ORG:IETF
             KIND:org
             GENDER:N
             END:VCARD

Notes:

The examples of "Fellow" and "Bird" are taken from the actual user interface of Digg, and see Wikipedia for intersex.

section 6.3.1. ADR

6.3.1. ADR

Just minor typos:

  • "are the plagued with" should be "are plagued with"
  • 'a "street" component' should be 'a "street address" component'

section 6.4.1. TEL

6.4.1. TEL

The new examples look reasonable.

One concern, I like the "ext" parameter used in the example, but don't see how it is represented in the grammar for the property. Hopefully this is an unintended omission and the TEL property grammar can be adjusted to allow for the "ext" parameter.

The problematic PREF parameter still exists. I don't expect it to work for interop/sync as specified.

In addition the notion of PREF is badly outdated and needs to be rethought *across* different types of communications, not just among instances of a specific type of communication (e.g. what is preferred: phone vs email, not just which phone number).

Recommend dropping PREF parameter as it is a poor design. Better not to have it than have a poor design that gives implementers backward compat headaches later.

section 6.4.2. EMAIL

6.4.2. EMAIL

Issue remains from draft 13:

The problematic PREF parameter still exists. I don't expect it to work for interop/sync as specified.

In addition the notion of PREF is badly outdated and needs to be rethought *across* different types of communications, not just among instances of a specific type of communication (e.g. what is preferred: phone vs email, not just which phone number).

Recommend dropping PREF parameter as it is a poor design. Better not to have it than have a poor design that gives implementers backward compat headaches later.

section 6.4.3. IMPP

6.4.3. IMPP

Same problems with PREF parameter.

section 6.4.4. LANG

6.4.4. LANG

Issue remains from draft 13:

I recommend using the full property name LANGUAGE instead, per re-use from OpenID.

The term "lang" is already a commonly used HTML attribute that appears to be similar in syntax (e.g. takes a single language-tag value) but is quite different in meaning, in that it indicates the language of the text being marked up, rather than a preference for communication.

section 6.5.1. TZ

6.5.1. TZ

Issues remain from draft 13:

Forward-looking references to potential efforts don't belong in a specification. E.g. "Efforts are currently being directed at creating a standard URI scheme for expressing time zone information. Usage of such a scheme would ensure a high level of interoperability between implementations that support it."

Cardinality should be *1 - how can a vCard object be in multiple time zones?

Even if it could - it would be very confusing and no guidance is provided to implementations for how to support a vCard object being in multiple time zones.

In addition, the property should drop the language about "you shouldn't use UTC offset".

In practice that may be quite useful ("is it the middle of the night in london right now?") and avoids all the complexity of full timezone support.

In PortableContacts we chose to ONLY allow utcOffset and and in microformats we only allow UTC offsets for datetime properties - so this is an interop issue.

It may be ok to leave in a warning, saying something like: "of course, this may not be perfectly accurate since differences in when/whether daylight saving time is observed may cause it to be off a bit" (editorial discretion accepted).

section 6.5.2. GEO

6.5.2. GEO

Issue remains from draft 13:

Same cardinality issue as TZ.

Cardinality should be *1 - how can a vCard object be in multiple specific locations?

Even if it could - it would be very confusing and no guidance is provided to implementations for how to support a vCard object being in multiple geo locations.

6.6.3. LOGO

Issues remain from draft 13:

In practice this property has caused confusion with respect to the PHOTO property. Which should you use when?

Also, why is this included in the Organizational Properties section rather than alongside PHOTO?

If there is a more specific semantic to be applied, e.g. this is the LOGO for the organization that the person the vCard object represents works for, then that specific semantic should be explicitly mentioned.

Recommend also providing an example with both LOGO and PHOTO that clearly demonstrates the proper/intended use of each.

section 6.6.5. MEMBER

6.6.5. MEMBER

Issue remains from draft 13:

Groups should not be in vCard but rather should be in another spec/schema, or an extension at least.

As noted in previous KIND property, the GROUP functionality has serious problems and lacks consensus - is not ready for last call.

Recommend drop this property.

We should cut this feature and those pursuing it can continue doing so as an extension.

section 6.6.6. RELATED

6.6.6. RELATED

This is looking much better, with the adoption of the canonical XFN vocabulary (rather than inventing a new vocabulary).

I suggest also adding a note encouraging those wanting to extend it to contribute and particiate in the XFN brainstorming page.

http://microformats.org/wiki/xfn-brainstorming


section 6.7.1. CATEGORIES

6.7.1. CATEGORIES

Issue remains from draft 13:

Just like TEL has been revised to accepted URL values, CATEGORIES should be as well, for the same reason.

There's an existing standard, rel-tag, that defines and encourages the use of URLs for tags/categories as a way of providing scoping/discovery/linking functionality to tags/categories.

Suggestion: explicitly allow URIs as text values to represent specifically scoped tags, with the last path segment of the URI representing the "keyword" of the tag, as specified by the rel-tag specification http://microformats.org/wiki/rel-tag

section 6.9. Calendar Properties

6.9. Calendar Properties

Issue remains from draft 13:

This whole section should be dropped from core and placed into an extension.


section 7. Synchronization

7. Synchronization

Issue remains from draft 13:

This entire section, the PID property, and the CLIENTPIDMAP property should all be moved to an extension spec.


past reviews critiques proposals

draft 13 section by section review

Moved to separate page:

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.

related

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