Subject: [VCARDDAV] New indiviudal subm,ission for CardDAV extension

From: Cyrus Daboo <[email-masked]>
Date: Fri, 26 Feb 2010 14:55:22 -0500

Hi folks,
I have just uploaded 
<http://tools.ietf.org/html/draft-daboo-carddav-directory-gateway>. This is 
an extension toi CardDAV that allows the server to advertise the presence 
of a "directory gateway" address bool collection to clients. Several 
vendors have expressed interest in this, and indeed the calendarserver.org 
server does have a directory gateway, though it did not advertise it in the 
way being proposed in the new draft.

Comments welcome.

-- 
Cyrus Daboo

---

From: Simon Perreault <[email-masked]>
Date: Fri, 26 Feb 2010 15:11:56 -0500

On 2010-02-26 14:55, Cyrus Daboo wrote:
> I have just uploaded
> <http://tools.ietf.org/html/draft-daboo-carddav-directory-gateway>. This
> is an extension toi CardDAV that allows the server to advertise the
> presence of a "directory gateway" address bool collection to clients.

I am profoundly confused by the "gateway" term. What is being gatewayed, 
and from where to where?

> Several vendors have expressed interest in this, and indeed the
> calendarserver.org server does have a directory gateway, though it did
> not advertise it in the way being proposed in the new draft.

How does it do it? It seems straightforward enough that I wonder how it 
could be much different.

Thanks,
Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: Nick Zitzmann <[email-masked]>
Date: Fri, 26 Feb 2010 14:23:58 -0700

On Feb 26, 2010, at 1:11 PM, Simon Perreault wrote:

> I am profoundly confused by the "gateway" term. What is being gatewayed, and from where to where?

CalDAV has a non-standard extension where additional calendars can be made available to a user that are not present in the user's calendar home set through the group-membership DAV property. It's not in the RFC, but it's used by Google Calendar and Apple's server.

I read the spec, and it looks like this is something similar in that it makes an additional collection available to anyone who can pick it up. Which does bring up a few questions:

1. If the gateway is read-only, how is anyone supposed to add records to the gateway?
2. What makes this different from CalDAV's proxy calendars extension, other than being limited to one directory?

I think I'd prefer it if the interface for accessing other contact collections would be the same as in the CalDAV extension... Anything that stops subtle differences between CardDAV and CalDAV from appearing is good.

Nick Zitzmann
<http://www.chronosnet.com/>

---

From: Filip Navara <[email-masked]>
Date: Fri, 26 Feb 2010 22:54:39 +0100

> <http://www.chronosnet.com/>

I think there's is a misunderstanding in the purpose of the extension.
This extension is meant to allow CardDAV access to LDAP (1) directory.
This is usually the same directory that is used for user
authentication, so essentially it would provide a way to access VCARDs
for all the users of the particular Addressbook system (2).

The CalDAV calendar-proxy extension (3) is meant for sharing calendars
between different users of the same calendaring system. That is way
different from what this extension proposes.

Filip Navara
eM Client

(1) ...or DAP or whatever other protocol exists
(2) Technically this is possible by pure WebDAV ACLs + CardDAV, but it
is inefficient and hard to implement on client side
(3) ...which doesn't use the group-membership property per se, the
clients use separate calendar-read-proxy-for/calendar-write-proxy-for
properties instead...

---

From: Nick Zitzmann <[email-masked]>
Date: Fri, 26 Feb 2010 15:07:28 -0700

> for all the users of the particular Addressbook system (2).

Okay, that makes sense.

> different from what this extension proposes.

In server-side implementation, definitely. On the client side, isn't it a different way of doing the same thing (gathering an extra collection)? Wouldn't it be simpler to have one way of gathering additional collections, whether they're gateways or proxy collections? Just trying to understand...

> clients use separate calendar-read-proxy-for/calendar-write-proxy-for

Except on the servers that don't. I think Google Calendar, for instance, uses group-membership and not calendar-*-proxy-for...

Nick Zitzmann

---

From: Filip Navara <[email-masked]>
Date: Fri, 26 Feb 2010 23:32:30 +0100

> In server-side implementation, definitely. On the client side, isn't it a different way of doing the same thing (gathering an extra collection)? Wouldn't it be simpler to have one way of gathering…

If the sole purpose of the draft was collection discovery then I would
agree that having several ways to do that would be a shame, but that's
not the case. This particular collection has to be treated specially
by the client due to its nature; it is not supposed to be synchronized
to the client and many requests may not work as expected.

