Re: [Ietf-carddav] carddav and corporate directories

Cyrus Daboo <cyrus@daboo.name> Wed, 09 May 2007 16:57 UTC

Return-Path: <cyrus@daboo.name>
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 643727F713 for <ietf-carddav@osafoundation.org>; Wed, 9 May 2007 09:57:16 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2BEF2142262 for <ietf-carddav@osafoundation.org>; Wed, 9 May 2007 09:56:21 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[BAYES_00=-2.599]
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 nlSiKLtjUk41 for <ietf-carddav@osafoundation.org>; Wed, 9 May 2007 09:56:18 -0700 (PDT)
Received: from mulberrymail.com (piper.mulberrymail.com [151.201.22.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 718ED14225D for <ietf-carddav@osafoundation.org>; Wed, 9 May 2007 09:56:18 -0700 (PDT)
Received: from [172.16.0.221] (defaultwatertownseattle.com [64.221.112.114] (may be forged)) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l49Gu91D006004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 May 2007 12:56:15 -0400
Date: Wed, 09 May 2007 09:56:04 -0700
From: Cyrus Daboo <cyrus@daboo.name>
To: Arnaud Quillaud <Arnaud.Quillaud@Sun.COM>, ietf-carddav@osafoundation.org
Subject: Re: [Ietf-carddav] carddav and corporate directories
Message-ID: <0DAF7F66553622D6E86F4DED@caldav3.local>
In-Reply-To: <0JHS007QJ8SUQPC0@d1-emea-09.sun.com>
References: <0JHS007QJ8SUQPC0@d1-emea-09.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
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: Wed, 09 May 2007 16:57:16 -0000

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.

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.

-- 
Cyrus Daboo