Subject: [VCARDDAV] LDAP Schema

From: Peter Mogensen <[email-masked]>
Date: Wed, 10 Jun 2009 15:23:33 +0200

Sly Gryphon wrote:
> The common usage scenarios I can think of are:
> (1) mail agent or other system publishing information from an LDAP
> directory into a vCard format,
> (2) having a single UI present information from both a local address
> book (presumably based on the fields from vCard) as well as from a
> corporate directory - having some consistency in the fields would make
> this presentation easier,
> (3) using an LDAP directory for storing contact information.
> 
> Scenario (1) and (2) would use inetOrgPerson, or derivatives, possibly
> extended with directoryCard information. Scenario (3) would just use
> directoryCard.
> 
> I don't think a complete mapping is possible,

I agreee.

However, I would really suggest a renewed consideration of how 
beneficial backward compatibility with inetOrgPerson is.

In my experience there's so many obstacles for the mapping that 
write-support (storing vCards in an LDAP directory) will not be 
supported by clients anyway. We might as well define a dedicated 
no-legacy vCard4 LDAP schema (and maybe a one-way mapping of essential 
attributes for read-only inetOrgPerson LDAP access).

Example obstacles:

* "sn" is mandatory in inetOrgPerson. It is explicitly no so in vCard4 
and common usage of contact info today often has no family name.

* PHOTO can be any image format, however inetOrgPerson only has 
photo/jpegPhoto which require format conversion.

* Hard to support PREF / language-tag without LDAP attribute options.

* Several vCard properties can be both inline values and URIs. (like 
PHOTO). This cannot be mapped to LDAP attributes in an inetOrgPerson 
compatible way.

* "mobile", "pager", "homePhone", "telephoneNumber" etc. can not support 
other URI schemes than "tel:".

* There's no attribute to express properties like WORK.EMAIL and 
TEL;TYPE=cell,video

* .. and btw...No support for KIND. LDAP groupOfNames cannot be without 
members.

At least for our application we have come to the conclusion, that 
inetOrgPerson is best supported read-only (which is what clients do 
anyway) via a rewriting proxy.

regards,
Peter Mogensen