[VCARDDAV] Why the group construct exists

Simon Perreault <simon.perreault@viagenie.ca> Wed, 03 November 2010 18:11 UTC

Return-Path: <simon.perreault@viagenie.ca>
X-Original-To: vcarddav@core3.amsl.com
Delivered-To: vcarddav@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9790028C0CF for <vcarddav@core3.amsl.com>; Wed, 3 Nov 2010 11:11:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.498
X-Spam-Level:
X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiGoA2PfGNe8 for <vcarddav@core3.amsl.com>; Wed, 3 Nov 2010 11:11:20 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 81E8028C123 for <vcarddav@ietf.org>; Wed, 3 Nov 2010 11:11:18 -0700 (PDT)
Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:39b4:3937:b348:8153]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A79C520D35; Wed, 3 Nov 2010 14:11:24 -0400 (EDT)
Message-ID: <4CD1A5CC.3070003@viagenie.ca>
Date: Wed, 03 Nov 2010 14:11:24 -0400
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.12) Gecko/20101027 Fedora/3.1.6-1.fc14 Thunderbird/3.1.6
MIME-Version: 1.0
To: Rohit Khare <Rohit@Khare.org>
References: <2B2DCE4A-4AC8-4C21-88CA-597A8123C809@Khare.org>
In-Reply-To: <2B2DCE4A-4AC8-4C21-88CA-597A8123C809@Khare.org>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Cc: vcarddav@ietf.org
Subject: [VCARDDAV] Why the group construct exists
X-BeenThere: vcarddav@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF vcarddav wg mailing list <vcarddav.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vcarddav>
List-Post: <mailto:vcarddav@ietf.org>
List-Help: <mailto:vcarddav-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Nov 2010 18:11:21 -0000

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