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