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 > >
- [VCARDDAV] KIND in draft 15 Kevin Marks
- Re: [VCARDDAV] KIND in draft 15 Simon Perreault
- Re: [VCARDDAV] KIND in draft 15 Peter Saint-Andre
- Re: [VCARDDAV] KIND in draft 15 Tantek Çelik
- Re: [VCARDDAV] KIND in draft 15 Simon Perreault
- Re: [VCARDDAV] KIND in draft 15 Tantek Çelik
- Re: [VCARDDAV] KIND in draft 15 Simon Perreault
- Re: [VCARDDAV] KIND in draft 15 Helge Hess
- Re: [VCARDDAV] KIND in draft 15 Tantek Çelik
- Re: [VCARDDAV] KIND in draft 15 Helge Hess
- Re: [VCARDDAV] KIND in draft 15 Kevin Marks
- Re: [VCARDDAV] KIND in draft 15 Cyrus Daboo
- Re: [VCARDDAV] KIND in draft 15 Kevin Marks
- Re: [VCARDDAV] KIND in draft 15 Cyrus Daboo
- Re: [VCARDDAV] KIND in draft 15 Cyrus Daboo
- Re: [VCARDDAV] KIND in draft 15 Mike Douglass
- Re: [VCARDDAV] KIND in draft 15 Andy Mabbett
- Re: [VCARDDAV] KIND in draft 15 Joseph Smarr
- Re: [VCARDDAV] KIND in draft 15 Cyrus Daboo
- Re: [VCARDDAV] KIND in draft 15 Joseph Smarr
- Re: [VCARDDAV] KIND in draft 15 Cyrus Daboo
- Re: [VCARDDAV] KIND in draft 15 Simon Perreault
- Re: [VCARDDAV] KIND in draft 15 Joseph Smarr
- Re: [VCARDDAV] KIND in draft 15 Joseph Smarr
- Re: [VCARDDAV] KIND in draft 15 Mike Douglass
- Re: [VCARDDAV] KIND in draft 15 Kevin Marks
- Re: [VCARDDAV] KIND in draft 15 Cyrus Daboo
- Re: [VCARDDAV] KIND in draft 15 Cyrus Daboo