RE: [Ietf-carddav] carddav and corporate directories

Arnaud Quillaud <Arnaud.Quillaud@Sun.COM> Thu, 10 May 2007 13:21 UTC

Return-Path: <Arnaud.Quillaud@Sun.COM>
X-Original-To: ietf-carddav@osafoundation.org
Delivered-To: ietf-carddav@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 95A5F7F793 for <ietf-carddav@osafoundation.org>; Thu, 10 May 2007 06:21:28 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5CB9214225A for <ietf-carddav@osafoundation.org>; Thu, 10 May 2007 06:20:33 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.279
X-Spam-Level:
X-Spam-Status: No, score=-2.279 tagged_above=-50 required=4 tests=[AWL=0.319, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZoBil6C0OGS for <ietf-carddav@osafoundation.org>; Thu, 10 May 2007 06:20:28 -0700 (PDT)
Received: from gmp-ea-fw-1.sun.com (gmp-ea-fw-1.sun.com [192.18.1.36]) by laweleka.osafoundation.org (Postfix) with ESMTP id AA8B214224C for <ietf-carddav@osafoundation.org>; Thu, 10 May 2007 06:20:27 -0700 (PDT)
Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4ADKQuZ022391 for <ietf-carddav@osafoundation.org>; Thu, 10 May 2007 13:20:26 GMT
Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JHT00E01UC1EA00@d1-emea-09.sun.com> (original mail from Arnaud.Quillaud@Sun.COM) for ietf-carddav@osafoundation.org; Thu, 10 May 2007 14:20:26 +0100 (BST)
Received: from tromblon ([82.227.203.159]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JHT0056SUE1WKL0@d1-emea-09.sun.com>; Thu, 10 May 2007 14:20:26 +0100 (BST)
Date: Thu, 10 May 2007 15:20:54 +0200
From: Arnaud Quillaud <Arnaud.Quillaud@Sun.COM>
Subject: RE: [Ietf-carddav] carddav and corporate directories
In-reply-to: <0DAF7F66553622D6E86F4DED@caldav3.local>
Sender: Arnaud.Quillaud@Sun.COM
To: Cyrus Daboo <cyrus@daboo.name>, ietf-carddav@osafoundation.org
Message-id: <0JHT0056TUE1WKL0@d1-emea-09.sun.com>
MIME-version: 1.0
X-Mailer: Sun Outlook Connector 7.1.228.0
Content-type: TEXT/PLAIN; CHARSET=Windows-1252
Content-transfer-encoding: QUOTED-PRINTABLE
X-BeenThere: ietf-carddav@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ietf-carddav.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-carddav>, <mailto:ietf-carddav-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-carddav>
List-Post: <mailto:ietf-carddav@osafoundation.org>
List-Help: <mailto:ietf-carddav-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-carddav>, <mailto:ietf-carddav-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 10 May 2007 13:21:28 -0000

 

> -----Message d'origine-----
> De : Cyrus Daboo [mailto:cyrus@daboo.name] 
> Envoyé : mercredi 9 mai 2007 18:56
> À : Arnaud Quillaud; ietf-carddav@osafoundation.org
> Objet : Re: [Ietf-carddav] carddav and corporate directories
> 
> Hi Arnaud,
> 
> --On May 9, 2007 6:36:45 PM +0200 Arnaud Quillaud 
> <Arnaud.Quillaud@Sun.COM>;
> wrote:
> 
> > Although it mentions LDAP in its introduction, the spec 
> does not talk 
> > about the link between Corporate Directory access and 
> CardDAV access.
> >
> > Most PIM or email clients that would benefit from a CardDAV access 
> > also offer some access to corporate directories, usually LDAP 
> > directories. For an end user, they almost serve the same 
> purpose (e.g. 
> > when sending an email, I may select some people from my personal 
> > address book and some from my corporate directory).
> >
> > Nevertheless:
> > - configuring those clients is usually a real pain: server name and 
> > port, ssl or no ssl, base dn, search filter, bind dn, etc... - each 
> > client has to deal with schema translation between the corporate 
> > directory schema and the internal representation.
> >
> > Being able from CardDAV to discover public address books 
> would greatly 
> > enhance the user experience.  Being able to work against one format
> > (vCard) instead of 2 (vCard + some LDAP schema) would ease 
> development 
> > of address book enabled applications.
> >
> 
> There is nothing to stop a CardDAV server from also being a 
> (read-only) gateway to LDAP. i.e. the CardDAV server could 
> expose a public address book that is "backed" by an LDAP 
> server, so that addresses in the address book were actual 
> directory entries in LDAP (with the appropriate LDAP->vCard mapping).
> 
> In fact CMU had an extension to IMSP that did just that.
> 
> I don't think we need to do anything special in CardDAV 
> itself for this - an implementation could just choose to do 
> it. The only thing that might be nice would be to have some 
> WebDAV properties on the mapped addressbook indicating where 
> the underlying LDAP server is etc But I think that could be 
> written up as an extension.
> 

I aggree. One issue related to the CardDAV design is that an LDAP tree can be hierarchical when CardDAV does not allow sub addressbooks. Nevertheless, most email/pim clients flatten out the hierarchy anyway.

> The only thing that might be missing (and CalDAV has this 
> issue too) is some way for a client to discover where public 
> address books/calendars might be. At one point during the 
> CalDAV discussions there was talk of something like the IMAP 
> NAMESPACE extension - done as a WebDAV REPORT, say
> - that clients could use to find out the locations of "interesting" 
> calendars or calendar hierarchies that would be good to 
> present to the user. I still think something like that would 
> be useful and could be used for CardDAV clients to discover 
> where the "corporate directory mapped address book" is on the server.

What about simply defining another Principal Property (similar to adbk-home-set) that would contain a set of public address books ?

Unlike "interesting calendars", there is usually a very limited list of corporate directories.

Arnaud Q