LDAP's Past Shouldn't Be Prologue

On Tuesday, I spoke on an LDAP panel at Networld-Interop in Las Vegas. The session was called "LDAP Case Studies," with presentations by executives from Ford Motor Co. and FedEx, both of whom extolled LDAP's use as a directory service for very-large-scale deployments. I then gave my thoughts on the future of LDAP and how it needs to change in order to become accessible to a broader range of uses and users (you can download the slides from here).

It appears that a lot of people don't understand my arguments for this. Either I'm fundamentally wrong and folks just aren't wasting their breath on arguing with an idiot, or my arguments aren't being made in an effective manner. I don't think I'm an idiot, so I'm going to assume it's the latter. So let me try this one more time, taking a somewhat different tack.

Positioning-vs-Reality

Most of the people responsible for marketing LDAP products take the position that it is a protocol for retrieving and managing data stored in a directory service, allowing users to view information about the network, using any given client, without the user or the client having to know anything about the directory's internal structure.

This sounds great on the surface, and LDAP is indeed being used in this manner to a certain degree, but we're a long way from achieving the kind of interoperability inferred by this positioning.

As it stands today, LDAP is only useful for retrieving information about the people-objects that are stored in a directory, allowing me to find somebody's e-mail address or their boss' phone number easily. But also as it stands today, LDAP can't be used to locate the printers on your network, a function provided by even the most rudimentary of directory service products. Even LAN Manager's NetBIOS name service -- the unchallenged bottom-dweller of network directories -- gives me more functionality than LDAP, at least in this regard.

In the end, all this boils down to the inescapable fact that the positioning of LDAP as a cure-all for your directory service access woes is extraordinarily different from the reality. The two are worlds apart.

There are a couple of reasons why LDAP is only useful for information about people. The biggest reason for this huge disconnect is LDAP's history as an IP-based front-end to X.500 white pages applications. Another reason has to do with schema incompatibilities between the various vendors, each of which are using different attribute collections to display information about the particular object in question. In order for LDAP to reach its goals, both of these issues have to be resolved. In addition to these major roadblocks, we also need to fix some of the other problems that arise from this dependency, such as the use of X.500's Internet-hostile resource naming syntax.

In short, we need to eliminate all traces of X.500 from the LDAP specification, allowing it to move towards becoming a solution for directory services in general, rather than a solution for X.500 in particular.

History Lesson: LDAP is X.500

Take note: LDAP was not written as a generic directory services protocol. Rather, LDAP was developed so that users at the University of Michigan could access the school's X.500-based white pages applications using TCP/IP as a transport rather than OSI.

And what are these white pages applications used for? Massive corporate phone books, mostly. Think of the really big organizations in the world -- the IBMs, General Motors, and University of Michigans -- and it's easy to see why these companies need a specific set of protocols and services for distributed maintenance of personnel data. X.500-based white pages applications provide just this functionality, and also provide a general purpose authentication service, an application registry, a global e-mail directory, and more. To the world's largest enterprises, X.500 and the white pages applications that it enables provide a very necessary service.

But what this also means is that X.500 is almost totally focused on providing people-centric information. Very few of the global X.500 implementations also store information about the printers that are available on the network (neither Ford nor FedEx does this today, for example).

In order for LDAP to succeed as a general-purpose directory service, this has to change. Although almost every company can benefit from an automated employee-information service, for most of us the work involved in trying to build and deploy a distributed X.500 white pages application is prohibitively expensive and impractical, especially when compared to the cost and effort of just storing the data in a dBase file somewhere.

The reality is that these white pages applications are only useful to the top 1% of the companies in the world. The rest of us wouldn't mind having this kind of functionality if we could get it for free, but in the end we're more concerned with being able to find and use the printers on our LAN. In order for LDAP to become useful and relevant to the other 99% of us, it must become useful in areas outside of X.500's historical purview of white pages data, providing a more generic network-information publishing service.

The Schema Problem

In truth, there's nothing about the LDAP protocol itself that prevents it from serving up information about network printers or anything else. Indeed, the protocol is very useful for acting as a generic data-exchange service, with support for active verbs that let users search, add, update and delete whatever information happens to be stored in the back-end directory. LDAP even provides the necessary security mechanisms that allow the back-end system to restrict these activities to the users who are authorized to do so.

The reason you can't use LDAP to browse and access the printers, servers and other resources on your network is because there aren't any standardized schema representations for those resources. Again, this is due to LDAP's legacy as a front-end for X.500 white pages applications. While there are many different schema definitions for people-centric data, there aren't any standard definitions for anything else.

In order for LDAP to be useful to folks like us, this has to change. If we're going to try to use LDAP as a generic protocol for viewing and using network resources, we need to be able to see those resources in a consistent manner.

It should be noted that these schema definitions exist already. Novell has long provided directory information for a variety of network resources. Over the years, they've managed to develop an extensive collection of objects and attributes for use with NDS. Netscape also provides a slew of schema definitions for a variety of objects, most notably for their various servers. Not to be outdone, Microsoft has also developed a set of schema definitions for NT 5's Active Directory.

The point is that LDAP doesn't use any of these schema definitions as a "standard" way of representing directory objects. If you wanted to use LDAP to view an LPD print queue on a NetWare server, you'd have to use a different set of schema definitions than the ones you'd use to access an LPD queue on an NT 5 server. By each vendor implementing their own schema definitions -- and by LDAP lacking a standard set of definitions that can bridge the gap between them -- what works with one vendor's directory won't work with the others', regardless of any other factors.

