[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/
- [VCARDDAV] seeking consensus on KIND Peter Saint-Andre
- Re: [VCARDDAV] seeking consensus on KIND Barry Leiba
- Re: [VCARDDAV] seeking consensus on KIND Cyrus Daboo
- Re: [VCARDDAV] seeking consensus on KIND Barry Leiba
- Re: [VCARDDAV] seeking consensus on KIND Andy Mabbett
- Re: [VCARDDAV] seeking consensus on KIND Andy Mabbett
- Re: [VCARDDAV] seeking consensus on KIND Barry Leiba
- Re: [VCARDDAV] seeking consensus on KIND Andy Mabbett
- Re: [VCARDDAV] seeking consensus on KIND Cyrus Daboo
- Re: [VCARDDAV] seeking consensus on KIND Barry Leiba
- Re: [VCARDDAV] seeking consensus on KIND Barry Leiba
- Re: [VCARDDAV] seeking consensus on KIND Peter Saint-Andre
- Re: [VCARDDAV] seeking consensus on KIND Barry Leiba
- Re: [VCARDDAV] seeking consensus on KIND Andy Mabbett
- Re: [VCARDDAV] seeking consensus on KIND Andy Mabbett
- Re: [VCARDDAV] seeking consensus on KIND Cyrus Daboo
- Re: [VCARDDAV] seeking consensus on KIND Mike Douglass
- Re: [VCARDDAV] seeking consensus on KIND Andy Mabbett
- Re: [VCARDDAV] seeking consensus on KIND Peter Saint-Andre
- Re: [VCARDDAV] seeking consensus on KIND Joseph Smarr
- Re: [VCARDDAV] seeking consensus on KIND Andy Mabbett