Bureaucrats, canmove, Confirmed users
2,887
edits
VCard4-draft-13-review: Difference between revisions
Jump to navigation
Jump to search
update through section 5 (5.13)
(→section 6.2.10. SEX: update with examples, and note optional components) |
(update through section 5 (5.13)) |
||
| Line 57: | Line 57: | ||
* N property | * N property | ||
** dropped 'additional-name's - this makes it non-backward compat with vCard3 | ** dropped 'additional-name's - this makes it non-backward compat with vCard3 | ||
FIXED in draft 15. | |||
=== divergence from Portable Contacts === | === divergence from Portable Contacts === | ||
* SEX (in vCard4) vs GENDER (in PoCo) | * SEX (in vCard4) vs GENDER (in PoCo) | ||
| Line 112: | Line 114: | ||
Suggestion: use "NOTE" property instead. | Suggestion: use "NOTE" property instead. | ||
FIXED in draft 14. | |||
=== section 4.1 === | === section 4.1 === | ||
| Line 121: | Line 126: | ||
Suggestion: use "NOTE" property instead. | Suggestion: use "NOTE" property instead. | ||
FIXED in draft 14. | |||
=== section 4.4 === | === section 4.4 === | ||
| Line 134: | Line 142: | ||
"boolean": The "boolean" value type is used to express boolean values. | "boolean": The "boolean" value type is used to express boolean values. | ||
FIXED in draft 14. | |||
=== section 5.1 === | === section 5.1 === | ||
| Line 159: | Line 170: | ||
Suggestion: drop this property parameter - it seems like a bad design, and unnecessary. | Suggestion: drop this property parameter - it seems like a bad design, and unnecessary. | ||
UNCHANGED - need to check email threads. | |||
=== section 5.5 === | === section 5.5 === | ||
| Line 166: | Line 180: | ||
I'm interested to see how implementations support this, but overall optimistic about its potential. | I'm interested to see how implementations support this, but overall optimistic about its potential. | ||
NO CHANGES NEEDED. | |||
=== section 5.6 === | === section 5.6 === | ||
| Line 173: | Line 190: | ||
My recommendation just reading its description would be to drop this new property parameter. | My recommendation just reading its description would be to drop this new property parameter. | ||
NO CHANGES MADE, CONSIDER AS PART OF SYNC ISSUE. | |||
=== section 5.7 === | === section 5.7 === | ||
| Line 178: | Line 198: | ||
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. | 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. | ||
NO CHANGES MADE, MAY STILL BE AN ISSUE. | |||
=== section 5.8 === | === section 5.8 === | ||
| Line 187: | Line 210: | ||
Recommended we drop this property parameter. | Recommended we drop this property parameter. | ||
PARAMETER KEPT. HOWEVER, PERHAPS IT IS OK TO HAVE A "MUST IGNORE" FOR NON-GREGORIAN VALUES. | |||
=== section 5.9 === | === section 5.9 === | ||
| Line 192: | Line 218: | ||
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. | 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. | ||
NO CHANGE NEEDED. | |||
=== section 5.10 === | === section 5.10 === | ||
| Line 197: | Line 226: | ||
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. | 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. | ||
NO CHANGE NEEDED. | |||
=== section 5.11 === | === section 5.11 === | ||
| Line 202: | Line 234: | ||
Makes sense in the same way as GEO parameter. | Makes sense in the same way as GEO parameter. | ||
NO CHANGE NEEDED. | |||
=== section 5.12 === | === section 5.12 === | ||
| Line 211: | Line 246: | ||
* specify forward compatible parsing rules (i.e. ignore any params you don't recognize) | * 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. | * 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. | ||
THIS HAS BEEN DROPPED ACCORDINGLY! (not sure if it was dropped in 14 or 15) | |||
=== section 5.13 === | === section 5.13 === | ||
| Line 216: | Line 254: | ||
This seems like a reasonable property parameter addition for binary value types. | This seems like a reasonable property parameter addition for binary value types. | ||
THIS HAS BEEN DROPPED AS IT IS NO LONGER NECESSARY. | |||
=== section 6. === | === section 6. === | ||
| Line 224: | Line 265: | ||
* (0-1) - at most one instance may be present | * (0-1) - at most one instance may be present | ||
* (0-n) - any number of instances may be present | * (0-n) - any number of instances may be present | ||
=== section 6.1 === | === section 6.1 === | ||