Re: [VCARDDAV] KIND in draft 15

Let me just add (at the risk of dragging this thread out any longer) that
one reason KIND:GROUP is a *bad* idea IMO is that clients who aren't aware
of it will end up with a "contact" that is not really a "contact", so you're
kind of polluting the list of vCards.

It's one thing to specify KIND for things like companies or autoresponders
that really do show up *in* people's address books as contacts. You could
even do the same for KIND:MAILING-LIST for yahoo/google/ietf-group mailing
lists with a single address that shows up in your contacts. In those cases,
if you ignore KIND (as most/all clients will do for the foreseeable future,
by definition), it doesn't hurt you--you thought you had a normal contact,
and you do, you're just missing some helpful classification information.

But to store contact group metadata in a fake contact and then try to "hide"
it by saying KIND:GROUP is a very different thing. That's not a normal
contact, and a client that ignores it will not only miss the metadata there,
they'll end up with a bogus contact that wasn't in their address book
before. That seems unacceptable to me, unless I'm missing something about
the source of these KIND:GROUP contacts.

On Tue, Dec 21, 2010 at 3:35 AM, Andy Mabbett <andy@pigsonthewing.org.uk>wrote:

> On 21 December 2010 02:55, Cyrus Daboo <cyrus@daboo.name> wrote:
>
> > CATEGORIES cannot be definitive if it just contains "names" which are not
> guaranteed
> > to be unique. KIND/MEMBER is definitive in that they use unique IDs.
>
> Surely, the issue with KIND: GROUP/LIST/ROBOT is not merely one of the
> semantics of those terms, but of the functionality we wish to enable?
>
> For example, someone mentioned the use-case of not auto-completing
> with 'bot addresses. As Cyrus points out, such functionality would be
> hard to provide, if all that is available is a category, which I have
> called "ROBOT" but someone else has called "AUTOREPONDER", or some
> other value.
>
> Much of the above debate (with some exceptions, I acknowledge) seems
> centre on the semantics, not the functionality. I think I for one
> would find it easier to reach a conclusion as to the best course of
> action, if arguments were based on the latter.
>
> --
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
> _______________________________________________
> VCARDDAV mailing list
> VCARDDAV@ietf.org
> https://www.ietf.org/mailman/listinfo/vcarddav
>