VCard4: Difference between revisions

Jump to navigation Jump to search

VCard4 (view source)

Revision as of 01:15, 14 December 2010

22,980 bytes removed ,  14 December 2010
→‎draft 13 section by section review: archived to separate page
(add vcarddav section at top, beijing minutes)
(→‎draft 13 section by section review: archived to separate page)
Line 110: Line 110:
== draft 13 section by section review ==
== draft 13 section by section review ==


=== section 3.1 ===
Moved to separate page:
3.1.  Line Delimiting and Folding


Editorial comment:
* [[VCard4-draft-13-review]]
 
Examples use "DESCRIPTION" property - which is not in vCard.
 
Suggestion: use "NOTE" property instead.
 
=== section 4.1 ===
4.1.  TEXT
 
Editorial comment:
 
Examples use "DESCRIPTION" property - which is not in vCard.
 
Suggestion: use "NOTE" property instead.
 
=== section 4.4 ===
4.4.  BOOLEAN
 
Editorial comment:
 
TYPO:
 
"boolean": The "boolean" value type is used to express boolen values.
 
Should be:
 
"boolean": The "boolean" value type is used to express boolean values.
 
=== section 5.1 ===
5.1.  LANGUAGE
 
Editorial comment:
 
Please provide a simple example use of the LANGUAGE property parameter, e.g.
 
<pre><nowiki>
ROLE;LANGUAGE=en:teacher
ROLE;LANGUAGE=tr:hoca
 
See below ALTID property parameter for how to associate these two ROLE properties as being alternatives for the same property value.
</nowiki></pre>
 
=== section 5.4 ===
5.4.  PREF
 
Preferred value between 1 and 100 seems a bit arbitrary.
 
What is the use-case for this?
 
Also, from a synchronization perspective, picking absolute numbers for indicating preference would seem to make little sense, as the values themselves only make sense relative to other values.
 
Suggestion: drop this property parameter - it seems like a bad design, and unnecessary.
 
=== section 5.5 ===
5.5.  ALTID
 
This seems like a good mechanism for publishing multilingual alternatives on a per-property basis.
 
I'm interested to see how implementations support this, but overall optimistic about its potential.
 
=== section 5.6 ===
5.6.  PID
 
This definition is very short and abstract and is not very useful out of context as it is.  There should be at least one concrete example, otherwise move this section to "Section 7" since that's where it says there are "more details on its usage".
 
My recommendation just reading its description would be to drop this new property parameter.
 
=== section 5.7 ===
5.7.  TYPE
 
No specific comments.  General comment - type seems like a catch-all of sorts - not very well designed.  Some of the uses are quite flawed. E.g. the notions of "work" and "home" have not worked well in practice. In particular "work" doesn't make much sense given that there is an "ORG" property with which any work email/phone/address should be associated, rather than just implied.
 
=== section 5.8 ===
5.8.  CALSCALE
 
In practice have there been any address books that implement a CALSCALE *other* than the specific default of "gregorian"?
 
I think this should be dropped until there is at least some evidence produced that there is address book software out there that bothers to even try to support part of the existing vCard3 spec and that provides a non-gregorian calendar scale user interface.
 
Recommended we drop this property parameter.
 
=== section 5.9 ===
5.9.  SORT-AS
 
Having this as a property *parameter* seems like an improvement over the previous 'sort-string' property which I've not really seen used in the wild.
 
=== section 5.10 ===
5.10.  GEO
 
This makes sense as an addition/refinement to the ADR property, to assign a specific lat/long to a particular address, especially when multiple addresses are involved. hCard backward compat will be a little interesting but I'm sure we can figure it out.
 
=== section 5.11 ===
5.11.  TZ
 
Makes sense in the same way as GEO parameter.
 
=== section 5.12 ===
5.12.  VERSION
 
I don't think this is necessary, and in fact encourage future breaking as well as pushing the burden of handling multiple versions of a property onto implementations.
 
