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.