[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
LDAP conformance
Brandon McCombs wrote:
Howard Chu wrote:
"Other LDAP implementations that don't do schema checking" is an
oxymoron - those are not LDAP implementations. They implement some
bizarre vendor-specific non-standard undocumented protocol that sort
of looks like LDAP until you actually try to use and interoperate with
it. That may be many things, but LDAP it's not.
Well maybe OpenLDAP is the only one and thus the exception but I don't
know of any LDAP implementation that doesn't have it's own little twist
on the standard. The one implementation I alluded to provides the
*option* to disable schema checking; by default it is on unless an
administrator disables it during installation. After building a
Java-based LDAP client that can communicate with 3 different directory
servers I can attest to the fact that at least any 2 of them (if not all
3 in some respects) would behave differently in one way or another. It
would be nice if they all conformed to the standard but when implemented
by commercial entities they all want to put their own twist on the
product to differentiate themselves.
Since LDAP is an extensible protocol, there's nothing wrong with different
vendors adding new features to their products to differentiate themselves.
But those are extensions, and here we're talking about the base, core
specification. If they don't implement the core specification then they're
not implementing "LDAP".
Extensions can do many things, but they all have to be explicitly requested
by the client. They can change the server behavior but their use is supposed
to be optional; a server cannot unilaterally impose non-standard behaviors on
unwitting clients. And no matter what the extension does, ultimately the
contents of the DIT must still conform to the X.500 data model.
When you accept non-standard behaviors in the core implementation of a
server, you've implicitly agreed to be locked in to that version of the
product (not just that *vendor*...). One need only look at Microsoft's
embrace/extend/extinguish practices to see where that will lead you.
The purpose of a standard is to establish a known reference point, so that
any basic client can get consistent service from any unknown server. When
vendors cut corners and omit elements of the basic specification, you really
need to ask yourself what else did they fail to do correctly? What other
technical integrity did they sacrifice for the sake of expedience, and in
what least-convenient moment are you going to discover it firsthand?
On that score, when a vendor like Sun tosses up their hands and says "our
JSDS code base is unmaintainable, let's start over" that speaks volumes about
the other questions.
https://opends.dev.java.net/public/docs/OpenDS-FAQ.html#why_not_os_sjsds
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
Chief Architect, OpenLDAP http://www.openldap.org/project/