canmove, Confirmed users
2,854
edits
VCard4: Difference between revisions
→high level proposal for improving vCard4
(= typo) |
|||
| Line 22: | Line 22: | ||
== high level proposal for improving vCard4 == | == high level proposal for improving vCard4 == | ||
Based on | Based on a thorough section by section review, the changes and feedback I have for vCard4 draft 13 fall into a general outline as follows: | ||
1. Explicitly state as a goal to have vCard4 be reasonably backward compatible (i.e. with current implementations) of vCard3, both syntactically, and from a schema perspective (e.g. don't mess with structure of properties like N). | 1. Explicitly state as a goal to have vCard4 be reasonably backward compatible (i.e. with current implementations) of vCard3, both syntactically, and from a schema perspective (e.g. don't mess with structure of properties like N). This kind of practical backward compat enabled publishers to start posting vCard3 even when most consuming applications still only supported vCard2.1. | ||
2. Keep the vCard4 core set of properties down to a minimum that has been well established either in: | 2. Keep the vCard4 core set of properties down to a minimum that has been well established either in: | ||
* Popular address book programs (e.g. ANNIVERSARY) | * Popular address book programs (e.g. ANNIVERSARY) | ||
* Current well adopted RFCs (e.g. IMPP) | * Current well adopted mature RFCs (e.g. IMPP) | ||
* | * Common additions by OpenID / Portable Contacts that have seen adoption (e.g. SEX/GENDER, LANGUAGE, ACCOUNTS) | ||
3. Drop other new vCard4 properties and if they seem to make sense, move them to extension specifications instead where they can prove themselves out, e.g.: | 3. Drop other new vCard4 properties from the core and if they seem to make sense, move them to extension specifications instead where they can prove themselves out, e.g.: | ||
* KIND - | * KIND - vCard should not expand scope like this. For new kinds of objects new vThings should be created, and can be, outside the vCard spec. | ||
* XML - bad idea. Don't violate DRY. | * XML - bad idea. Don't violate DRY. This encourages breaking interop by potentially allowing implementations to look only at the XML or at the actual properties in a vCard. Same on the publishing side. | ||
Potential Extensions: | |||
* genealogy extension (BIRTH location, DEATH location, DDAY datetime of death) | * genealogy extension (BIRTH location, DEATH location, DDAY datetime of death) | ||
* social networking extension (MEMBER, RELATED, maybe more from PoCo) | * social networking extension (MEMBER, RELATED, maybe more from PoCo) | ||
* calendar contact extension (FBURL, CALADRURI, CALURI) | * calendar contact extension (FBURL, CALADRURI, CALURI) | ||
== issues == | == issues == | ||