canmove, Confirmed users
2,675
edits
VCard4: Difference between revisions
reviewed thru section 6.4.4
(reviewed thru section 6.2.10) |
(reviewed thru section 6.4.4) |
||
| Line 381: | Line 381: | ||
Sex component: The value M stands for "male", F stands for "female", O stands for "other", N stands for "none or not applicable", and U stands for "unknown". | Sex component: The value M stands for "male", F stands for "female", O stands for "other", N stands for "none or not applicable", and U stands for "unknown". | ||
=== section 6.3. Delivery Addressing Properties === | |||
6.3. Delivery Addressing Properties | |||
No comment on intro section. | |||
=== section 6.3.1. ADR === | |||
6.3.1. ADR | |||
I think it is good that the ADR structure has been maintained from vCard3. | |||
In practice however, the user interfaces for entering/editing address information do not correspond to the vCard ADR structure and have thus posed challenges for mapping user data to vCard ADR subproperties. | |||
I would recommend: | |||
* deprecate post office box (keep it in the structure, but suggest an empty string) | |||
* 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 === | |||
6.3.2. LABEL | |||
Seems unchanged from vCard3. No comments. | |||
=== section 6.4. Communications Properties === | |||
6.4. Communications Properties | |||
Intro sentence needs to be reworded - total awkward run-on. | |||
=== section 6.4.1. TEL === | |||
6.4.1. TEL | |||
The change to a URI makes sense on the surface but does not from a compat perspective. | |||
Rather, leave TEL alone (as was in vCard3), and suggest using the URI property for TEL URIs. | |||
Adjusting/updating the set of TYPEs for a TEL seems reasonable. | |||
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 === | |||
6.4.2. EMAIL | |||
Same comment about PREF. Good to see the useless TYPE param dropped. | |||
=== section 6.4.3. IMPP === | |||
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 === | |||
6.4.4. LANG | |||
This also seems like a reasonable addition, based on the presence of a similar property in OpenID Attribute Exchange: openid.sreg.language | |||
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. | |||