Subject: [VCARDDAV] draft-daboo-carddav-directory-gateway and large/multiple directories

From: Arnaud Quillaud <[email-masked]>
Date: Thu, 11 Mar 2010 15:37:19 +0100

Hello,

As currently defined, the directory-gateway property 
(http://tools.ietf.org/html/draft-daboo-carddav-directory-gateway-01#section-3) 
points to a single carddav collection which may aggregate results from 
different sources.
I see two problems with that approach:
- In organizations with a very large number of directory entries, it 
would be much beneficial to be able to offer a choice of multiple 
collections ("all users in my Business Unit",  "all conference rooms", 
etc...).
- It might always be obvious to aggregate data from various sources, 
especially if future extensions allow for paging or sorting of results.

Hence couldn't we allow the directory-gateway property to point to a 
regular collection containing address book collections ? We could 
mandate that address book queries be supported at the root collection 
level to still allow global searches.

Arnaud Quillaud

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 11 Mar 2010 09:59:34 -0500

Hi Arnaud,

--On March 11, 2010 3:37:19 PM +0100 Arnaud Quillaud 
<[email-masked]> wrote:

> (http://tools.ietf.org/html/draft-daboo-carddav-directory-gateway-01#sect
> ion-3) points to a single carddav collection which may aggregate results
> from different sources.
> regular collection containing address book collections ? We could mandate
> that address book queries be supported at the root collection level to
> still allow global searches.

Why not provide that "filtering" via the addressbook-query report? i.e. the 
LDAP OU attribute would map to a vcard property and then the client could 
"scope" its query by filtering on that property. Yes that does require the 
client to know what vCard property to "scope" and what values might be 
appropriate.

I am wary of going too far down the road of exposing the "internals" of the 
directory and its schema via CardDAV - as stated in the document this is 
not meant as a full replacement of the directory. I think if scoped queries 
like you propose are needed, then maybe the client should use the directory 
"protocol" directly. To that end it might help if the CardDAV directory 
gateway address book had a WebDAV property listing URIs for all the sources 
of the directory data. That way if a client decided it needed to have a 
more sophisticated interaction with the directory, then it could look at 
those URIs and figure out how to do that itself.

-- 
Cyrus Daboo

---

From: Arnaud Quillaud <[email-masked]>
Date: Fri, 12 Mar 2010 13:33:22 +0100

On 3/11/10 3:59 PM, Cyrus Daboo wrote:
>> mandate
> Why not provide that "filtering" via the addressbook-query report? 
> i.e. the LDAP OU attribute would map to a vcard property and then the 
> client could "scope" its query by filtering on that property. Yes that 
> does require the client to know what vCard property to "scope" and 
> what values might be appropriate.
This means exposing the internals of the directory and schema much more 
than what I suggested. Basically, you have to configure each client 
which is totally unacceptable, especially in a large organization.
>
> I am wary of going too far down the road of exposing the "internals" 
> of the directory and its schema via CardDAV
I'm just talking about being able to access multiple corporate address 
books. This has nothing to do with exposing the internals of a 
directory. It is a concept that end users really much understand (and a 
very often used feature of MSFT Exchange BTW).
> - as stated in the document this is not meant as a full replacement of 
> the directory. I think if scoped queries like you propose are needed, 
> then maybe the client should use the directory "protocol" directly. To 
> that end it might help if the CardDAV directory gateway address book 
> had a WebDAV property listing URIs for all the sources of the 
> directory data. That way if a client decided it needed to have a more 
> sophisticated interaction with the directory, then it could look at

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 12 Mar 2010 10:06:55 -0500

Hi Arnaud,

--On March 12, 2010 1:33:22 PM +0100 Arnaud Quillaud 
<[email-masked]> wrote:

> than what I suggested. Basically, you have to configure each client which
> is totally unacceptable, especially in a large organization.

There are possible solutions to that. One example is that the server could 
advertise a set of "stored" queries that the client can use in different 
circumstances. Those would be "tagged" with suitable display names so the 
client can present them to the user who could then choose what "scope" of 
query they wanted. No direct client configuration would be required.

> books. This has nothing to do with exposing the internals of a directory.
> It is a concept that end users really much understand (and a very often
> used feature of MSFT Exchange BTW).

I am familiar with Exchanges Global Address List (GAL) feature which I 
believe appears as only a single "address book" in Outlook. Are you saying 
that more is possible? I know that in some organizations they run multiple 
Exchange servers for different business units (BU) and those of course 
would have a GAL scoped for each BU. There is nothing to prevent having 
multiple CardDAV servers for each BU in a similar way.

I do think the single directory is the most common use case for 
small/medium sized organizations so I think it best to keep it simple for 
that case. If we want to support a whole "collection" of directory 
gateways, then I suggest with add an additional, optional, property 
<CARDDAV:directory-gateway-collection> that points to a collection 
containing multiple address book collections each backed by a directory 
with different levels of scoping. Servers could advertise either of those 
properties (or we could say only one of them is allowed to be present). 
Keeping the single gateway property just makes that case more efficient as 
clients don't have to do extra Depth:1 PROPFINDs to find the one and only 
address book collection.

-- 
Cyrus Daboo

---

From: Arnaud Quillaud <[email-masked]>
Date: Mon, 15 Mar 2010 15:56:15 +0100

On 3/12/10 4:06 PM, Cyrus Daboo wrote:
>> which
> There are possible solutions to that. One example is that the server 
> could advertise a set of "stored" queries that the client can use in 
> different circumstances. Those would be "tagged" with suitable display 
> names so the client can present them to the user who could then choose 
> what "scope" of query they wanted. No direct client configuration 
> would be required.
>
>>>
>> directory.
> believe appears as only a single "address book" in Outlook. Are you 
> saying that more is possible?
Yes. Administrators have control over what corporate address books can 
be displayed from Outlook. See 
http://technet.microsoft.com/en-us/library/bb232119.aspx
> I know that in some organizations they run multiple Exchange servers 
> for different business units (BU) and those of course would have a GAL 
> scoped for each BU. There is nothing to prevent having multiple 
> CardDAV servers for each BU in a similar way.
>
> small/medium sized organizations so I think it best to keep it simple 
> for that case. If we want to support a whole "collection" of directory 
> containing multiple address book collections each backed by a 
> directory with different levels of scoping. Servers could advertise 
> either of those properties (or we could say only one of them is 
> allowed to be present). Keeping the single gateway property just makes 
> that case more efficient as clients don't have to do extra Depth:1 
> PROPFINDs to find the one and only address book collection.
I'm fine with that.

Arnaud