I’ve recently seen a lot of traffic referencing an image depicting the history of a number of LDAP-related RFCs. That image is available in a number of locations, including http://commons.wikimedia.org/wiki/File:LDAP_RFC_Hist.jpg (I don’t generally like wikipedia, but it seems to be the most professional/reputable of the sites containing the image). Most of the comments associated with this image are along the lines of “look at how hard LDAP is to understand”. While it’s certainly true that you need to read a few RFCs if you want to become an expert in LDAP (especially if you want to write your own fully-compliant directory server), I do think that this is a bit of an unfair conclusion to draw from this image.
First, the sheer number of RFCs pertaining to a topic is not necessarily a direct indicator of how complex that topic is. For example, most people don’t consider telnet to be a particularly complex protocol, but according to http://www.faqs.org/rfcs/np.html there are 105 different RFCs pertaining to telnet versus 89 for LDAP, and both of them are dwarfed by the list of 207 RFCs pertaining to DNS. I’m sure if you created a similar diagram showing the relationships between those telnet or DNS RFCs you’d probably come up with something that puts the LDAP version to shame, however I don’t hear anyone complaining about how hard they are.
Second, I think that the diagram illustrates how LDAP is evolving over time. The arrows in the diagram show changes over time, so it’s not like all of those RFCs cover completely different topics. For example, the LDAPv2 protocol was originally described in RFC 1487, and then revised in RFC 1777, then updated again in RFC 2251 for LDAPv3, and once more in RFC 4511. If you want to understand LDAP at the protocol level, you only need to read RFC 4511 since it is the most comprehensive and up-to-date of the protocol specifications. In fact, reading just RFCs 4510-4519 would provide a pretty comprehensive understanding of most LDAP-related concepts.
Third, the relatively large number of LDAP-related RFCs is a good demonstration of the openness that LDAP exhibits. A handful of RFCs provide me with all the information I need to write a standards-compliant LDAP client, which should be capable of talking to any standards-compliant LDAP directory server, or I could even write my own LDAP server. Contrast that with something like the relational database world. I can’t write my own client for talking with an Oracle database, and even if I could, it wouldn’t be able to communicate with DB2 or MySQL or any other type of server. It’s true that there is an ANSI SQL standard, but even then it’s kind of a crap shoot about which parts of that standard a given database follows.
Ultimately, I think that the number of LDAP-related RFCs and the relationships between them has very little to do with how easy it is to understand, and beyond that how easy it is to use or write an LDAP client or server. It’s definitely true that some directory servers or client APIs are easier to use or more full-featured than others. I spend a lot of my time working to make sure that the UnboundID products are as easy to use as possible, and ensuring that we do so without sacrificing performance, scalability, or functionality, and I know that other vendors have people trying to do the same for their products. There are definitely some poorly-written applications out there that use LDAP, and it’s unfortunate that they can give people a bad impression of LDAP itself, but hopefully that will also improve over time.
One thought on “How Hard is LDAP?”
I would add to your third point that a protocol *have* to be normalized to be open. We have a good counter example with the proliferation of NoSQL database: most of them have some kind of proprietary internal protocol for communication/querying, sometime just an API. Of course, that means less RFCs to read, but I’m pretty sure it does not imply that it is easier for a third party to implement it if one cares. That is not an attack against NoSQL database – after all, LDAP directories were the first to embrace some of their idioms – more a proof of not yet mature domain. The problem is that open (non trivial) protocol are hard to specify to be non (too much) ambiguous, and so for the spec to be of some interest. For example, if we look at AMQP which is comparable to LDAP in "broadness" (it is a protocol for event messaging): the spec is in development for years, and is reaching 200 pages (ok, perhaps it is an example of what not to do, but at least it shows that specifying a protocol is hard). So… Well I really thing that people clamin "LDAP is hard" with the provided picture are in the middle of some confusion between LDAP (the protocol), LDAP tools, LDAP directories, and mixing their frustration in the little slogan. So thank you very much for that clarifying post !
Comments are closed.