RE: [Ietf-carddav] carddav and corporate directories

[Arnaud Quillaud <[e-mail]>]

 

> -----Message d'origine-----
> De : Cyrus Daboo [mailto:[e-mail]] 
> Envoyé : mercredi 9 mai 2007 18:56
> À : Arnaud Quillaud; [e-mail]
> Objet : Re: [Ietf-carddav] carddav and corporate directories
> 
> Hi Arnaud,
> 
> --On May 9, 2007 6:36:45 PM +0200 Arnaud Quillaud 
> <[e-mail]>
> 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