canmove, Confirmed users
2,675
edits
VCard4: Difference between revisions
update summary based on having a "done" RFC
(→issues: update draft # ref) |
(update summary based on having a "done" RFC) |
||
| (7 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
vCard 4 is | vCard 4 is defined by [http://tools.ietf.org/html/rfc6350 RFC6350] ([http://www.ietf.org/rfc/rfc6350.txt 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. | In many ways vCard4 is a big step forward from vCard3 in terms of a standard for exchanging contact information. | ||
| Line 27: | Line 27: | ||
== current draft == | == current draft == | ||
vCard 4 draft 22 has been published as [http://tools.ietf.org/html/rfc6350 RFC6350] ([http://www.ietf.org/rfc/rfc6350.txt text version]) | |||
Changes made | Changes made in earlier drafts: | ||
* [http://tools.ietf.org/rfcdiff?url2=draft-ietf-vcarddav-vcardrev-22 draft 22 diffs from 21] | |||
* [http://tools.ietf.org/rfcdiff?url2=draft-ietf-vcarddav-vcardrev-21 draft 21 diffs from 20] | |||
* [http://tools.ietf.org/rfcdiff?url2=draft-ietf-vcarddav-vcardrev-20 draft 20 diffs from 19] | |||
* [http://tools.ietf.org/rfcdiff?url2=draft-ietf-vcarddav-vcardrev-19 draft 19 diffs from 18] | |||
* [http://tools.ietf.org/rfcdiff?url2=draft-ietf-vcarddav-vcardrev-18 draft 18 diffs from 17] | |||
* [http://tools.ietf.org/rfcdiff?url2=draft-ietf-vcarddav-vcardrev-17 draft 17 diffs from 16] | |||
* [http://tools.ietf.org/rfcdiff?url2=draft-ietf-vcarddav-vcardrev-16 draft 16 diffs from 15] | |||
* [http://tools.ietf.org/rfcdiff?url2=draft-ietf-vcarddav-vcardrev-15 draft 15 diffs from 14] | * [http://tools.ietf.org/rfcdiff?url2=draft-ietf-vcarddav-vcardrev-15 draft 15 diffs from 14] | ||
* [http://tools.ietf.org/rfcdiff?url2=draft-ietf-vcarddav-vcardrev-14 draft 14 diffs from 13] | * [http://tools.ietf.org/rfcdiff?url2=draft-ietf-vcarddav-vcardrev-14 draft 14 diffs from 13] | ||
2010-12-09: draft 15 | |||
* <nowiki>http://www.ietf.org/internet-drafts/draft-ietf-vcarddav-vcardrev-15.txt</nowiki> (dead link, how does one view and link to versions of IETF drafts?) | |||
== recent vcarddav meetings == | == recent vcarddav meetings == | ||
| Line 60: | Line 69: | ||
Potential Extensions: | Potential Extensions: | ||
* | * groups extension (MEMBER property, maybe a new VGROUP object) | ||
* sync extension (CLIENTPIDMAP, etc.) | |||
* calendar contact extension (FBURL, CALADRURI, CALURI) | * calendar contact extension (FBURL, CALADRURI, CALURI) | ||
4. Improvements to | 4. Improvements to Extensions: | ||
(this subsection needs updating per the recent drafts of the genealogy extension - [[User:Tantek|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. | 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) | * genealogy extension (BIRTH location, DEATH location, DDAY datetime of death, maybe more from GEDCOM) | ||
| Line 80: | Line 90: | ||
*** 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) | *** 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 | **** maybe something like BLOCATION - reusing B prefix from BDAY and LOCATION property from iCalendar - would be better | ||
*** ISSUE: | *** ISSUE: impacts security. some sites use birth location as a pseudo-security question/answer. | ||
== issues == | == issues == | ||
| Line 140: | Line 150: | ||
6.1.5. XML | 6.1.5. XML | ||
While it has been clarified that this property is NOT for duplicating any vCard properties/values, | 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. | 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? | 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. [http://blog.jclark.com/2010/11/xml-vs-web_24.html 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. | Recommendation: DROP XML property, and encourage implementers who think they need it or want to implement to propose an extension instead. | ||
| Line 176: | Line 196: | ||
BDAY;19531015T231000Z | BDAY;19531015T231000Z | ||
BDAY;VALUE=text:circa 1800 | BDAY;VALUE=text:circa 1800 | ||
</nowiki><pre> | </nowiki></pre> | ||
and make any updates to the grammar as needed. | and make any updates to the grammar as needed. | ||
| Line 305: | Line 325: | ||
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. | 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 === | === section 6.5.2. GEO === | ||