VCard4: Difference between revisions

Jump to navigation Jump to search

VCard4 (view source)

Revision as of 01:58, 11 January 2011

10,393 bytes added ,  11 January 2011
finally cleaned up the rest of my review (over past couple of weeks) and posting it here for consideration.
(→‎draft 15 section by section review: add 6.1.4 KIND feedback update)
(finally cleaned up the rest of my review (over past couple of weeks) and posting it here for consideration.)
Line 29: Line 29:
2010-12-09: draft 15:
2010-12-09: draft 15:
* http://www.ietf.org/internet-drafts/draft-ietf-vcarddav-vcardrev-15.txt
* http://www.ietf.org/internet-drafts/draft-ietf-vcarddav-vcardrev-15.txt
'''NOTE: draft 15 is greatly improved over draft 13 and I'm in the process of updating the rest of this page accordingly. [[User:Tantek|Tantek]] 18:44, 15 December 2010 (PST)'''


Changes made since draft 13:
Changes made since draft 13:
Line 107: Line 105:
The following new properties should not be in core vCard and should be considered for extensions instead.
The following new properties should not be in core vCard and should be considered for extensions instead.


Social Networking extension:
Groups extension:
* MEMBER - related to GROUPs
* MEMBER - related to GROUPs
* RELATED
* perhaps a new VGROUP object


Synchronization extension:
Synchronization extension:
Line 142: Line 140:


2010-12-20 email sent to vcarddav list accordingly.
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?
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 [https://wiki.mozilla.org/VCard4-draft-13-review#section_6.2.1._FN 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 [https://wiki.mozilla.org/VCard4-draft-13-review#section_6.2.5._BDAY 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:
<pre><nowiki>
Examples:
            BDAY:19960415
            BDAY:1996-04
            BDAY:--0415
            BDAY;19531015T231000Z
            BDAY;VALUE=text:circa 1800
</nowiki><pre>
and make any updates to the grammar as needed.
=== section 6.2.6.  ANNIVERSARY ===
6.2.9.  ANNIVERSARY
Issue [https://wiki.mozilla.org/VCard4-draft-13-review#section_6.2.9._ANNIVERSARY 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:
<pre><nowiki>
Examples:
            ANNIVERSARY:19960415
            ANNIVERSARY:1996-04
            ANNIVERSARY:--0415
            ANNIVERSARY;19531015T231000Z
            ANNIVERSARY;VALUE=text:circa 1800
</nowiki></pre>
=== section 6.2.7. GENDER  ===
Overall this is a big improvement over the [https://wiki.mozilla.org/VCard4-draft-13-review#section_6.2.10._SEX previous "SEX" property].
However, it appears the [https://wiki.mozilla.org/VCard4-draft-13-review#GENDER 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:
<pre><nowiki>
Examples:
            GENDER:M
            GENDER:F
            GENDER:M;Fellow
            GENDER:F;Bird
            GENDER:O;intersex
            GENDER:;queer
</nowiki></pre>
When you might you see the 'N' value for the sex component, and organization for example:
<pre><nowiki>
Examples
            BEGIN:VCARD
            FN:IETF
            ORG:IETF
            KIND:org
            GENDER:N
            END:VCARD
</nowiki></pre>
Notes:
The examples of "Fellow" and "Bird" are taken from the actual [http://microformats.org/wiki/gender-examples user interface of Digg], and see [http://en.wikipedia.org/wiki/Intersex#Intersex_identity 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 [https://wiki.mozilla.org/VCard4-draft-13-review#section_6.4.2._EMAIL 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 [https://wiki.mozilla.org/VCard4-draft-13-review#section_6.4.5._LANG 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 [https://wiki.mozilla.org/VCard4-draft-13-review#section_6.5.1._TZ 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.
=== section 6.5.2.  GEO ===
6.5.2.  GEO
Issue [https://wiki.mozilla.org/VCard4-draft-13-review#section_6.5.2._GEO 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.
=== section 6.6.3.  LOGO ===
6.6.3.  LOGO
Issues [https://wiki.mozilla.org/VCard4-draft-13-review#section_6.6.3._LOGO 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 [https://wiki.mozilla.org/VCard4-draft-13-review#section_6.6.5._MEMBER 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 [https://wiki.mozilla.org/VCard4-draft-13-review#section_6.7.1._CATEGORIES 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 [https://wiki.mozilla.org/VCard4-draft-13-review#section_6.9._Calendar_Properties remains from draft 13]:
This whole section should be dropped from core and placed into an extension.
=== section 7.  Synchronization ===
7.  Synchronization
Issue [https://wiki.mozilla.org/VCard4-draft-13-review#section_7._Synchronization remains from draft 13]:
This entire section, the PID property, and the CLIENTPIDMAP property should all be moved to an extension spec.


== related ==
== related ==
* [[Standards]]
* [[Standards]]
Tantek
canmove, Confirmed users
2,675

edits

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

Navigation menu