Even the stuff that is standardized (like people-centric schema) isn't incorporated consistently across product lines. If you look closely at the LDAP queries used in Netscape's Communicator and Microsoft's Outlook Express, you'll see that there are substantial differences in how each of them represents the information being requested. One example: Communicator associates the "facsimileTelephoneNumber" attribute with an office fax number, while Outlook Express uses this for a user's home fax and the "officeFax" attribute for work.

Obviously, these incompatibilities are a huge fly in the ointment. In order for LDAP to satisfy the marketing hype, this consistency problem must be resolved, with the IETF providing attribute and schema standardization services, the same way they do for BOOTP/DHCP extensions and SNMP MIBs.

Unfortunately, as long as LDAP is tied to X.500, this can't really be done through the IETF. Since LDAP is a front-end for X.500, the attribute and schema definitions will have to take the needs and workflow patterns of the X.500 community into account first and foremost. As long as LDAP is tied to X.500, any effort at schema standardization must be done through X.500's standards channels as opposed to the mechanisms provided by the IETF.

It should be noted here that Microsoft and Cisco have submitted their schema definitions to the Directory Enabled Networking Ad Hoc Working Group. While this should act as a decent repository for those companies who want to use Microsoft's and Cisco's schema, it is by no means an IETF-sanctioned effort, and this work may never appear in any IETF (or OSI) standard implementations. You should be aware of this before you commit to using these schema on a network-wide basis.

The Need for Internet Naming

Another major problem with LDAP's dependency upon X.500's white pages orientation is the use of X.500 syntax rather than Internet-friendly resource names.

For example, the LDAP name for my user account is cn=ehall, ou=san-mateo, o=ehsco, dc=ehsco, dc=com. This is not only impossible for anybody to remember, but it also requires that every user be an expert in X.500 syntax in order to effectively use any given resource. Compare that to the RFC 822 e-mail address of ehall@ehsco.com, a format already in widespread use among the hoi poloi.

Even long-time advocates of X.500's syntax are starting to recognize the shortcomings of this structure. Novell has used an X.500-like syntax with NDS since day one, and they continue to maintain that it's not too hard for users to work with. Perhaps they would care to explain the motivation for NetWare 5's new "contextless login" feature, a service that allows regular folk to login with a simple username rather than having to provide their fully-qualified, multi-level NDS name. By saying "we're making it simpler," they're admitting that it was too hard in the first place.

The X.500 syntax is not only cumbersome and unwieldy, but it's also completely foreign to the Internet-aware user base. RFC 822 resource naming is infinitely better than the multi-tiered, syntactically-precise structure of X.500, if only because people are already familiar with it. If we ever do get around to having printers stored in the directory, are you going to want to spend the money on training your users that cn=mktg-queue, ou=san-mateo, o=ehsco, dc=pserver, dc=ehsco, dc=com is the same as mktg-queue@pserver.ehsco.com?

There's no reason that LDAP can't use RFC 822 naming (except for that little problem about LDAP being joined to X.500 at the hip). Let's just acknowledge that X.500 naming is too difficult for the average user, and that the only way we can really fix this is to give up on it entirely.

Let me be clear about this. I'm not saying that Novell (or anybody else) should stop using X.500 resource naming in their own products. Companies should do whatever they deem best for their own competitive position(s). But what I am saying is that LDAP should use Internet-friendly RFC 822 naming rather than X.500's Internet-hostile structure.

Breaking Away from X.500

It should be obvious to anybody who's read this far that LDAP has a long way to go before it can become the ubiquitous directory-access solution it's being positioned as. In order for it to become the lingua franca of network services it has to abandon its focus on people-centric data, get some standardized schemas, and make the resource naming more Internet-friendly.

These are all very big deals, any one of which could easily be claimed as "just too hard." Fine, then let's just come right out and say that LDAP is going to stay an X.500 query protocol, and that it's not going to be a generic network-services tool after all. Who here is brave enough to do that?

As we've already seen, trying to preserve the people-centric nature of the white pages legacy causes more problems than it solves. Furthermore, many of X.500's most-vocal proponents maintain that X.500 should stay true to its design and should only serve up white pages data. Hey, if the X.500 people want to stay focused on solving that problem, then by all means they should do so. But if the LDAP people want to go beyond that role -- which they must if LDAP is to become everything it's cracked up to be -- then LDAP has to be separated from X.500.

That may sound pretty radical, but it's not really. Indeed, the Internet community has a long history of developing new protocols that go beyond the functional limitations of their predecessors, and there's no reason that LDAP couldn't do the same, diverging from X.500 into a new, more flexible Internet-specific access protocol.

Without this type of effort, LDAP will indeed fail, and other protocols will rise to fill the void. In case nobody's noticed, XML is being touted as a way for systems to exchange data over the Internet. With a little bit of tweaking, XML could easily provide many of the same services that LDAP was supposed to deliver. Although it's my opinion that HTTP is a lousy transport for directory services, at least the resource naming and syntax are Internet-friendly.

As for Web-application developers, many are already looking at using XML in this manner, allowing the resources on different kinds of servers to be browsed and modified by XML clients. Isn't this a service that LDAP was supposed to provide?

So which is it? Is LDAP tied to X.500 or not? Neither choice is pretty, but the only one that's viable over the long haul is to totally pull the two apart.

Until next time,

Eric A. Hall
President, EHS Company

Written by Eric A. Hall.
Copyright © 1998, EHS Company. net.Opinion is a trademark of EHS Company. All rights reserved.