Fwd: [VCARDDAV] seeking consensus on KIND

Forwarding to public-contacts-coord@w3.org to make sure we get feedback
from all the right people.

Please send feedback to the vcarddav@ietf.org list.

/psa


-------- Original Message --------
Subject: [VCARDDAV] seeking consensus on KIND
Date: Tue, 15 Mar 2011 21:27:18 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
To: CardDAV <vcarddav@ietf.org>

<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/