[VCARDDAV] seeking consensus on KIND

Peter Saint-Andre <stpeter@stpeter.im> Wed, 16 March 2011 03:25 UTC

Return-Path: <stpeter@stpeter.im>
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 2F8553A6AC9 for <vcarddav@core3.amsl.com>; Tue, 15 Mar 2011 20:25:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.605
X-Spam-Level:
X-Spam-Status: No, score=-102.605 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 0CYjoMXWoD8j for <vcarddav@core3.amsl.com>; Tue, 15 Mar 2011 20:25:54 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id F26D83A697A for <vcarddav@ietf.org>; Tue, 15 Mar 2011 20:25:53 -0700 (PDT)
Received: from squire.local (dsl-251-69.dynamic-dsl.frii.net [216.17.251.69]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 65D5940022 for <vcarddav@ietf.org>; Tue, 15 Mar 2011 21:27:48 -0600 (MDT)
Message-ID: <4D802E16.8000108@stpeter.im>
Date: Tue, 15 Mar 2011 21:27:18 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: CardDAV <vcarddav@ietf.org>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms070008080504000609040507"
Subject: [VCARDDAV] seeking consensus on KIND
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, 16 Mar 2011 03:25:55 -0000

<hat type='AD'/>

Folks, we need to finish the vcard4 core spec.

I've reviewed draft-ietf-vcarddav-vcardrev-16 and I think it closes all
of the issues that were raised on this list over the last few months.

As our long-suffering document editor has noted, there is one exception:
the KIND property.

Late last week I reviewed the December discussion thread about KIND.
Based on that reading, I see three possible ways forward (in order from
least invasive to most invasive with regard to the core spec):

1. Leave "KIND:group", "KIND:location", and "KIND:org" in the core but
define them more carefully and completely.

2. Define "KIND:individual" in the core but move "KIND:group",
"KIND:location", and "KIND:org" to extension documents.

3. Remove the KIND property entirely.

It seems to me that #3 is a non-starter, because the WG has had
consensus to include the KIND property since before the core spec was
accepted as a WG item (draft-resnick-vcarddav-vcardrev-01, published
February 4, 2008).

I would agree with those who argue that "KIND:group", "KIND:location",
and "KIND:org" are underspecified in the core spec, because all we have
in Section 6.1.4 is this:

      The value may be one of: "individual" for a single
      person, "group" for a group, "org" for an organization,
      "location" for a named geographical place, an x-name or
      an iana-token.

Whether we move those values of the KIND property to extension specs or
keep them in the core, they need to be specified more carefully and
completely. Therefore I ask for a volunteer to post text to the list
that describes these values in more detail.

Once that is done, we can decide whether the proposed text belongs in
the core spec or in extension specs. (Naturally, discussion of that
topic is welcome before text is posted.)

I would like to make two related points:

a. I think the text in Section 6.1.4 needs to be adjusted regarding the
default value. It currently says the following about the KIND property:

   If this property is absent, "individual" MUST be assumed as default.

I think it would be more accurate to say:

   If this property is absent or an application does not understand the
   provided value (e.g., an x-name or an iana-token), then a value of
   "individual" MUST be assumed (i.e., "individual" is the default).

My reasoning is that we can't expect an application that supports the
KIND property to understand all possible values of the property (even
x-names and iana-tokens).

b. The spec is unclear about which values MUST be understood by an
implementation that supports the KIND property. Does it need to
understand all values defined in the core spec? Only "individual"? This
needs to be clarified (and might be a consideration in deciding whether
values other than "individual" belong in the core spec).

Let's get this done!

Peter

--
Peter Saint-Andre
https://stpeter.im/