[VCARDDAV] Why the group construct exists

[Simon Perreault <[e-mail]>]

On 2010-10-12 02:42, Rohit Khare wrote:
> * The group concept arrives early on (page 9). Only much later would the
> revision history clue me in that it’s been a controversial idea that’s
> made it in and out of the drafts.
> 
> In any case, the “group.” prefix came out of nowhere as I was reading
> the syntax, without reference to its roots in the HOME/WORK distinction.
> Whenever I introduce a new degree of freedom, I prefer to ground it with
> specific, evocative examples as soon as possible. At this point, even
> after reviewing the whole doc, I’m unclear on why it exists — are there
> other cultures that have lots of evidence of a taxonomy with higher
> valence than Home/Work? Are implementations incorrectly assuming the
> group prefix correlates to a user-facing label (fields should never
> determine display, imo)?

The reason for the group construct's existence is simple: it was in
vCard 3. There is absolutely no change to the group construct from vCard
3 to vCard 4.

We did attempt to change its semantics for replacing the TYPE parameter,
but finally gave up in the name of backward compatibility.

We know that Mac OS X's address book uses it heavily to group things in
some way.

I acknowledge that it is under-specified and uninteroperable. But any
change to this sad state of things implies breaking backward
compatibility substantially.

> Editorial recommendation: a better explanation inline, or at least a
> specific forward reference. Instead, the early arrival of such a weak
> claim (SHOULD/MAY) reduced my confidence that this would be an
> interoperable spec.

Pick your poison: uninteroperability or backward incompatibility.

At this late stage in the process, and in the absence of an explicit
proposal, I'll refrain from making the choice myself.

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org