Subject: [VCARDDAV] KIND in draft 15

From: Kevin Marks <[email-masked]>
Date: Thu, 16 Dec 2010 14:09:11 -0800

I welcome dropping 'thing', but still have reservations about the way
'group' is defined, as others have said previously.

As mentioned before, there are two very widespread kinds of entries in
address books that would benefit from having different treatment by
user agents - mailing lists, and automated responders.

I'd suggest we add KIND's for these

Add 'list' for mailing lists and similar addresses that need different
treatment by user-agents (eg gmail's category error of insistently
trying to invite mailing lists to gtalk).

Add 'automated' for the kinds of auto responder email addresses that
updates from social networks, banks and the like.

Also, we shoudl have examples of these types - we need one for location

Giving text:

The value may be one of: "person" for a single person, "list" for an
address corresponding to a list of people (eg a mailing list), "org"
for an organization, "location" for a named geographical place,
"automated" for an automated system (eg a social network notifier,
bank address), an x-name or an iana-token.  If this property is
absent, "person" MUST be assumed as default

examples:

Special notes:

The value may be one of: "individual" for a single person, "group" for
a group, "org" for an organization, "location"for a named geographical
place, "list" for an address corresponding to a list of people (eg a
mailing list),  "automated" for an automated system (eg a social
network notifier, bank address), an x-name or an iana-token.  If this
property is absent, "individual" MUST be assumed as default.

   ABNF:

     KIND-param = "VALUE=text" / any-param
     KIND-value = "individual" / "group" / "org" / "location" / "list"
/ "automated"
                / iana-token / x-name

   Example:

      This represents the VCARD Mailing list:

         BEGIN:VCARD
         VERSION:4.0
         KIND:list
         FN:VCARD Mailing List
         EMAIL:[email-masked]
         ORG:Internet Engineering Task Force.;Network Working Group;
         END:VCARD

      This represents the VCARD Mailing list autoresponder:

         BEGIN:VCARD
         VERSION:4.0
         KIND:automated
         FN:VCARD List bot
         EMAIL:[email-masked]
         ORG:Internet Engineering Task Force.;Network Working Group;
         END:VCARD

---

From: Simon Perreault <[email-masked]>
Date: Fri, 17 Dec 2010 08:51:05 -0500

> updates from social networks, banks and the like.

I think this should go into an extension. I see no reason for putting
this in the base spec.

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 17 Dec 2010 08:37:18 -0700

<hat type='individual'/>

> I think this should go into an extension. I see no reason for putting

Agreed.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Tantek Çelik <[email-masked]>
Date: Mon, 20 Dec 2010 10:59:44 -0800

>> I think this should go into an extension. I see no reason for putting

I agree with putting Kevin's suggestions:

* LIST - for describing a vCard object that represents a mailing list
* ROBOT - for automated, auto responder/notification email addresses,
e.g. used for updates from social networks, banks and the like

into an extension.

However I *also* think that

* GROUP

should be dropped from 6.1.4 and also be put into such an extension.

In my opinion, "GROUP" is far more abstract (lacks documented real
world user interfaces / implementations - if not - please cite the
research documentation) than *either* LIST or ROBOT.

Whereas right now, in my Gmail contacts for example, I *do* have
*several* email addresses (and thus contacts) for LISTs and ROBOTs.  I
don't have any for GROUPs.

I realize this is only one anecdote, and I invite others to post their
own or provide documentation of better research/data.

Thanks,

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

---

From: Simon Perreault <[email-masked]>
Date: Mon, 20 Dec 2010 14:04:41 -0500

> should be dropped from 6.1.4 and also be put into such an extension.

Note that the working group consensus from Beijing seems to be pointing
in the other direction.

> research documentation) than *either* LIST or ROBOT.

I have used tons of address book programs that let me organize contacts
into groups... Is my experience not ordinary?

> don't have any for GROUPs.

