Re: [VCARDDAV] KIND in draft 15

[Simon Perreault <[e-mail]>]

On 2010-12-20 14:16, Tantek Çelik wrote:
> In my experience those "groups" in such user interfaces, e.g. Apple
> Address Book, are typically *not* represented as vCard objects
> themselves, but rather as CATEGORIES on the contacts that are in the
> groups.

Yes, this is one way that they can be implemented. But it only allows
for a group name, nothing more. Any UA that allows the user to input
meta-data about a group cannot be implemented with CATEGORIES. And there
are plenty of such UAs out there.

> No GUI elements - the data point here is the existence of real world
> *content* (the contacts themselves) that are examples of the data
> model addition represented by KIND:LIST and KIND:ROBOT.

This highlights some confusion about the "already widely implemented"
criteria for getting into vCard 4 base.

I originally stated the criteria as "it is needed by a majority of vCard
implementations". See here:
http://www.ietf.org/mail-archive/web/vcarddav/current/msg00958.html
It seemed to make consensus at the time.

Obviously, current vCard implementations cannot have already implemented
something that we're planning for vCard 4. But if current
implementations try to provide a similar feature, either through
standard or non-standard means, that's enough justification for
introducing such a feature in base vCard 4.

The fact that groups are implemented through file-system directories
with meta-data, or using DAV meta-data, or through CATEGORIES, or even
in ways that do not involve vCard at all, is enough justification in my
mind for us to say "this feature is needed by a majority of vCard
implementations needs to be in the vCard 4 core spec".

However, I don't know of any UA that implements a feature similar to
KIND:LIST or KIND:ROBOT. That's not to say that current UAs cannot
*store* such addresses, but I don't know of any that lets me flag them
as such (e.g. by toggling a checkbox). Obviously that currently wouldn't
be implemented with the KIND property since it doesn't exist yet, but I
would be looking for an implementation using non-standard properties or
whatever else. I don't know of any such implementation.

As usual, the working group's consensus trumps my individual opinion. So
I'd like to hear from other participants at this point.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca