Subject: [VCARDDAV] how to represent distribution lists

From: Helge Hess <[email-masked]>
Date: Fri, 16 May 2008 15:54:36 +0200

Hi,

is there already a concept on how to represent distribution lists in  
CardDAV? (or vCard in general?)
Files with multiple vCards in them, subcollections, a single vCard  
with multiple EMAIL fields, ...

Thanks,
   Helge
-- 
Helge Hess
http://www.zideone.com/
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Simon Perreault <[email-masked]>
Date: Fri, 16 May 2008 10:06:18 -0400

On Friday 16 May 2008 09:54:36 Helge Hess wrote:
> Files with multiple vCards in them,

This is not possible with vCard 3.0. With vCard 4.0 it looks like you will be 
able to reference other vCards with a URI or UID, but it's still being 
discussed.

> a single vCard 

You can already do that with vCard 3.0. It's perfectly legal to have, say,

FN:Distribution list
EMAIL:[email-masked]
EMAIL:[email-masked]
...
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Helge Hess <[email-masked]>
Date: Fri, 16 May 2008 16:15:23 +0200

On 16.05.2008, at 16:06, Simon Perreault wrote:
>> a single vCard with multiple EMAIL fields, ...
>

Yes, would be OK for storage, but the semantics are different. We  
would need an additional marker field, like

   X-ABShowAs:COMPANY
   X-ABUseAs:DISTLIST

Hm. Which BTW, is also useful and it would be nice if there would be  
some way to say that a vCard represents a company.

I wonder whether we should better represent distlists in the WebDAV  
context as WebDAV collections. The PROPFIND result could point to the  
URLs of the real vCards (which then should have proper content- 
location headers).

Thanks,
   Helge

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 16 May 2008 10:41:48 -0400

Hi Helge,

> URLs of the real vCards (which then should have proper content-

Check out 
<http://www.ietf.org/internet-drafts/draft-ietf-vcarddav-vcardrev-01.txt>. 
There is a new KIND property that is meant to indicate what the vcard 
represents. Values include "individual" and "org" - the later implying that 
it represents a company.

For group support we need values for "group" and "distributionlist" to 
cover those two cases as well. In the case of "group" we need a MEMBERS 
property that lists the URIs or UIDs of vcards that are members of the 
group.

Note there has been some debate in the past as to how to represent groups. 
Two approaches discussed are:

1) "Group" vCard that lists the members by reference. Note you can also 
embed vCards, so they could be referenced by value too, if that made sense 
in certain cases.

2) Groups are represented as "tag" property values on individual vcards. 
e.g. to add someone to the group "Friends" you would add "Friends" as a 
value to a new GROUPS property (or maybe we re-use CATEGORIES for that).

3) A hybrid of (1) and (2).

I think (1) is better than (2). There are several problems with (2), 
including the inability to make groups members of other groups. Also, with 
(2), there is a big security concern as its possible for group membership 
details to leak out in individual vcards. e.g. I send someone my vcard and 
that exposes all the groups I have setup in my address book and to which I 
added myself as a member. The person receiving the vcard can see those and 
send me back their vcard modified to make them members of those groups. If 
I wasn't careful someone could silently insert themselves into my groups 
and that would be bad. The way around that is to require clients to strip 
out the group property when sending or receiving vcards - somehow I don't 
think we can or should rely on that. Plus it means you can't exchange group 
information with other people if you really want to.

So all in all I would like to see (1) as the solution.

I would also like to see this issue resolved soon.

-- 
Cyrus Daboo

---

From: Simon Perreault <[email-masked]>
Date: Fri, 16 May 2008 10:42:41 -0400

On Friday 16 May 2008 10:15:23 Helge Hess wrote:
> We would need an additional marker field, like
>
>    X-ABShowAs:COMPANY
>    X-ABUseAs:DISTLIST
>

This is all in the works for vCard 4.0. :)

