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/