Can you point at the GUI elements in Gmail that let you tag these
addresses as LISTs and ROBOTs?

Actually, Gmail is a good example of a UA that lets you organize
contacts into groups.

Simon

---

From: Tantek Çelik <[email-masked]>
Date: Mon, 20 Dec 2010 11:16:38 -0800

> into groups... Is my experience not ordinary?

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.

There is data yes, but it does not imply the creation of a "GROUP"
value for KIND.

> addresses as LISTs and ROBOTs?

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.

And yes, due to the lack of specific implementation/GUI - I support
trying KIND:LIST and KIND:ROBOT as *extensions* rather than putting
them into core.

> Actually, Gmail is a good example of a UA that lets you organize

Same as Apple Address Book.  The "groups" in gmail are merely CATEGORIES.

In fact if you create a group, it does *nothing* on its own. It is
*not* a contact itself.

When you add a contact to a gmail contacts group, all it does it add
the name of the group as a category to that contact.

This is readily obvious when you click on the contact itself, and it
shows the list of groups that the contact is in merely as a list of
labels/tags.

Again, the existing GUI for "group" is already handled by the existing
vCard CATEGORIES feature, and does not justify the addition of a new
feature.

Tantek

---

From: Simon Perreault <[email-masked]>
Date: Mon, 20 Dec 2010 14:48:39 -0500

> themselves, but rather as CATEGORIES on the contacts that are in the

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.

> 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

---

From: Helge Hess <[email-masked]>
Date: Mon, 20 Dec 2010 12:47:16 -0800

> themselves, but rather as CATEGORIES on the contacts that are in the

In the case of Apple AB the groups ARE represented as vCard objects. (and also added to CATEGORIES as a secondary).

hh

---

From: Tantek Çelik <[email-masked]>
Date: Mon, 20 Dec 2010 14:10:18 -0800

On Mon, Dec 20, 2010 at 11:48, Simon Perreault
<[email-masked]> wrote:
> Yes, this is one way that they can be implemented.

This is is how they *are* *interoperably* implemented today.

If you know of any other examples that implement groups differently,
please provide them.

All examples / evidence provided to date shows *one* type of
implementation - group = category on the vcards in the group. Nothing
more.

> But it only allows
> for a group name, nothing more.

Correct.

I just checked Apple Address Book (v5.0.2 on OSX10.6.4) and Gmail
Contacts and both UIs allow for a group name, nothing more.

> Any UA that allows the user to input

I claim theoretical.

If there are "plenty of such UAs", please name specific names,
versions, (and preferably URLs). None have been provided so far.

> It seemed to make consensus at the time.

I agree with that general principle - thank you for pointing it out -
it will help weed out and simplify the current draft even further.

Bigger question: is there any public documentation by anyone in this
group of existing vCard implementations' features that we can use to
reason about for consideration of new features (or dropping unused
features) ?

If not, I will volunteer to start a wiki page - all this gets lost in email.

> introducing such a feature in base vCard 4.

Agreed. This is reasonable analysis as well.

> implementations needs to be in the vCard 4 core spec".

Possibly. In this case it may have just been that developers decided
that "groups" merely provide an easier to understand user interface
model on top of the data model of "categories".

I think we can use a bit of Occam's razor here - the simplest
explanation is one that doesn't require any additional features, and
thus that's what we should take.

> KIND:LIST or KIND:ROBOT.

Agreed.

> That's not to say that current UAs cannot
> as such (e.g. by toggling a checkbox).

Agreed. On the contrary, Apple Address Book does have a [ ] Company checkbox.
Per the same reasoning, note that it DOES NOT have a [ ] Group checkbox.

> Obviously that currently wouldn't

Neither do I. Hence I agree that these belong in a possible
*extension*, not in the core.

> In the case of Apple AB the groups ARE represented as vCard objects. (and also added to CATEGORIES as a secondary).

