Re: [VCARDDAV] KIND in draft 15

Kevin Marks <kevinmarks@gmail.com> Tue, 21 December 2010 21:10 UTC

Return-Path: <kevinmarks@gmail.com>
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 CDFD83A6A92 for <vcarddav@core3.amsl.com>; Tue, 21 Dec 2010 13:10:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.473
X-Spam-Level:
X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_LOW=-1]
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 SQE0H57G8ML4 for <vcarddav@core3.amsl.com>; Tue, 21 Dec 2010 13:10:51 -0800 (PST)
Received: from mail-fx0-f43.google.com (mail-fx0-f43.google.com [209.85.161.43]) by core3.amsl.com (Postfix) with ESMTP id CCD703A68C6 for <vcarddav@ietf.org>; Tue, 21 Dec 2010 13:10:48 -0800 (PST)
Received: by fxm18 with SMTP id 18so4503291fxm.16 for <vcarddav@ietf.org>; Tue, 21 Dec 2010 13:12:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=xY9qp1fyrS3u/+Kct3JSp5xUzSxUbU1CXDkD9qO428Q=; b=Qq99WG0tZndQBLdQFEvwCM4AP4A/edygUkaaxP7cekDr7e27OkQaxapWL+n77MJW+X Gtvgi4F9ptvVraGNvOt5dNxpqhALQ6cPaF6I0i9qkjT6p/z2JGOoQJZ/A5eEn2u8Mkg0 iw1LkjqwzWMVR32wtvP5MEFtwMOOt83dB/MJE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Be0kcWCF+FxW3rRhNrX8cWBAuqvsyaJlEkw0Z7sDok2Q6fXOtY01wHoovqQmzp1HTv 84HfhdenQ6BK3bEBaEkk8k1Wso/98T4uWq4XxWCwSqW8OG03uaKSDrG7kT0qzg+8nxIa ry9JENb2ccN9qrYfkm8MUYyNVlBwfuBJYumUw=
MIME-Version: 1.0
Received: by 10.223.86.196 with SMTP id t4mr969426fal.34.1292965964554; Tue, 21 Dec 2010 13:12:44 -0800 (PST)
Received: by 10.223.74.131 with HTTP; Tue, 21 Dec 2010 13:12:44 -0800 (PST)
In-Reply-To: <4D10FA58.6060004@rpi.edu>
References: <AANLkTikckYf5A0rUZ6k=JN2UZwp+__bBFHndxbfLcEHK@mail.gmail.com> <4D0B6AC9.1080607@viagenie.ca> <4D0B83AE.4060601@stpeter.im> <AANLkTimA-AuKRoOm6ZRmqSTmOBzHkWCah52ezCJCmvVp@mail.gmail.com> <4D0FA8C9.7080201@viagenie.ca> <AANLkTimM2sAX3_4+Y2sBXuUxbWdRxpJ2bLq5Pq12pGOr@mail.gmail.com> <4D0FB317.1050004@viagenie.ca> <AANLkTim-026NEKwmEwHi6hY2BfTunny11q191+9Wdw+g@mail.gmail.com> <5B90C712-865E-4760-ACE4-451B063999C8@opengroupware.org> <9944D1A448E2AEEC76264B1F@cyrus.local> <AANLkTing1mcsJgD+W8+dkg9Sb=SkbfLNagHrYtCujMa2@mail.gmail.com> <5C90ECF3EB063458C5F1692F@cyrus.local> <AANLkTinHUBPF6ECVkwf17_1FB1K=vNbikptUPP=8_dNx@mail.gmail.com> <AANLkTim28Z2U1dqahuE2gdYvHKHVKc_tc=9DoHDbftYr@mail.gmail.com> <BB98A5C1EA4AA623BDE64DDA@cyrus.local> <AANLkTikOrMkuJsEL=Ns3p1bHVRWGJNX11DacJ3b80Gor@mail.gmail.com> <20053CE6AFBEA55673BF3EEE@cyrus.local> <AANLkTimxZ7dwp4xxrVvsuyp_bYs6Yfuw6cjeH9P1vNxq@mail.gmail.com> <4D10FA58.6060004@rpi.edu>
Date: Tue, 21 Dec 2010 13:12:44 -0800
Message-ID: <AANLkTik--D388QcEjh15GEzwcfv7Fh+1uOtqoXvqONKM@mail.gmail.com>
From: Kevin Marks <kevinmarks@gmail.com>
To: Mike Douglass <douglm@rpi.edu>
Content-Type: multipart/alternative; boundary="20cf30433f7a0623a40497f219ba"
Cc: "vcarddav@ietf.org >> CardDAV" <vcarddav@ietf.org>
Subject: Re: [VCARDDAV] KIND in draft 15
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: Tue, 21 Dec 2010 21:10:58 -0000

On Tue, Dec 21, 2010 at 11:04 AM, Mike Douglass <douglm@rpi.edu> wrote:

>  I strongly disagree with that and your previous assertion that "it
> basically worked fine".
>
> vcard as it stands together with most of the implementations are a model of
> non-interoperability. It might work fine if you don't ever use another
> client and it might work fine if you're prepared to do significant editing
> of the data before importing and if you know all the quirks of the client
> you're about to import into. Otherwise my experience is you're pretty much
> screwed.
>
> Almost every time I try to import I end up with a "polluted" address book.
>
> This says nothing about the quality of individual V3(2.1) clients. They may
> be good, bad or indifferent but the data model and its specification is
> simply inadequate.
>