A typical use case in an e-mail client like ours is that a user starts
typing in a To field (or any field for contact input) and wants to get
back suggestions. We search locally synchronized contacts, but we also
support server-side search in directories (in the "LDAP" meaning of
the word) - which are too large to be synchronized and often the
protocol is not designed for synchronization. Given this CardDAV
extension it would be matter of getting one more principal property
during the account bootstrap (which we do anyway and one more property
won't hurt) and then issuing addressbook-query on the directory
collection.

In contrast the collections specified in the addressbook-home-set are
synchronized locally (either using plain WebDAV or using the
sync-collection REPORT) and treated as read-write (possibly depending
on their ACLs).

Given the confusion about the whole purpose of the draft I guess a
longer introduction and rationale in the draft would be needed.

> Except on the servers that don't. I think Google Calendar, for instance, uses group-membership and not calendar-*-proxy-for...

AFAIK the Apple CalDAV client in OS X 10.6 doesn't support delegation
on servers that don't implement the calendar-*-proxy-for properties
and the expand-property report. Google Calendar support both, albeit
both in a broken way that is just good enough for the Apple client to
work.

Best regards,
Filip Navara

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 26 Feb 2010 20:59:54 -0500

Hi Simon,

> I am profoundly confused by the "gateway" term. What is being gatewayed,

Filip seemed to do a pretty good job explaining the purpose of this. I 
think I deliberately left out talking about LDAP because I did not want it 
to be just tied to a standard directory like that - the directory could 
come from any type of database etc.

In any case, if it would clarify things by mentioning LDAP as an example, I 
can easily do that.

> How does it do it? It seems straightforward enough that I wonder how it

Our servers (both CalDAV and CardDAV) use LDAP for user accounts and 
authentication. The directory gateway basically takes a 
CARDDAV:addressbook-query and turn it into an LDAP query, then it takes the 
results of the LDAP query and maps the records and attributes to vCards 
which are returned (or cached locally on the server for later retrieval by 
the client using multiget).

I can add text such as the above as an example of how this could be 
implemented. It is by no means the only way to do it, but the key thing is 
making the directory records available as vcards.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 26 Feb 2010 21:11:46 -0500

Hi Filip,

> longer introduction and rationale in the draft would be needed.

In addition to giving an specific example of how this would be done with an 
LDAP server, I will also add comments about why this addressbook needs to 
be treated specially as you outlined in your discussion.

-- 
Cyrus Daboo

---

From: Simon Perreault <[email-masked]>
Date: Sat, 27 Feb 2010 10:44:40 -0500

On 02/26/2010 08:59 PM, Cyrus Daboo wrote:
> think I deliberately left out talking about LDAP because I did not want
> it to be just tied to a standard directory like that - the directory
> could come from any type of database etc.

Thanks, I understand the use case now.

So you have a URL behaving like a normal CardDAV collection, but it has
special properties:
- read-only
- shouldn't be cached
- should limit report sizes

If I open this collection with a normal CardDAV client that doesn't
support directory gateways, what will happen?

Also, why assume that there can only be one such URL? I understand that
the discovery feature could be limited to just one URL, but there may
exist multiple directory gateway collections per server, no? I'm
thinking that these collections need a property tagging them as being
directory gateways so that you don't need to use the discovery feature
to recognize them as being special.

Simon
-- 
DNS64 open-source   --> http://ecdysis.viagenie.ca
STUN/TURN server    --> http://numb.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: Cyrus Daboo <[email-masked]>
Date: Sat, 27 Feb 2010 13:21:17 -0500

Hi Simon,

> support directory gateways, what will happen?

So this is something I want to get feedback on. What we could do is change 
the resourcetype on this collection so its not recognized as a "normal" 
address book collection, so existing clients would not "see" it. But 
"directory gateway aware" client would spot the new resource type and know 
what to do (but they would also know about them from the principal property 
too).

Do people feel that a different resourcetype is warranted for this?

> to recognize them as being special.

So from a complexity standpoint having multiple collections requires the 
client to do multiple queries on the different URIs. The question becomes 
whether the client really cares about the different collections? What makes 
them different? Would they ever want to query just one rather than all? How 
would they distinguish between them to know which is the one they want?

My feeling is that the client is only going to want to do one "directory" 
query. If the server does have multiple sources for directory information, 
then it should be responsible for aggregating those effectively into a 
single "directory" that is used for the gateway collection. If this makes 
sense then I can add text suggesting that servers do that.

(As it turns out our server running on OS X effectively does aggregation of 
multiple directory sources via the Directory Services feature of the OS 
which supports that.)

-- 
Cyrus Daboo