Subject: Re: [VCARDDAV] CardDAV and LDAP

From: Cyrus Daboo <[email-masked]>
Date: Thu, 24 Jul 2008 10:00:06 -0400

Hi Richard,

--On July 24, 2008 2:53:17 PM +0200 Richard Watson <[email-masked]> 
wrote:

> In the course of implementing an LDAP directory for my company, I have
> done some research into the current state of address book data. I have
> several questions and comments on the emergence of CardDAV.
>
> - Clearly the vCard standard needs some revision. Hopefully a good XML
> representation will also be developed.

And indeed that is being done in the vcarddav working group.

> - Surely it is easy to create and standardize a vCard object class in
> LDAP that extends the widely supported inetOrgPerson?

Not necessarily. There was a presentation on this issue at the original 
vcraddav BOF that explained some of the difficulties of mapping the 
multiple properties/parameters model in vCard into LDAP. It s certainly 
possible, but not straight forward.

Also bear in mind that vCard is a ubiquitous standard - nearly every 
address book app from desktop to web to mobile has support for it.

> - Instead of creating a new standard, why not address the access control
> issues of LDAP by producing a set of open-source ACL management tools,
> guides and documentation?

CardDAV isn't so much a new standard as a more refined application of an 
existing standard (WedDAV + ACL) to a specific application. Yes there are 
some new protocol elements, but it is really not that much on top of LDAP.

> - It appears that CardDAV, with support of Apple, will separate the
> serving of contact information from the serving of other user-specific
> information (such as posix account details). I agree that they do not
> need to be housed in the same data entities; however, once separated, how
> will they ever be re-associated? Is there going to be a (multi-valued) DN
> attribute (and corresponding LDAPURI attribute) in the new vCard standard
> to support cross-referencing?

The bottom line is that CardDAV is not meant to "compete" with LDAP but 
rather to complement it. The nature of information stored in a personal 
address book is different from that typically stored in LDAP. In particular 
many LDAP installations are used as the "corporate" directory system. 
Having users' personal information such as contact data for family, 
friends, business associates is often not appropriate. In a lot of cases 
the corporate directory system is read-only to end-users too. Whilst all 
that could be changed through policy decisions and use of various 
extensions there is a natural reluctance to tinker with such systems.

Instead CardDAV provides an alternative for storing personal contacts. What 
is more, CardDAV and LDAP can live together. In particular, it is entirely 
possible for the CardDAV server to expose vCards for all users in the 
directory system, so a "corporate" address book could exist in addition to 
personal address books. That would then provide a view of the single 
authoritative source for corporate contact information, whilst still 
allowing individuals to create their own personal data.

> WebDAV is slowly replacing FTP, CalDAV is dominating, CardDAV will
> dominate... is everything eventually moving towards DAV? Should I be
> using and supporting DAV at every opportunity?

Again, to re-iterate: CardDAV is not meant to replace LDAP - and indeed I 
strongly believe that it never will. The two will co-exist and co-operate 
and be the right tools for the particular problem spaces each is trying to 
solve.

-- 
Cyrus Daboo

_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 24 Jul 2008 22:45:38 -0400

Hi Richard,

--On July 24, 2008 4:44:20 PM +0200 Richard Watson <[email-masked]> 
wrote:

> I did read the Chicago presentation, thanks. Since the new standard will
> be accompanied by an XML representation, I think it would also be wise to
> create an LDAP representation of the new vCard and distribute it in the
> core.schema. I'm sure the LDAP working groups would appreciate this form
> of industry support. It would enable interoperability by providing the
> 1:1 mapping that is currently missing between vCard and inetOrgPerson. It
> would also allow the easy integration of the two formats in an address
> book application (drag-n-drop).

Items (6) on the vcarddav charter is for the WG to define an LDAP<->vcard 
mapping. Hopefully that is what you want.

> Good point. Do you think future address book clients will continue to
> build in LDAP support?

I think LDAP is here to stay as the corporate directory solution, so there 
will always be a need to support it somewhere or other. I think one big 
question to ask is what is the adoption of LDAP in mobile devices? I don't 
know that I have seen much support there except in high-end "smartphones".

>> Instead CardDAV provides an alternative for storing personal
>> contacts. What is more, CardDAV and LDAP can live together. In
>> particular, it is entirely possible for the CardDAV server to expose
>> vCards for all users in the directory system, so a "corporate"
>> address book could exist in addition to personal address books. That
>> would then provide a view of the single authoritative source for
>> corporate contact information, whilst still allowing individuals to
>> create their own personal data.
> Do you mean the CardDAV server would manage the corporate address book?
> If so, how is LDAP involved?

I don't see CardDAV as being used to edit/manage an LDAP directory. Rather 
I see it as a read-only one-way mapping from user directory entries into a 
vcard address book. i.e. CardDAV acts as a read-only gateway to LDAP. In 
fact CMU had done an extension to the old IMSP protocol to do exactly that 
and it worked reasonably well.

>> Again, to re-iterate: CardDAV is not meant to replace LDAP - and
>> indeed I strongly believe that it never will. The two will co-exist
>> and co-operate and be the right tools for the particular problem
>> spaces each is trying to solve.
> I think it will come down to whether or not clients (address book, mail,
> etc) continue to include LDAP searches. I think this will only happen
> there is a vCard object in the core schema.