> URLs of the real vCards (which then should have proper content-

In vCard 4.0 you will be able to do something like this:

BEGIN:VCARD
VERSION:4.0
FN:My funky distribution list
KIND:group
MEMBER:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
MEMBER:...
END:VCARD

BEGIN:VCARD
VERSION:4.0
FN:Joe Member
UID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
EMAIL:[email-masked]
END:VCARD

With CardDAV, you can do first a report on the group vCard, fetching only the 
MEMBER properties. Then for each one you do a report, fetching the EMAIL 
property for those with matching UID properties.

Hmmm, now that I think about it, you would have to do one query for each 
member, which is wrong. You cannot get all the results in one shot for a 
report because the result has to match all prop-filter instead of just one.

We would need something like:

<filter mode="or">
  <prop-filter name="UID"><text-match 
match-type="equals">urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6</text-match></prop-filter>
  <prop-filter name="UID">...
</filter>

Cyrus? What's your take on this? Am I making sense?
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 16 May 2008 10:59:45 -0400

Hi Simon,

--On May 16, 2008 10:42:41 AM -0400 Simon Perreault 
<[email-masked]> wrote:

> With CardDAV, you can do first a report on the group vCard, fetching only
> the  MEMBER properties. Then for each one you do a report, fetching the
> EMAIL  property for those with matching UID properties.
>
> match-type="equals">urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6</text-m
> atch></prop-filter>   <prop-filter name="UID">...
> </filter>
>

If the MEMBER property contains http URLs to the vcards on the carddav 
server then you could use the multiget REPORT to get all the vcards for a 
group. Alternatively, as is likely for a lot of desktop clients at least, 
clients will likely have all the individual vcards cached and will simply 
do the uuid lookups out of their local cache. For limited capacity devices 
that may not be the case.

Note there was some discussion before about the query report's lack of 
boolean operators. The suggest I came up with was to support a simple 
"anyof" and "allof" operator for queries. In that case the following would 
work for group expansion:

<filter test="anyof">
  <prop-filter name="UID"><text-match
match-type="equals">urn:uuid:XXX1</text-match></prop-filter>
  <prop-filter name="UID"><text-match
match-type="equals">urn:uuid:XXX2</text-match></prop-filter>
  <prop-filter name="UID">...
</filter>

This approach is simple and does not require any complex nested boolean 
behavior. I am proposing to add this to the next carddav revision (which I 
am working on right now).

An alternative would be to have a new "group_expand" report that, when run 
on a "group" vcard, would expand all the members and return the results in 
the usual multistatus response. That would have the added option of doing 
depth:1 or depth:infinity expansion (i.e. with infinity any members that 
are themselves groups would be further expanded). This would be a little 
more compact than the query, and has the added depth:infinity behavior. I 
am not sure whether that is enough justification for adding another report 
though.

-- 
Cyrus Daboo

---

From: Simon Perreault <[email-masked]>
Date: Fri, 16 May 2008 11:11:42 -0400

> that may not be the case.

You're right. But uisng HTTP URLs means that you're tying the data to a 
particular location. Sizeable disadvantage. I think I'd prefer using UIDs for 
local vCards (i.e. in the same collection). And if there was a central UID 
lookup thingie then I'd happily use UIDs all the way. :)

> am working on right now).

+1

> am not sure whether that is enough justification for adding another report

Yeah, I'm not sure either. Maybe leave it for a future extension RFC if 
there's a demand for it...
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Helge Hess <[email-masked]>
Date: Fri, 16 May 2008 17:21:26 +0200

On 16.05.2008, at 16:41, Cyrus Daboo wrote:
> Check out <http://www.ietf.org/internet-drafts/draft-ietf-vcarddav-vcardrev-01.txt 
> >.

Ah, thanks. Haven't seen that yet.

> Note there has been some debate in the past as to how to represent  
> groups. Two approaches discussed are:
>
> 1) "Group" vCard that lists the members by reference. Note you can  
> also embed vCards, so they could be referenced by value too, if that  
> made sense in certain cases.
>
> 2) Groups are represented as "tag" property values on individual  
> vcards. e.g. to add someone to the group "Friends" you would add  
> "Friends" as a value to a new GROUPS property (or maybe we re-use  
> CATEGORIES for that).
>

Personally I dislike approach 2. If the user wants that, he can  
already filter by keyword/category. Thats not like forming a real set  
by identity.

Reference by UID, URL and/or EMAIL would be preferably (I think by- 
EMAIL would be quite helpful for many clients). Consider a GROUP like  
the ATTENDEE set in a VEVENT.

Thanks,
   Helge
-- 
Helge Hess
http://www.helgehess.eu/

---

From: Simon Perreault <[email-masked]>
Date: Fri, 16 May 2008 11:26:23 -0400

> the ATTENDEE set in a VEVENT.

Well, that won't happen because EMAIL is not restricted to be unique across 
vCards.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Helge Hess <[email-masked]>
Date: Fri, 16 May 2008 17:31:58 +0200

On 16.05.2008, at 17:26, Simon Perreault wrote:
>> EMAIL would be quite helpful for many clients). Consider a GROUP  
>> like the ATTENDEE set in a VEVENT.
> Well, that won't happen because EMAIL is not restricted to be unique  
> across vCards.

