canmove, Confirmed users
2,675
edits
(more vCard4 review, thru section 5.12) |
(reviewed thru section 6.1.5) |
||
Line 1: | Line 1: | ||
vCard 4 is work in progress (by the vcarddav group in IETF) on an update/replacement to/for vCard 3, RFC 2426. | vCard 4 is work in progress (by the vcarddav group in IETF) on an update/replacement to/for vCard 3, RFC 2426. | ||
Line 169: | Line 167: | ||
* 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. | ||
=== 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? | |||
== related == | == related == | ||
* [[Standards]] | * [[Standards]] |