Re: [VCARDDAV] KIND in draft 15

[Mike Douglass <[e-mail]>]

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.

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.

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 <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Hi Joseph,
>
>
>     --On December 21, 2010 9:56:30 AM -0800 Joseph Smarr
>     <[e-mail] <mailto:[e-mail]>> 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
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/vcarddav
>
>
>
> _______________________________________________
> VCARDDAV mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vcarddav

-- 

Mike Douglass                           [e-mail]
Senior Systems Programmer
Communication&  Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180