MailNews Talk:Mozilla LDAP Address Book Schema

This page is for filling comments about the mozilla alpha LDAP schema. Please include your signature (name/date/time) when commenting.

--Standard8 08:06, 28 Dec 2005 (PST)

why all the mozilla prefixes?

As the "big Picture" intent must surely be to use the LDAP server for a common repositroy for contact information, why would you label the schema names prefixed with mozilla?

Why not just homePostalCode ?

No other application is going to use mozillaHomePostalCode.

Am I missing something?

Also, I see that an export to LDIF in version 1.5 (20051201) does export as homeStreet (vs mozillaHomeStreet); is this going to change to mozillaHomeStreet?

Jwilleke 05:41, 14 Jan 2006 (PST)

Mozilla LDAP has gone the wrong way

Hi,

the Mozilla LDAP support has completely gone the wrong way:

• The implementation is buggy and odd. Editing, Updating, Caching, Better Authentication (including Kerberos) do not work, Code seems to be stone-age old.

• The idea to define a general mozilla LDAP Schema is weird. This proposal won't work anywhere except where dedicated mozilla databases are created from scratch. Who would be willing to modify his/her LDAP Server, e.g. the company ADS? I would not even be able to modify our company's ADS, nor would I be able to argument to have every entry twice, once in the Microsoft Schema, and once for the Mozilla schema. Same problem with other LDAP schemes. The proposal to have a fixed Mozilla schema is silly.

• No matter how you would call the attributes, they are insufficient:
  • E.g. it is insufficient to have the number of addresses limited to just two.
  • It is insufficient to only have one mobile and one fax number
  • It is insufficient to not have additional phone number entries, e.g. VoIP
  • It is insufficient to have only one URL
  • This scheme is actually limited to the US addressing scheme, but does not support address schemes in other countries. E.g. in Germany many companies and institutions have post boxes for letters, and thus need a second address with a different post code. On the other hand, the State entry does not make sense in most european countries. Please drop this US-limited perception of what an address is.
  • Incompatible with KDE and GNOME address book schemes
  • Incompatible with commercial address providers
  • About ten years ago the first Mozilla/Mosaic versions were able to display an image stored in LDAP. Where is this feature gone?
  • Absolutely no way to display company specific attributes.

As a result, this won't work. It is a pretty bad idea to have/invent a special LDAP schema for Mozilla, and to limit Mozilla to such an old-fashioned scheme.

My proposal is:

Completely remove all this LDAP crap from Mozilla/Thunderbird and replace it with a common plugin interface:

• For each 'external' address database allow to configure an external script or dynamic library
• Define a function for each action, e.g. search_for_name, search_for_emailadress.
• When displaying the address details, just have the script return something like a HTTP script or an e-mail with attached pictures. This way you can display just anything, with any attributes, including pictures.
• For editing allow something like a HTML form and call the plugin like a CGI script. This allows editing of any attributes.

This way you are not limited to any stiff LDAP scheme, but can query just anything, like

• any kind of LDAP scheme, even with unlimited number of sub-addresses
• any other kind of database like SQL
• any other source of information, like e-mail-addresses in your mailbox or PGP key ring. It's just a matter of plugin scripting.

Please, the LDAP support of Thunderbird is currently really bad. And defining such a scheme will make it worse.

regards Hadmut

--Hadmut 03:34, 28 March 2006 (PST)

Need for a standard address book schema

One of the goals of the Mozilla Foundation should be to encourage the move from propietary solutions to its own products, and one of the tools that salesmen use the most is the address book.

We would never switch those users if they will no longer be able to access their centralized address book in the same way they did with Outlook. And nowadays that there exist several devices or PIM applications that can connect to LDAP servers, the Mozilla products should have to prove themselves as applications that can integrate easily.

This is not a problem of the LDAP server implementations abroad, but a lack of standarization on this issue from the clients. I just wonder why is no effort done in this direction from the Mozilla Foundation to reach an agreement with other PIM implementations.

Juan Fernández-Rebollos - 15/06/2006

Extensibility

The old mozilla person schema and the "obsolete" derivitive had a SUP of inetorgperson, but this schema seems to want to create a private, non-extensible area. That seems to be counter-intuitive to its purpose, which I would think should be to better integrate mozilla's LDAP features into various LDAP services.

I don't understand why, if you're going to make the schema dependent on other schema, do you not explicitly declare that dependency?