VCard4-draft-13-review: Difference between revisions

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.2.  N ===

* Restore the "additional name" structural component that was in vCard3 for better schematic compatibility.

* Am ok with multiple Given Names as that does reflect common practice.

=== section 6.2.3.  NICKNAME ===

Use "belonging to the object the vCard represents" instead.

=== section 6.2.4.  PHOTO ===

<nowiki>data:[<MIME-type>][;charset=<encoding>][;base64],<data></nowiki>

=== section 6.2.5.  BDAY ===

The expansion of permitting month-day only or year only are both very good.  Would also suggest permitting year-month as well, e.g. 1996-04

=== section 6.2.6.  DDAY ===

I would also be ok postponing this property to a "genealogy" extension.

=== section 6.2.7.  BIRTH ===

Recommendation: drop from vCard4.

=== section 6.2.8.  DEATH ===

Recommendation: drop from vCard4.

=== section 6.2.9.  ANNIVERSARY ===

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

=== section 6.2.10. SEX  ===

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.  Delivery Addressing Properties ===

* deprecate extended address (keep it in the structure, but suggest an empty string)

* encourage multiline (lines delimited with the COMMA character as the draft suggests) in the "street address" subproperty, with the first line being the actual street address with number and name of street, or if there is none (e.g. in the case of a PO BOX only address), simply include the replacement that you would on a mailing label, corresponding to the "address line 1" field that we see on so many forms.

=== section 6.3.2.  LABEL ===

Seems unchanged from vCard3. Better to deprecate the LABEL property and add a LABEL parameter to the ADR property.

=== section 6.4.  Communications Properties ===

Intro sentence needs to be reworded - total awkward run-on.

=== section 6.4.1.  TEL ===

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).

=== section 6.4.2.  EMAIL ===

Same comment about PREF.  Good to see the useless TYPE param dropped.

=== section 6.4.3.  IMPP ===

Seems like a reasonable addition, and good example of an extension being tried for a new feature before inclusion in the core.  A lesson to be applied to the genealogy properties that have been proposed.

=== section 6.4.4.  LANG ===

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.  Geographical Properties ===

Cardinality should be (0-1) - how can a vCard object be in multiple time zones?

=== section 6.5.2.  GEO ===

Cardinality should be (0-1) - how can a vCard object be in multiple locations?

=== section 6.6.  Organizational Properties ===

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

=== section 6.6.4.  ORG ===

Recommend drop this property.

=== section 6.6.6.  RELATED ===

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

=== section 6.7.  Explanatory Properties ===

Organizationally I'm not sure this makes much sense.  Most of these apply to the vCard object as a whole and are perhaps identity related and could be grouped into section 6.2.

=== section 6.7.1.  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.7.2.  NOTE ===

Would be nice to allow whole dates as well (without time).

=== section 6.7.5.  SOUND ===

Lacking an example with a use-case, this property should be dropped.

=== section 6.7.8.  URL ===

The SORT-AS parameter MAY be applied to this property.

=== section 6.7.9.  VERSION ===

I don't think it is clear how to use it, and it should be dropped from vCard4 (or at least deprecated/ignored).

=== section 6.8.2.  KEY ===

It would be great if there were an example with PGP.

=== section 6.9.  Calendar Properties ===

=== section 9.  Security Considerations ===

Seems fine.  If we deprecate the CLASS property, the text referring to Section 6.8.1. should be amended.

=== section 10.  IANA Considerations ===

10.3.4.  Values Registries will have to be updated if/when KIND and CLASS are dropped/deprecated.

=== section 11.  Acknowledgements ===