This is false (as far as can be proven/demonstrated from the user
interface, which is all that we can reasonably argue about).

I just used Apple Address Book (v5.0.2 on OSX10.6.4) to create a new
group, two new contacts, add the contacts to the group, and then
export the group as VCF.

The result was a VCF with the two contacts, with category of the group name.

Nothing more.

No vCard objects representing the groups.

In short:

Both the concrete implementations discussed in this thread so far:
* Apple Address Book
* Google Contacts

agree 100% on how Groups work, and that they only:
* specify group name
* affect the contacts in the group by adding to the CATEGORIES
property of each of the included contacts the name of the group.

And that's it.

None of them have:
* an X-KIND property
* vCard objects in VCF export that represent the groups themselves.

If anything, this evidence points to a suggestion to add informative
language to the draft stating if your vCard application has a notion
of groups, that it should use CATEGORIES on individual vCard objects
to indicate which groups they are in, since that is established
current *interoperable* practice.

Let's document what is already interoperably implemented, instead of
creating a new duplicate mechanism.

Tantek

---

From: Helge Hess <[email-masked]>
Date: Mon, 20 Dec 2010 17:54:54 -0800

On Dec 20, 2010, at 2:10 PM, Tantek Çelik wrote:
> This is false

Take a look at the title of this mailing list [VCARDDAV], then try again.

hh

---

From: Kevin Marks <[email-masked]>
Date: Mon, 20 Dec 2010 18:31:09 -0800

That was a spectacularly gnomic and unhelpful response, Helge.

The case for group has not been made.

On Mon, Dec 20, 2010 at 5:54 PM, Helge Hess <[email-masked]>wrote:

> >> In the case of Apple AB the groups ARE represented as vCard objects.
> (and also added to CATEGORIES as a secondary).
> > This is false
>
> _______________________________________________
> VCARDDAV mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vcarddav
>

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 20 Dec 2010 21:35:31 -0500

Hi,

> Take a look at the title of this mailing list [VCARDDAV], then try again.

Let me clarify in detail: AddressBook's CardDAV support does represent 
groups as vCards on the server. When we were working on this implementation 
we were hoping that vCard v4 would be done so we could leverage that (the 
KIND property). However, we had to stick with vCard v3, but we basically 
followed the v4 model by having an X-ADDRESSBOOKSERVER-KIND property for 
the KIND, and X-ADDRESSBOOKSERVER-MEMBER properties for the membership 
list. We also use the CATEGORIES on the individual vCard records to show 
which groups they belong to (though the group vCard membership list is 
definitive).

So as far as I am concerned KIND is important.

-- 
Cyrus Daboo

---

From: Kevin Marks <[email-masked]>
Date: Mon, 20 Dec 2010 18:43:14 -0800

When you say the KIND/MEMBER is definitive, does that imply the CATEGORIES
may be inconsistent?

On Mon, Dec 20, 2010 at 6:35 PM, Cyrus Daboo <[email-masked]> wrote:

> Hi,
>
>
> --On December 20, 2010 5:54:54 PM -0800 Helge Hess <
> [email-masked]> wrote:
>
> followed the v4 model by having an X-ADDRESSBOOKSERVER-KIND property for the
> KIND, and X-ADDRESSBOOKSERVER-MEMBER properties for the membership list. We
> also use the CATEGORIES on the individual vCard records to show which groups
> they belong to (though the group vCard membership list is definitive).
>

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 20 Dec 2010 21:52:23 -0500

Hi Kevin,

> The case for group has not been made.

Here is the deal: simply relying on group names in CATEGORIES won't work. 
If you have a set of vCards and have a "Family" group, and I have a set of 
vCards and my own "Family" group, well those two groups absolutely have to 
be distinct, particularly when address books/vcards start to be shared. 
i.e. if I were to send you my vCard with CATEGORIES containing "Family" 
your certainly wouldn't want me to suddenly appear in your Family group.

