VCard4: Difference between revisions

1,576 bytes added ,  7 October 2010
reviewed thru section 6.1.5
(more vCard4 review, thru section 5.12)
(reviewed thru section 6.1.5)
Line 1: Line 1:
{{stub}}
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]]
canmove, Confirmed users
2,675

edits