MozillaWiki

VCard4: Difference between revisions

Page Discussion

VCard4 (view source)

Revision as of 01:58, 14 December 2010

631 bytes added ,  14 December 2010
update current draft link to draft 15, update issues overview
(→‎draft 13 section by section review: archived to separate page)
(update current draft link to draft 15, update issues overview)
Line 1: Line 1:
vCard 4 is work in progress (by the vcarddav group in IETF) on an update/replacement to/for vCard 3, RFC 2426.
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 many ways vCard4 is a big step forward from vCard3 in terms of a standard for exchanging contact information.


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.
Backward compatibility with vCard3 is still a concern and one that we're working hard to help improve.
 
Also, in some 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.


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.
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.
Line 9: Line 11:
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.
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.


— [[User:Tantek|Tantek]] 17:50, 14 August 2010 (PDT)
— [[User:Tantek|Tantek]]


== vcarddav ==
== vcarddav ==
Line 25: Line 27:


== current draft ==
== current draft ==
http://www.ietf.org/internet-drafts/draft-ietf-vcarddav-vcardrev-13.txt
2010-12-09: draft 15:
* http://www.ietf.org/internet-drafts/draft-ietf-vcarddav-vcardrev-15.txt


== recent vcarddav meetings ==
== recent vcarddav meetings ==
Line 36: Line 39:
== high level proposal for improving vCard4 ==
== 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:
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
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
Line 50: Line 53:
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.:
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.
* 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.
* XML - obsolete bad idea. From a programmatic perspective the web has moved on from XML to JSON. See [http://blog.jclark.com/2010/11/xml-vs-web_24.html James Clark: XML vs the Web] (2010-11-24)


Potential Extensions:
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)
* social networking extension (MEMBER, RELATED, maybe more from PoCo)
* calendar contact extension (FBURL, CALADRURI, CALURI)
* calendar contact extension (FBURL, CALADRURI, CALURI)
4. Improvements to Potential Extensions
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 [http://en.wikipedia.org/wiki/Normandy_landings 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: hurts security. many sites use birth location as a pseudo-security question/answer.


== issues ==
== issues ==
Line 62: Line 82:
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.
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 ===
=== divergence from GENDER proposal ===
* N property  
* 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.
** dropped 'additional-name's - this makes it non-backward compat with vCard3
 
=== divergence from Portable Contacts ===
* Summary of previous proposal:
* SEX (in vCard4) vs GENDER (in PoCo)
** SEX - biological value (enum: (M)ale, (F)emale, (O)ther, (N)one, (U)nknown)
** different property names and values that don't necessarily map
** GENDER - gender identity value (a string)
** 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 ====
==== see also 2009 Joseph Smarr post ====
Joseph Smarr wrote about [http://josephsmarr.com/2009/03/25/portable-contacts-and-vcarddav-ietf-74/ Portable Contacts and vCardDAV (IETF 74)] on his blog in March of 2009 also covering challenges/issues around vCard4 vs PoCo.
Joseph Smarr wrote about [http://josephsmarr.com/2009/03/25/portable-contacts-and-vcarddav-ietf-74/ Portable Contacts and vCardDAV (IETF 74)] on his blog in March of 2009 also covering challenges/issues around vCard4 vs PoCo.
 
* need to review that post to see if draft 15 handles the problems mentioned.
=== 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. [[User:Tantek|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. [[User:Tantek|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. [[User:Tantek|Tantek]] 18:36, 14 August 2010 (PDT)


=== other properties and problems ===
=== 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)
* 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 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. [[User:Tantek|Tantek]] 18:36, 14 August 2010 (PDT)
** 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. [[User:Tantek|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 ===
=== other new properties that should go into extension instead ===
Line 109: Line 115:


== draft 13 section by section review ==
== draft 13 section by section review ==
Moved to separate page:
Moved to separate page:


Tantek
canmove, Confirmed users
2,675

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/273386"