Let's NOT add this, and instead work hard to:
* specify forward compatible parsing rules (i.e. ignore any params you don't recognize)
* keep properties backward compatible in general, just adding detail params (like TZ and GEO) where it progressively enhances the property without breaking any existing semantics.
 
=== section 5.13 ===
5.13.  FMTTYPE
 
This seems like a reasonable property parameter addition for binary value types.
 
=== section 6. ===
The current cardinality shorthands are cryptic, please use something more typically readable, e.g.:
 
* (1) - exactly one instance must be present
* (1-n) - at least one instance must be present
* (0-1) - at most one instance may be present
* (0-n) - any number of instances may be present
 
=== section 6.1 ===
6.1.  General Properties
 
no content.
 
=== section 6.1.1. BEGIN ===
 
no comment. seems compatible.
 
=== section 6.1.2. END ===
 
no comment. seems compatible.
 
=== section 6.1.3. SOURCE ===
6.1.3.  SOURCE
 
no comment. seems compatible.
 
=== section 6.1.4.  KIND ===
6.1.4.  KIND
 
I think this is a really bad idea.
 
While existing usage of vCard3 for both people and organizations is something we have to support moving forward, I really don't want to see this expanded further (with the possible exception of a named location - which we've found utility for with hCard as well).
 
Object to: group, thing
 
Groups should not just be a form of vCard.  And thing?  I think both of these are horrible abuse of existing vCard semantics.
 
If you want to add new objects, let's add new objects like a vGroup or a vThing etc. But please let's not bloat vCard with these things.
 
=== section 6.1.5.  XML ===
6.1.5.  XML
 
I think this is totally unnecessary and a bad idea because it violates DRY.
 
Seriously? An XML property that represents all the rest of the data in the same vCard? Ugh. Which do you trust? The XML or the actual vCard properties?
 
 
=== section 6.2.  Identification Properties ===
6.2.  Identification Properties
 
no comment on intro.
 
=== section 6.2.1.  FN ===
6.2.1.  FN
 
The possibility of having multiple FNs is introduced, which seems both reasonable and useful in practice from personal experience with developing address book code.
 
However, there is no advice/guidance 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.2.  N ===
 
Not requiring an N is a big improvement.
 
The new N structure is different enough from vCard3 to be problematic.
 
Minor change:
* Use "family name" as a primary (perhaps with "also known as surname") since vCard3 referred to "family name", and hCard adopted that wording in the subproperty "family-name".
 
Major changes:
* Consider allowing multiple family names. In my experience giving microformats workshops around the world, I have found that there are languages/cultures that actually use multiple family names in practice, e.g. in Spain.
* 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 ===
6.2.3.  NICKNAME
"belonging to a person, place, or thing" - avoid such itemizations of what a vCard could represent as it will be (is) a maintenance nightmare.
 
Use "belonging to the object the vCard represents" instead.
 
=== section 6.2.4.  PHOTO ===
6.2.4.  PHOTO
 
Seems about the same as vCard3.
 
Provide a data: URI example as implementations do seem to support that, and note how the data URI may contain the content/MIME-type and thus that can be used instead of the FMTTYPE param.  For reference:
 
http://en.wikipedia.org/wiki/Data_URI_scheme
 
<nowiki>data:[<MIME-type>][;charset=<encoding>][;base64],<data></nowiki>
 
=== section 6.2.5.  BDAY ===
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 ===
6.2.6.  DDAY
 
No evidence of address books that support this property have been presented.
 
This would make more sense as part of a "genealogy" extension to vCard4 rather than part of the core.
 
That being said:
 
I for one have personally found it there to be a user-interface challenge in managing the contact information in an address book of people that have passed away.
 
While some may suggest simply deleting such entries, I don't think that reflects that necessary history/attachment/notes of common usage of such address book entries.
 
However, given that address books are often used to "auto-fill/suggest" things like email program "To:" fields etc. (e.g. Mail.app on MacOSX with the Address Book app), it makes sense to provide some way to mark a contact as deceased so that they don't show up in auto-fill/suggest user interfaces.
 
A DDAY property could serve as a proxy for such a "deceased" checkbox on an entry.
 
It should explicitly allow the same data type as BDAY, and provide examples accordingly.
 
Thus while there is no existing evidence of address books that provide this kind of user interface feature, I believe this may be an instance where it makes sense to add this field, given the *address book* use cases documented above.
 
Naming: while the name "DDAY" I'm sure appeals as a parallel to the BDAY property, the term DDay already has a widely known/used historical semantic and thus it may unnecessarily cause confusion.
 
I suggest instead the term "DECEASED" as that is much more indicative of the meaning (less cryptic).
 
"Deceased" was also the original suggestion provided on the microformats page for this property: http://microformats.org/wiki/vcard-suggestions#Deceased
 
In addition, consider permitting a simple "Y" value to indicate that the person is deceased but no precise date or even year is known.  This would enable modeling of a simple checkbox interface to indicate that someone has passed away without burdening the user with entering a date or year.
 