Well I think clients have got used to the basic aspects of the inetOrg 
schema.

> Does Apple intend doing so? I gather that Snow Leopard is supporting
> both. Will Open Directory entries eventually contain only

Sorry I can't talk about Apple's plans beyond what has been publicly 
announced to date.

> I think it is good to separate contact information infrastructure from
> directory information infrastructure. The CardDAV proposal seems to be
> well through through. LDAP has a niche in large scale, high performance
> searching. For them to live together non-competitively, I think there
> will need to be maximum communication ability. Perhaps even a CardDAV
> backend to LDAP and a vCard schema (with a vCard to LDIF transformer).

Sure. I think it is feasible to have gateways in both directions if needed 
but I don't see that as being a requirement.

-- 
Cyrus Daboo

---

From: Richard Watson <[email-masked]>
Date: Thu, 24 Jul 2008 14:53:17 +0200

Hi WG Members,

- Instead of creating a new standard, why not address the access  
control issues of LDAP by producing a set of open-source ACL  
management tools, guides and documentation?

- It appears that CardDAV, with support of Apple, will separate the  
serving of contact information from the serving of other user-specific  
information (such as posix account details). I agree that they do not  
need to be housed in the same data entities; however, once separated,  
how will they ever be re-associated? Is there going to be a (multi- 
valued) DN attribute (and corresponding LDAPURI attribute) in the new  
vCard standard to support cross-referencing?

Admittedly the LDAP community focussed heavily on defining the server  
and client interactions through RFCs, but forgot that wide-spread  
interoperability requires the development, release and maintenance of  
schema which have the support of the industries actually requiring  
directory services. The inetOrgPerson schema should have evolved  
through collaboration of all interested parties and persons. Is it too  
late for that? Or Can a vCard schema extension with built-in ACL  
standards still leverage the deployed LDAP infrastructure?

Although I would love to see wise standard evolving, my main interest  
is ensuring the value and usefulness of the IT investments of my  
business. Given your current positions in the industry and within the  
standards workgroups, do you see built-in support for LDAP being  
maintained/developed, especially on mobile devices? Or is it wiser to

I would appreciate any commentary, advice or feedback, if you have time.

Be well,

Richard

________________________________

Richard Watson
Visionary
The Loop

Email: [email-masked]
Phone: +27 73 7800566 (GMT+2:00)
Skypename: the-loop
Loopname: richard
Web: www.the-loop.co.za

---

From: Richard Watson <[email-masked]>
Date: Thu, 24 Jul 2008 16:44:20 +0200

Hi Cyrus,

Thanks for your response. Great to see you're actively involved in  
discussion with interested parties :)

> Not necessarily. There was a presentation on this issue at the  
> original vcraddav BOF that explained some of the difficulties of  
> mapping the multiple properties/parameters model in vCard into LDAP.  
> It s certainly possible, but not straight forward.

I did read the Chicago presentation, thanks. Since the new standard  
will be accompanied by an XML representation, I think it would also be  
wise to create an LDAP representation of the new vCard and distribute  
it in the core.schema. I'm sure the LDAP working groups would  
appreciate this form of industry support. It would enable  
interoperability by providing the 1:1 mapping that is currently  
missing between vCard and inetOrgPerson. It would also allow the easy  
integration of the two formats in an address book application (drag-n- 
drop).

>> control
> CardDAV isn't so much a new standard as a more refined application  
> of an existing standard (WedDAV + ACL) to a specific application.  
> Yes there are some new protocol elements, but it is really not that  
> much on top of LDAP.
Also a good point. May as well reuse all of the ACL stuff that is  
inherently built into the WebDAV and file systems instead of  
reproducing it in an LDAP DIT.

> The bottom line is that CardDAV is not meant to "compete" with LDAP  
> but rather to complement it. The nature of information stored in a  
> personal address book is different from that typically stored in  
> LDAP. In particular many LDAP installations are used as the  
> "corporate" directory system. Having users' personal information  
> such as contact data for family, friends, business associates is  
> often not appropriate. In a lot of cases the corporate directory  
> system is read-only to end-users too. Whilst all that could be  
> changed through policy decisions and use of various extensions there  
> is a natural reluctance to tinker with such systems.
I agree. I've experienced the exact same thing in various corporate  
environments. Another factor is that most address book clients don't  
support the addition or modification of entries (even if the ACL's  
were in place).

> create their own personal data.
Do you mean the CardDAV server would manage the corporate address  
book? If so, how is LDAP involved?

> spaces each is trying to solve.
I think it will come down to whether or not clients (address book,  
mail, etc) continue to include LDAP searches. I think this will only  
happen there is a vCard object in the core schema. Does Apple intend  
doing so? I gather that Snow Leopard is supporting both. Will Open  
Directory entries eventually contain only

I think it is good to separate contact information infrastructure from  
directory information infrastructure. The CardDAV proposal seems to be  
well through through. LDAP has a niche in large scale, high  
performance searching. For them to live together non-competitively, I  
think there will need to be maximum communication ability. Perhaps  
even a CardDAV backend to LDAP and a vCard schema (with a vCard to  
LDIF transformer).

Thanks for your time and input and assistance in understanding the  
issues involved.

Best regards,

Richard