Even if I grant you that this is true, you seem to be asserting that the
GROUP/MEMBER data model is magically better and we should ignore the fact
that it will pollute existing addressbooks with non-functional contacts by
design.


> Back in 2007 at the CalConnect workshop there was a list of features that
> were deemed desirable or essential. Groups was one of them and some of us
> have built a structure based on usable groups.
>
> I'd rather deal with trying to convert vcard 3 (or 2.1) up to vcard 4 than
> continue to try to represent common constructs on a broken model.
>
> As Cyrus points out the result of importing a group contact is benign.
>

Clearly there is a problem, as Cyrus rightly says, with merging CATEGORIES
from different origins. likewise, there is a problem with merging contacts
of different origins. To some extent this can br done automatically through
matching of properties; sometimes this requires user intervention - most
clients I have used have some way of showing merges or changes.

Importing a GROUP with MEMBERS that is self-consistently defined is not
going to magically solve this, as merging the individual contacts will still
be a problem if there is any overlap between sources. Importing where
CATEGORIES overlap between new source and current collection is going to
require either asking the user about merging categories, or separating,
them, or adding a new category indicating the source so that they can still
be distinguished (if UX allows multiple category filtering).

In practice at the moment,the common pattern is enabling export (and hence
import) of a specific category; Portable Contacts defines how to use
filterBy on tags (it's CATEGORIES equivalent) to get subsets.

Looking at the CARDDAV draft, I see a similar distinction made between
addresses and collections that appear as URLs - did you later change this,
Cyrus?

http://ietfreport.isoc.org/all-ids/draft-ietf-vcarddav-carddav-10.txt

The following restrictions are applied to the resources within an
   address book collection:

   a.  Address book collections MUST only contain address object
       resources and collections that are not address book collections.
       i.e., the only "top-level" non-collection resources allowed in an
       address book collection are address object resources.  This
       ensures that address book clients do not have to deal with non-
       address data in an address book collection, though they do have
       to distinguish between address object resources and collections
       when using standard WebDAV techniques to examine the contents of
       a collection.

   b.  Collections contained in address book collections MUST NOT
       contain address book collections at any depth. i.e., "nesting" of
       address book collections within other address book collections at
       any depth is not allowed.  This specification does not define how
       collections contained in an address book collection are used or
       how they relate to any address object resources contained in the
       address book collection.

   Multiple address book collections MAY be children of the same
   collection.





>
> On 12/21/2010 01:38 PM, Joseph Smarr wrote:
>
> You're still polluting people's address books with these special
> non-contact contacts, and then you're hoping that a) they don't notice or
> care that you added these weird contacts, and b) they don't delete them and
> mess things up. That doesn't sound like a desirable situation. At best it
> sounds like a "lame situation that we hope isn't too bad". Does anyone
> disagree?
>
> On Tue, Dec 21, 2010 at 10:35 AM, Cyrus Daboo <cyrus@daboo.name> wrote:
>
>> Hi Joseph,
>>
>>
>> --On December 21, 2010 9:56:30 AM -0800 Joseph Smarr <jsmarr@gmail.com>
>> wrote:
>>
>>   Nearly all desktop contacts clients have some concept of a group like
>>>> this, so what v4 is doing is providing them with a way to exchange that
>>>> information as well as individual contacts. I think this counts as
>>>> progress.
>>>>
>>>
>>>
>>> Of course I agree that groups are a common thing that deserves some
>>> better formal support. But I think this approach is a poor hack that is
>>> likely to cause more harm than good. Were other approaches discussed,
>>> perhaps outside of individual vCards with new tags to define group info
>>> and metadata that downlevel clients would just ignore?
>>>
>>>
>>  Just to be clear, the current behavior we have for AB.app + CardDAV does
>> not cause any problems. Yes, it does mean that users of clients that do not
>> understand the X-KIND value see groups as contacts, but those "contacts"
>> have the group name and apart from that appear totally empty (no email
>> address etc). Provided those clients correctly "roundtrip" those vcards (and
>> in theory there is no reason they would write them back to the server since
>> users will simply not edit them) then everything is fine (except for the
>> case where the user may be confused and deletes the "group"). There is
>> certainly no real interoperability problem here.
>>
>> What is potentially an issue is users being confused by these "group"
>> contacts. I don't think that is a big deal and the clients have easy upgrade
>> paths to deal with that: (1) simply ignore the KIND:group, (2) fully support
>> groups. Now (1) may be an issue if the client deletes a contact in a group -
>> that would lead to a group with a non-existent member - but that is a
>> situation that can arise for any number of reasons and is something "group
>> aware" clients will have to deal with regardless.
>>
>>
>> --
>> Cyrus Daboo
>>
>> _______________________________________________
>> VCARDDAV mailing list
>> VCARDDAV@ietf.org
>> https://www.ietf.org/mailman/listinfo/vcarddav
>>
>
>
> _______________________________________________
> VCARDDAV mailing listVCARDDAV@ietf.orghttps://www.ietf.org/mailman/listinfo/vcarddav
>
>
> --
>
> Mike Douglass                           douglm@rpi.edu
> Senior Systems Programmer
> Communication & Collaboration Technologies      518 276 6780(voice) 2809
> (fax)
> Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180
>
>
> _______________________________________________
> VCARDDAV mailing list
> VCARDDAV@ietf.org
> https://www.ietf.org/mailman/listinfo/vcarddav
>
>