I would also be ok postponing this property to a "genealogy" extension.
 
 
=== section 6.2.7.  BIRTH ===
6.2.7.  BIRTH
No evidence of address books that support this property have been presented.
 
This would make more sense as part of a "genealogy" extension to vCard4 rather than part of the core.
 
And this is a horrible property name to boot for a "location".
 
Recommendation: drop from vCard4.
 
=== section 6.2.8.  DEATH ===
6.2.8.  DEATH
 
No evidence of address books that support this property have been presented.
 
This would make more sense as part of a "genealogy" extension to vCard4 rather than part of the core.
 
And this is a horrible property name to boot for a "location".
 
Recommendation: drop from vCard4.
 
=== section 6.2.9.  ANNIVERSARY ===
6.2.9.  ANNIVERSARY
 
I have seen "anniversary" as a field in address book application user interfaces (anecdotal, off the top of my head), and thus this seems like a reasonable addition to vCard.
 
Should allow same date-and-or-time data type as BDAY, including year-only, month-day, year-month etc.
 
=== section 6.2.10.  SEX ===
6.2.10.  SEX
 
It's a good idea to add the general idea of this feature to vCard.
 
The specific implementation is roughly close but does leave something to be desired.
 
The current draft has: The value 0 stands for "not known", 1 stands for "male", 2 stands for "female", and 9 stands for "not applicable".
 
While this discretization into 4 values makes sense,  and if I'm not mistaken, is based on the work in the microformats community:
 
http://microformats.org/wiki/gender-brainstorming
 
The translation to opaque numerical values is a negative.
 
Instead use the single letter prefixes of the English terms as noted in the microformats page:
 
sex: M(ale) F(emale) O(ther) N(one or Not applicable)
 
This reflects common use in both social networking sites which permit M or F (see microformats research at above URLs), as well as previous formats that have worked on representing this information, e.g. openid.sreg.gender permits  "M" for male, "F" for female.
 
Finally, sex without gender is problematic from a gender identity perspective and discriminatory against a marginalized minority.
 
Thus for the sake of allowing a more flexible representation that avoids such marginalization, an additional property should be introduced:
 
GENDER-IDENTITY
 
which takes a string that the user can assign any label.
 
Alternatively (and preferably), rather than the SEX property, introduce a new *structured* property:
 
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:  (0-1)
 
Special notes:  The structured property value corresponds, in sequence, to the sex (biological), and (optional) gender identity. The text components are 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".
 
Gender identity component: a single text value.
 
 
In addition the current draft includes a notion of "not known", which, though I haven't seen evidence for, can understand the potential utility as it may help represent the explicit not knowing of information. Thus I would be ok with:
 
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. Better to deprecate the LABEL property and add a LABEL parameter to the ADR property.
 
=== 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.
 
 
=== section 6.5.  Geographical Properties ===
6.5.  Geographical Properties
 
This is a good intro clarifying what the properties apply to. (has been a source of confusion in vCard3 in the past)
 
 
=== section 6.5.1.  TZ ===
6.5.1.  TZ
 
Looks good in general, compatible with vCard3.
 
A bit concerned about the forward-looking references to potential efforts - those don't belong in a specification.
 
Cardinality should be (0-1) - how can a vCard object be in multiple time zones?
 
=== section 6.5.2.  GEO ===
6.5.2.  GEO
 
Looks good in general, compatible with vCard3.
 
Cardinality should be (0-1) - how can a vCard object be in multiple locations?
 
 
 
=== section 6.6.  Organizational Properties ===
6.6.  Organizational Properties
 
Minor typo in intro sentence. should be:
 
These properties are concerned with information associated with characteristics of the organization or organizational units of the object that the vCard represents.
 
=== section 6.6.1.  TITLE ===
6.6.1.  TITLE
 
Seems fine, compatible with vCard3.
 
=== section 6.6.2.  ROLE ===
6.6.2.  ROLE
 
Seems fine, compatible with vCard3.
 
=== section 6.6.3.  LOGO ===
6.6.3.  LOGO
 
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.4.  ORG ===
6.6.4.  ORG
 
Seems fine, compatible with vCard3.
 
=== section 6.6.5.  MEMBER ===
6.6.5.  MEMBER
 
Groups should not be in vCard but rather should be in another spec/schema.
 
Recommend drop this property.
 