Ups, sorry, I wrote GROUP. Of course I meant distribution list. Its no  
problem in that case (in fact its usually exactly that, a simple list  
of emails :-). Same thing like VEVENT ATTENDEEs.

Thanks,
   Helge

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 16 May 2008 11:36:06 -0400

Hi Simon,

--On May 16, 2008 11:11:42 AM -0400 Simon Perreault 
<[email-masked]> wrote:

>> do the uuid lookups out of their local cache. For limited capacity
>> devices that may not be the case.
>
> particular location. Sizeable disadvantage. I think I'd prefer using UIDs
> for  local vCards (i.e. in the same collection). And if there was a
> central UID  lookup thingie then I'd happily use UIDs all the way. :)

Ok - well that points to one problem them. The query report has to be 
targeted at a resource. Typically that would be an address book collection 
or perhaps the user's address book home. What you really need with uuid 
searches though is a server-wide search across any address books accessible 
to the user. That probably means doing a query on the root resource / with 
Depth:infinity. A smart server would maintain a database of uuid->uri 
mappings and could return matches using that. However, most servers are not 
going to want to support depth:infinity reports on arbitrary properties 
because those will be expensive (unless everything is indexed in one big 
database). In that case the specialized group-expansion report might be 
better as that is something servers can specifically optimize for.

I think this is important, because I can imagine servers offering a 
shared/public address book contain the vcards of all the users on the 
server. Then I would expect users to reference the vcards in that address 
book in their own groups. So the group expansion query needs to be able to 
target the shared/public address book in some way. Maybe we just require 
clients to run the query report on all the address books they have access 
to, but that may be a lot of queries.

I am not sure this is an area we should dwell on too much now. I would 
rather get the simple base spec out now and then look at some of the more 
complex sharing behavior later - noting that CalDAV also needs work in that 
area we should probably come up with a common solution.

I suspect deployment experience with CardDAV will go a long way to 
highlighting use cases that need to be optimized via extensions. Certainly 
that is how things are developing with CalDAV.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 16 May 2008 11:46:27 -0400

Hi Helge,

> of emails :-). Same thing like VEVENT ATTENDEEs.

OK, so thinking about this I think what we need is a just a KIND:group, but 
allow the MEMBER property value to be an embedded vCard in addition to a 
uuid. So a "pure" distribution list would just be a group where all the 
MEMBER's are embedded vCards, and a "pure" group would have all MEMBER's as 
urn:uuid's, but you could also have a mixture of both.

BEGIN:VCARD
KIND:group
FN:Daboo Family
MEMBER;TYPE=VCARD:BEGIN:VCARD\nFN:Cyrus Daboo\nEMAIL:[email-masked]\n
 IM:jabber:[email-masked]\nEND:VCARD
MEMBER;TYPE=VCARD:BEGIN:VCARD\nFN:Kim Daboo\nEMAIL:[email-masked]\n
 IM:jabber:[email-masked]\nEND:VCARD
...
END:VCARD

-- 
Cyrus Daboo

---

From: Simon Perreault <[email-masked]>
Date: Fri, 16 May 2008 11:52:33 -0400

>  IM:jabber:[email-masked]\nEND:VCARD

Why? What are you trying to achieve? Does this achieve the same goal? It's 
much easier on the parser.

BEGIN:VCARD
KIND:group
FN:Daboo Family
MEMBER:urn:uuid:blah1
MEMBER:urn:uuid:blah2
...
END:VCARD
BEGIN:VCARD
UID:urn:uuid:blah1
FN:Cyrus Daboo
EMAIL:[email-masked]
IM:jabber:[email-masked]
END:VCARD
BEGIN:VCARD
UID:urn:uuid:blah2
FN:Kim Daboo
EMAIL:[email-masked]
IM:jabber:[email-masked]
END:VCARD
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Helge Hess <[email-masked]>
Date: Fri, 16 May 2008 18:50:05 +0200

On 16.05.2008, at 17:52, Simon Perreault wrote:
>> OK, so thinking about this I think what we need is a just a  
>> KIND:group, but allow the MEMBER property value to be an embedded  
>> vCard in addition to a uuid. So a "pure" distribution list would  
>> just be a group where all the MEMBER's are embedded vCards, and a  
>> "pure" group would have all MEMBER's as urn:uuid's, but you could  
>> also have a mixture of both.
>>
>> BEGIN:VCARD
>> KIND:group
>> FN:Daboo Family

This sounds OK.

> IM:jabber:[email-masked]

