[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Q: How can I use a different core.schema with 2.3.x?



Mark Swanson wrote:
Have I missed anything? I hope so because if not I will have to move to
another LDAP server.

Given that what you are talking about is an RFC defined SYNTAX for all LDAP servers, how is moving to a different LDAP server going to help

There are other LDAP servers have the same behaviour as OpenLDAP 2.2.x.

There are other LDAP servers that corrupt their databases just like back-ldbm in OpenLDAP 2.2.x. Pointing at what software does wrong is not a compelling reason to make a change.


you? The basic problem here is data entry by the users of those devices, it sounds like, rather than a problem with the LDAP server. Of course, user education is one of the hardest things to achieve.

Almost. The problem is that other software allows basic text strings for attributes like telephoneNumber. I can't blame a user for using it as a string if the software lets them. Unless Outlook/cell phones, etc.. force users to use the LDAP syntax users aren't going to do it on their own. Since Outlook/cell phones/etc.. have not forced this behaviour in the past telephoneNumbers will never be in the RFC syntax.

Funny, none of my Motorola cell phones allow arbitrary strings in telephone number fields. Even worse, I can't even enter "+" for international numbers in some of the older phones. You can't generalize from your specific experiences and assume that what you want is the best for everyone.

In a nutshell, 2.2.x easily interoperates and can stay in sync with virtually any other system. All one has to do is slightly relax the core schemas to accomodate existing systems. With 2.3.x, full interoperability is impossible.


I humbly urge the OpenLDAP developers to reconsider this restriction and revert to the 2.2 behaviour.

Our aim is to implement code that conforms to accepted standards. The slapd code isn't broken here, so you're wasting your time asking us to break it for you. Instead, you should lobby your client providers to fix their broken software, or make a case to the IETF that the standard needs to be fixed/relaxed. Or, break your private copy of the code and live with it.

This may seem like an unreasonable hard line to you, but compromising and allowing broken software to perpetuate doesn't do anybody any real favors. One need only look at Microsoft Windows to understand where that leads.

--
 -- Howard Chu
 Chief Architect, Symas Corp.  http://www.symas.com
 Director, Highland Sun        http://highlandsun.com/hyc
 OpenLDAP Core Team            http://www.openldap.org/project/