=== section 6.6.6.  RELATED ===
6.6.6.  RELATED
 
This is an interesting idea that merits exploration as an extension, not part of vCard core.
 
Also, rather than inventing another taxonomy of relationship, consider simply re-using by reference the XFN 1.1 taxonomy:
 
http://gmpg.org/xfn/11
 
And then proposing or adding support for additional terms on the XFN brainstorming page.
 
http://microformats.org/wiki/xfn-brainstorming
 
=== section 6.7.  Explanatory Properties ===
 
Sounds more like a miscellaneous section.
 
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 ===
6.7.1.  CATEGORIES
 
Nice to see this section/semantic upgraded to mention tags.
 
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 ===
 
Seems fine, compatible with vCard3.
 
=== section 6.7.3.  PRODID ===
 
This seems fine. In practice this is not used much.
 
=== section 6.7.4.  REV ===
6.7.4.  REV
 
Seems fine, compatible with vCard3.
 
Would be nice to allow whole dates as well (without time).
 
=== section 6.7.5.  SOUND ===
6.7.5.  SOUND
 
Seems fine, compatible with vCard3.
 
=== section 6.7.6.  UID ===
6.7.6.  UID
 
Seems fine, compatible with vCard3. Nice improvement to use URI.
 
=== section 6.7.7.  CLIENTPIDMAP ===
6.7.7.  CLIENTPIDMAP
 
Lacking an example with a use-case, this property should be dropped.
 
=== section 6.7.8.  URL ===
6.7.8.  URL
 
Seems fine, compatible with vCard3.
 
==== new property ACCOUNT ====
Related suggestion:
 
PoCo has the notion of an "account" property which is a tuple of domain, username, userid. There is sufficient additional utility (above and beyond "URL") to having explicit structured account information that I propose the following new property:
 
ACCOUNT
 
Purpose: To specify the components of an account of the object the vCard represents.
 
Value type: A single structured text value. Each component can have one value.
 
Cardinality: (0-n)
 
Special note:  The structured property value corresponds, in sequence, to the domain name, username, user-id , and canonical profile URL.  The text components are separated by the SEMI-COLON character (ASCII decimal 59).  This property is based on the semantics of the Portable Contacts Account property. The property SHOULD be present in the vCard object when one or more URLs for the object represent online profiles of the object.
 
The SORT-AS parameter MAY be applied to this property.
 
=== section 6.7.9.  VERSION ===
6.7.9.  VERSION
 
Seems fine, compatible with vCard3. Not used much in practice.
 
=== section 6.8.  Security Properties ===
6.8.  Security Properties
 
Seems fine.
 
=== section 6.8.1.  CLASS ===
6.8.1.  CLASS
 
In practice we have seen no use of this property in hCard.
 
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 ===
6.8.2.  KEY
 
This property has light use but much potential in both vCard and hCard.
 
It would be great if there were an example with PGP.
 
=== section 6.9.  Calendar Properties ===
6.9.  Calendar Properties
 
This whole section should be dropped from core and placed into an extension.
 
=== section 6.10.  Extended Properties and Parameters ===
6.10.  Extended Properties and Parameters
 
Seems about the same as vCard3.
 
=== section 7.  Synchronization ===
7.  Synchronization
 
This entire section, the PID property, and the CLIENTPIDMAP property should all be moved to an extension spec.
 
=== section 8.  Example: Authors' vCards ===
8.  Example: Authors' vCards
 
Seems fine. Didn't review/test for vCard validity but assume the authors will do that.
 
=== 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 ===
Seems fine as much as any other IANA-based registration assumptions/plans.
 
Obviously 10.3.1.  Properties Registry will have to be updated as any properties are added or dropped.
 
Similarly 10.3.2.  Parameters Registry if any parameters are added/dropped.
 
10.3.3.  Value Data Types Registry no changes expected.
 
10.3.4.  Values Registries will have to be updated if/when KIND and CLASS are dropped/deprecated.
 
=== section 11.  Acknowledgements ===
11.  Acknowledgements
 
No comments.
 
=== section 12.  References ===
12.  References
 
No comments.
 
=== section Appendix A.  Differences from RFCs 2425 and 2426 ===
Appendix A.  Differences from RFCs 2425 and 2426
 
will need updates accordingly.
 
=== section Appendix B.  Change Log ===
Appendix B.  Change Log (to be removed by RFC Editor prior to publication)
 
No comments.


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

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/273380"

Navigation menu