I guess it would be OK too, but is it really easier to parse? I  
wouldn't say so. You still need to resolve the UIDs which is not  
necessary in Cyrus' example.
While I also kinda dislike the nested vCards, it seems to represent  
well what a distlist is.

Also: are multiple vCards in one resource allowed in CardDAV? (UID<- 
 >href relship)

Well, actually, to make it really easy, why can't we have emails in  
MEMBERs. I'm not sure why you are so opposed to this, using the email  
address to locate contacts is really quite common (this is no  
different to ATTENDEE). And in the case of distlists you don't even  
need to locate them, you just send them mail :-)

Thanks,
   Helge

---

From: Simon Perreault <[email-masked]>
Date: Fri, 16 May 2008 13:20:31 -0400

> While I also kinda dislike the nested vCards, it seems to represent

What about this one:

BEGIN:VCARD
KIND:group
FN:Funky families
MEMBER;TYPE=VCARD:BEGIN:VCARD\nKIND:group\nFN:Daboo Family\n
 MEMBER;TYPE=VCARD:BEGIN:VCARD\\nFN:Cyrus Daboo\\n
 EMAIL:[email-masked]\\nIM:jabber:[email-masked]\\nEND:VCARD\n
 MEMBER;TYPE=VCARD:BEGIN:VCARD\\nFN:Kim Daboo\\n
 EMAIL:[email-masked]\\nIM:jabber:[email-masked]\\nEND:VCARD
...
END:VCARD

Do you want to parse that? I'm pretty sure I made at least one mistake.

If we can eliminate the recursive parser it would be a good thing IMHO.

> Also: are multiple vCards in one resource allowed in CardDAV? (UID<-

No. But then it's easy, you just issue a REPORT request and let the server do 
the hard work for you.

> need to locate them, you just send them mail :-)

Because vCard is a format for representing people, not distribution lists. We 
can make it easy for you to make a group of people that you will call a 
distribution list, but even then people are not required to have email 
addresses.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Helge Hess <[email-masked]>
Date: Fri, 16 May 2008 20:08:36 +0200

...
> Do you want to parse that? I'm pretty sure I made at least one  

Sure, no problem with that.

> If we can eliminate the recursive parser it would be a good thing  

As mentioned I agree (if we _can_ ;-).

> No. But then it's easy, you just issue a REPORT request and let the  
> server do the hard work for you.

What I meant is a 'Contacts' collection, eg:
   /contacts/
     distlist.vcf
       vcard:begin ... uid:distlist
       vcard:begin ... uid:helge
       vcard:begin ... uid:cyrus
     cyrus.vcf
       vcard:begin ... uid:cyrus

Means with your suggestion you have the same UID at the top-level, in  
multiple resources of one collection. This is going to hurt and the  
reason why nested vCards sound better for the specific case.

> Because vCard is a format for representing people, not distribution  
> lists. We can make it easy for you to make a group of people that  
> you will call a distribution list, but even then people are not  
> required to have email addresses.

Well, yes, I initially asked for advise whether there is a way to  
represent distlists in vCard. This wasn't meant to start a huge  
discussion, I just wanted to hear about approaches :-)

In fact I still think that subcollections with content-location are  
the most beautiful solution (but also the most complicated, probably  
not viable).

Thanks,
   Helge

---

From: Simon Perreault <[email-masked]>
Date: Fri, 16 May 2008 14:20:43 -0400

> reason why nested vCards sound better for the specific case.

I'm sorry I don't understand what you mean. I might be slow. Could you be more 
explicit?
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: "Javier Godoy" <[email-masked]>
Date: Fri, 16 May 2008 16:51:06 -0300

Hi you all, I'm joining this discussion rather late... but here are my 0.02

First, I must say I also favour the approach of groups listing their members
instead of group tags on each member.

> If we can eliminate the recursive parser it would be a good thing IMHO.

I think so. A vCard-stream (which may be a DAV:multistatus response or
whatever) is an elegant solution. For instance, you may recover only a vCard
about a distribution list (with or without membership information), or you
may recover the group vCard and the members' vCards too.

>> MEMBERs.

That is good because it could be a distribution list for sending  phone
calls, SMS, postal mail or carrier pigeons ;-). Though I think these use
cases are much less frequent that email distribution list; and we could make
things easier for the expected usage of this feature.

IMHO, the main advantage of having a vCard instance for each member is that
it allows storing other information about each member (such as full name or
alternate mail addresses).
However, in the simpler case such additional information will not be
available or will not be represented. I'm afraid it may result in several
records such as:

