Sharing the addressbook of two computers means usually one of two things: Having trouble, or using LDAP. I opted for the second variant since my ISDN call monitor also uses LDAP to look up names for telephone numbers.

The OpenLDAP server ships with some standard schemas that can be used to store address data: person, organizationalPerson and inetOrgPerson. A person has a name, description, telephone number and a password. Far from enough for an address book since it doesn't even has an address field. organizationalPerson goes a bit further and has a telephone number, fax number, postal address and some more. Still no email field... So we're going to the next standard one: inetOrgPerson which has a mobile number field, carLicense, mail and a place for a jpegPhoto.

Now we could live happy forever if a) all programs would support the standard fields and b) we wouldn't have any other things to store in the address book. For example: Birthday and anniversary date, IM (instant messaging) account address, second/third email and a second address (to distinguish between home and work address).

I found JXplorer to be the best general LDAP editor, also suitable to create and maintain address book entries.

Schemas used by popular applications

I spent quite a time searching for the golden standard schema that has all the things I need and is supported by most of the programs (Evolution, KAddressbook and Thunderbird/Mozilla Seamonkey). The conclusion: There is none.

Mozilla has its own schema called mozillaAbPersonAlpha since it is in very early alpha stages. I don't really like the schema since it doesn't fully use the existing ones (inetOrgPerson) and prefixes most own values with "mozilla". Great, isn't it? I don't care if it's mozilla's invention to add that fiel, I want it to work. While Thunderbird supports exporting its address book to a .ldif file, the generated one cannot be imported into you ldap directory without modifications, since the ldif is broken and has some non-existing fields. I almost forgot to add that Thunderbird cannot add/modify LDAP entries which makes it an LDAP-Viewer only.

Evolution on the other side has also its own schema called evolutionPerson. At least the schema file that installed into /usr/share/evolution-data-server-1.8/evolutionperson.schema when installing gnome-extra/evolution-data-server also contains a class called evolutionPersonList to e.g. group persons into a mailing list. The irony is that even this schema does not support all the settings allowed by the evolution address book itself. Great? The good things is the field names are at least half reasonable, and it has birthday field support.

The golden schema

So, where is the golden standard schema? Asking on the LDAP mailing list I got the definitive answer: There is none.

There were, however, some ideas to think about:

• The mail field is multi-valued. So you can store several email adresses in this one without needed another field like secondEmail, thirdEmail or fourthEmail. The downside is that you cannot differentiate if it is the home or work email. Evolution supports multi-valued mail fields, Thunderbird not. KAddressbook does display them, but when saving it stores the first address only.
• Adding fields like secondSomethings is bad since it calls for adding a thirdSomething and a fourthSomething which isn't the end of the ladder. Better would be multi-valued fields or linking to some special address entries also stored in the directory. This one isn't supported by any of the programs, tough.
• IM messaging names are also too specific since they are bound to a certain service. While KAddressbook supports key-value (service name - user service address) pairs, it does not store them in LDAP. Evolution has the same problem, and Thunderbird has a single "screen name" that nobody knows what it means.
• If you need more than the schemas provide, add your own AUXILIARY one to extend them. This was considered to be a bad, but still the best solution on the ldap mailing list.
• Some people think all the schemas are "broken" by misusing standard schema elements. Consider them to be as broken as your custom schema also is.

Someone also suggested creating your own hybridPerson schema that combines all schemas (altough you can assign multiple classes to an entry, which I do currently):

# Objectclass: mHybridPerson
# Description: Seals the break in objectclass inheritence created
#   by officePerson and evolutionPerson descending from inetOrgPerson
objectclass ( 1.3.6.1.4.1.6921.1.12
  NAME 'mHybridPerson'
  DESC 'Combine several objectclasses to support multiple MUAs'
  SUP ( inetOrgPerson $ officePerson $ evolutionPerson )
  STRUCTURAL )
  

Conclusion

So, where leaves us this? You are on your own, period. Despite many applications support LDAP, they developers did not even try to standardize the schemas. If only all the programs would allow LDAP entry <-> address book text field associations, it would be a bit better. Setting up an LDAP addressbook is worth the problems, since you really don't have to sync them anymore.

Other pages

Quanah Gibson-Mount wrote an article called Creating a well defined LDAP directory query interface for email clients with a list of things to consider when setting up your own directory.