So a requirement is that there be a group "entity" of some kind with a 
unique identifier (not its name) that can uniquely identify its membership. 
Well that is a vCard with KIND:group.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 20 Dec 2010 21:55:49 -0500

Hi Kevin,

--On December 20, 2010 6:43:14 PM -0800 Kevin Marks <[email-masked]> 
wrote:

> When you say the KIND/MEMBER is definitive, does that imply the
> CATEGORIES may be inconsistent?
>

As I mentioned in a email I just sent, 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.

-- 
Cyrus Daboo

---

From: Mike Douglass <[email-masked]>
Date: Mon, 20 Dec 2010 23:18:43 -0500

I also regard group as very important.

It is important for us to be able to represent groups as they appear in 
enterprise systems. Without KIND=GROUP I have no compact way of 
delivering the entire membership of a group.

On 12/20/2010 09:35 PM, Cyrus Daboo wrote:
> groups as vCards on the server. When we were working on this 
> implementation we were hoping that vCard v4 would be done so we could 
> leverage that (the KIND property). However, we had to stick with vCard 
> v3, but we basically followed the v4 model by having an 
> X-ADDRESSBOOKSERVER-KIND property for the KIND, and 
> X-ADDRESSBOOKSERVER-MEMBER properties for the membership list. We also 
> use the CATEGORIES on the individual vCard records to show which 
> groups they belong to (though the group vCard membership list is 
> definitive).
>

-- 

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

---

From: Andy Mabbett <[email-masked]>
Date: Tue, 21 Dec 2010 11:35:56 +0000

On 21 December 2010 02:55, Cyrus Daboo <[email-masked]> 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

---

From: Joseph Smarr <[email-masked]>
Date: Tue, 21 Dec 2010 07:55:23 -0800

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.

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 21 Dec 2010 11:06:30 -0500

Hi Joseph,

--On December 21, 2010 7:55:23 AM -0800 Joseph Smarr <[email-masked]> 
wrote:

> 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.

Well the point is we are expecting vCard v4 clients to understand the 
difference. A client that only knows about vCard v3 in theory will reject 
the v4 cards. 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.

-- 
Cyrus Daboo

---

From: Joseph Smarr <[email-masked]>
Date: Tue, 21 Dec 2010 09:56:30 -0800

the v4 cards.