BEGIN:VCARD
 FN:vCardDAV
 KIND:group
 MEMBER:urn:uuid:1e9d778f-f0b0-4b1b-8d35-a59a6d109e89
 MEMBER:urn:uuid:0f4a41c9-371e-43c4-b84f-5c764c63077e
 ...
END:VCARD

BEGIN:VCARD
 FN: [email-masked]
 EMAIL:[email-masked]
 UID:urn:uuid:1e9d778f-f0b0-4b1b-8d35-a59a6d109e89
 VERSION:4.0
END:VCARD
...

Furthermore, I have no clue (other than assuming that email identifies
people) for realizing that FN:[email-masked] is the same entity
which I have stored in my own (personal) address book as FN:Simon Perreault
(with a different UID, unless Simon had provided his UID when subscribing
and I had stored the original vCard from him).
Having said so, I think the following should not harm:

BEGIN:VCARD
 FN:vCardDAV
 KIND:group
 MEMBER:mailto:[email-masked]
 MEMBER:...
 ...
END:VCARD

Of course here the MEMBER URI is not identifying a vCard UID, which diverts
from the original intent, and I am dubious about this point.

Hope that helps

Best Regards

Javier

---

From: Helge Hess <[email-masked]>
Date: Fri, 16 May 2008 22:05:34 +0200

On 16.05.2008, at 20:20, Simon Perreault wrote:
> I'm sorry I don't understand what you mean. I might be slow.

Ah, common ;-)

> Could you be more explicit?

Sure. I don't know what is planned for CardDAV, but in a CalDAV  
collection there is a 1:1 mapping between a collection child resource  
and a UID.
That is, a UID must only occur in exactly one leaf HTTP resource. And  
a HTTP resource may only contain a single UID.

In my/your example above the UID 'cyrus' is contained in two HTTP  
resources, distlist.vcf and cyrus.vcf.
Since CardDAV REPORTs only address the top-level structure of the  
vCards(?), not nested vCards, this UID limit is not a problem if we  
use nested vCards for list members. (the nested UID isn't seen/ 
processed by the server)

http://tools.ietf.org/html/rfc4791#section-4.1
"Calendar components in a calendar collection that have different UID  
property values MUST be stored in separate calendar object resources.  
Calendar components with the same UID property value, in a given  
calendar collection, MUST be contained in the same calendar object  
resource."

Hope you can follow, not sure whether I explained well enough.

Thanks,
   Helge

---

From: Simon Perreault <[email-masked]>
Date: Fri, 16 May 2008 16:19:37 -0400

> resources, distlist.vcf and cyrus.vcf.

Ah, I understand where the misunderstanding was. :)

What I suggested was to use flat vCards (as opposed to nested) and refer to 
them via either UID or URI.

When they are on a CardDAV server, they are represented as separate resources. 
You just do a REPORT request and filter on the UID property (or a multiget 
REPORT on all the URIs) to get them all at once.

> use nested vCards for list members. (the nested UID isn't seen/

That could even be considered a bug.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: "Darryl Champagne" <[email-masked]>
Date: Fri, 16 May 2008 23:21:37 -0400

I think it is also helpful to remember that other standards bodies have done
work on groups and distribution lists....

As perhaps a lesser known example, the Liberty Alliance, with its People
Service:
http://www.projectliberty.org/liberty/specifications__1
 
http://www.projectliberty.org/liberty/content/download/3471/23039/file/liber
ty-idwsf-people-service-1.0-errata-v1.0.pdf

Of course, they also did their own contact information XML, address cards,
with their Personal Profile
http://www.projectliberty.org/liberty/content/download/1028/7146/file/libert
y-idsis-pp-v1.1.pdf, and Employee Profile
http://www.projectliberty.org/liberty/content/download/1031/7155/file/libert
y-idsis-ep-v1.1.pdf.  It is interesting to note the additional fields they
needed, that are not in vCard, such as Legal Identity, an extended Marital
status (single / married / commonlawmarriage / separated / divorced /
widowed / dead / notapplicable), companies informal name, local script
versions of _every_ field (similar to YomiName), Façade, Birthday without a
year, Public Key, Emergency contact and so on. 

Note that those are XML based services, not pure storage, but there is a
fair bit of overlap.

I'm not saying to go and add all those fields - I am just pointing out other
existing prior art.

dgc

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Cyrus Daboo
> Sent: Friday, May 16, 2008 11:46 AM
> To: Helge Hess; [email-masked]
> Subject: Re: [VCARDDAV] how to represent distribution lists
> 
> Hi Helge,
>