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

[Arnaud Quillaud <[e-mail]>]

On 3/12/10 4:06 PM, Cyrus Daboo wrote:
> Hi Arnaud,
>
> --On March 12, 2010 1:33:22 PM +0100 Arnaud Quillaud 
> <[e-mail]> wrote:
>
>>> 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.
>
> 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.
>
>>>
>>> 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).
>
> 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?
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.
>
> 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.
I'm fine with that.

Arnaud