Cyrus-I strongly disagree with this assumption, and I think it's very
dangerous. In practice, TONS of vCard parsers never really updated to vCard
3, and largely coasted on its backwards compatibility with vCard 2.1. Sure
they missed a bit of new stuff, but it basically worked fine. I'm quite sure
the same will happen for vCard 4--all the hundreds of millions of Outlook
clients won't be upgraded over night, and that's assuming Outlook quickly
puts in vCard 4 support in their latest version, which who knows if/when it
will happen. And ditto for a zillion websites that have built vCard
importers and deployed them with no active maintenance for several years
(since the spec hasn't changed noticeably in years).

That's why we were so concerned about things in vCard 4 that broke backwards
compatibility, like changing the sub-fields of N, because invariably that
will cause chaos as old clients blithely mis-parse vCard 4 without realizing
their assumptions are no longer valid. I think post-Beijing we addressed all
or nearly all of those situations, but KIND:GROUP still sticks out like a
sore thumb in this regard. I really think it's reckless and unrealistic to
stick non-contacts as vCards with some new property that old clients won't
know about and just say "if they don't reject newer versions of vCard,
that's their own damn fault".

> 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?

Thanks, js

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 21 Dec 2010 13:35:28 -0500

Hi Joseph,

--On December 21, 2010 9:56:30 AM -0800 Joseph Smarr <[email-masked]> 
wrote:

> 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

---

From: Simon Perreault <[email-masked]>
Date: Tue, 21 Dec 2010 13:37:13 -0500

On 2010-12-21 12:56, Joseph Smarr wrote:
> That's why we were so concerned about things in vCard 4 that broke
> backwards compatibility, like changing the sub-fields of N, because
> invariably that will cause chaos as old clients blithely mis-parse vCard
> 4 without realizing their assumptions are no longer valid. I think
> post-Beijing we addressed all or nearly all of those situations, but
> KIND:GROUP still sticks out like a sore thumb in this regard.

That's a fair point.

However, the group feature is in high demand, is well understood, and
has already been implemented in various non-standard ways. (And as Cyrus
said, using CATEGORIES for groups is just a hack.)

So, would a proposal for a *backwards-compatible* group feature have any
chance of making consensus?

Simon

---

From: Joseph Smarr <[email-masked]>
Date: Tue, 21 Dec 2010 10:38:39 -0800

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 <[email-masked]> wrote:

> 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
> 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
>

---

From: Joseph Smarr <[email-masked]>
Date: Tue, 21 Dec 2010 10:39:46 -0800

Yes, I would definitely support an approach to model groups with more
robustness than just CATEGORIES, since that's a common and useful thing to
support well--provided it doesn't confuse or pollute down-level clients,
which KIND:GROUP does.

---

From: Mike Douglass <[email-masked]>
Date: Tue, 21 Dec 2010 14:04:56 -0500

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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Joseph,
>
>
>     --On December 21, 2010 9:56:30 AM -0800 Joseph Smarr
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>             information as well as individual contacts. I think this
>             counts as
>             progress.
>
>
>
>     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
>
>     [email-masked] <mailto:[email-masked]>

--

---

From: Kevin Marks <[email-masked]>
Date: Tue, 21 Dec 2010 13:12:44 -0800

On Tue, Dec 21, 2010 at 11:04 AM, Mike Douglass <[email-masked]> wrote:

> 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.
>
> 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.
>

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.

> 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?
>
> VCARDDAV mailing [email-masked]://www.ietf.org/mailman/listinfo/vcarddav
>
>
> --
>
> Communication & Collaboration Technologies      518 276 6780(voice) 2809
> (fax)

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 21 Dec 2010 16:23:03 -0500

Hi Kevin,

--On December 21, 2010 1:12:44 PM -0800 Kevin Marks <[email-masked]> 
wrote:

> that it will pollute existing addressbooks with non-functional contacts
> by design.

What is a "non-functional" contact? It is perfectly feasible and legitimate 
for me to create an "individual" contact that just contains a name and 
nothing else. A KIND:group would be functionally equivalent to that in an 
address book that did not understand KIND:group.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 21 Dec 2010 16:39:53 -0500

Hi Kevin,

--On December 21, 2010 1:12:44 PM -0800 Kevin Marks <[email-masked]> 
wrote:

> addresses and collections that appear as URLs - did you later change
> this, Cyrus?

I am not quite sure what you are referring to here. In CardDAV we followed 
the model we have in CalDAV. There can be any number of "regular 
collections" in a user's address book home, and any number of "address book 
collections". "Address book collections" may appear inside of regular 
collections at any depth, but "address book collections" must not appear 
inside of other "address book collections" at any depth.

That later requirement basically ensures no nested address books (or 
calendars in the CalDAV case). When designing CalDAV we felt this was a 
constraint we needed to keep the protocol simple. There are clearly 
possible uses for nested collections, but the complexity of interactions 
the client might need were more than we wanted to foist on adopters of the 
protocol.

As things have turned out, the Apple clients at least currently only bother 
to look at depth:1 in the calendar or address book home collections - that 
also simplifies the client/server interaction as only a single PROPFIND 
Depth:1 is needed to discover the special collections. The need for even 
regular collection nesting just does not seem to be there. This is probably 
reasonable for calendars and address books as users are not likely to have 
large num=bers of those (as opposed to say email where users often create 
nested mailboxes/collections for organizational reasons).

-- 
Cyrus Daboo