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