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

Cyrus Daboo <cyrus@daboo.name> Fri, 12 March 2010 15:23 UTC

Return-Path: <cyrus@daboo.name>
X-Original-To: vcarddav@core3.amsl.com
Delivered-To: vcarddav@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 402CF3A67C0 for <vcarddav@core3.amsl.com>; Fri, 12 Mar 2010 07:23:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level:
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnGjcZHXfYHx for <vcarddav@core3.amsl.com>; Fri, 12 Mar 2010 07:23:56 -0800 (PST)
Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id 643D23A6A22 for <vcarddav@ietf.org>; Fri, 12 Mar 2010 07:06:54 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 9B7571053E0B3; Fri, 12 Mar 2010 10:06:59 -0500 (EST)
X-Virus-Scanned: amavisd-new at daboo.name
Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weooc9ZVdCH2; Fri, 12 Mar 2010 10:06:59 -0500 (EST)
Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTPSA id E27281053E0A8; Fri, 12 Mar 2010 10:06:57 -0500 (EST)
Date: Fri, 12 Mar 2010 10:06:55 -0500
From: Cyrus Daboo <cyrus@daboo.name>
To: Arnaud Quillaud <Arnaud.Quillaud@Sun.COM>
Message-ID: <EAB3AF10092A8C8E41DD4969@caldav.corp.apple.com>
In-Reply-To: <4B9A3492.5010704@sun.com>
References: <4B99001F.9000801@sun.com> <AB5C9D4528C850C7BCADF499@caldav.corp.apple.com> <4B9A3492.5010704@sun.com>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size="2576"
Cc: vcarddav@ietf.org
Subject: Re: [VCARDDAV] draft-daboo-carddav-directory-gateway and large/multiple directories
X-BeenThere: vcarddav@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF vcarddav wg mailing list <vcarddav.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vcarddav>
List-Post: <mailto:vcarddav@ietf.org>
List-Help: <mailto:vcarddav-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Mar 2010 15:23:57 -0000

Hi Arnaud,

--On March 12, 2010 1:33:22 PM +0100 Arnaud Quillaud 
<Arnaud.Quillaud@Sun.COM> 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? 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