NOTE: This article is an archived copy for portfolio purposes only, and may refer to obsolete products or technologies. Old articles are not maintained for continued relevance and accuracy.
December 27, 1997

LDAP Will Fail

First there was e-mail. Then web browsers. According to the folks who ought to know, a unified directory service is going to be networking's next Killer App. I am somewhat inclined to agree, although I don't think it's going to succeed for at least five years, unless the industry really gets its collective act together pronto.

Although lots of progress has been made (most notably, the formal publishing of the LDAP v3 protocol spec), this is nowhere near the level of directory service that will be required in order for the technology to become pervasive. As we all know, the only technologies that truly succeed are those that become commodities. Unfortunately, we're miles away from commodity-class directory access.

For example, LDAP is currently useful as a lightweight e-mail lookup service. Using Netscape Communicator or Microsoft Outlook, you can easily query an LDAP server to locate the e-mail address of another user. But this is nothing compared to where directories must be in the future in order for them to become truly pervasive, commodity-class tools along the lines of SMTP and HTTP.

There are some interesting uses of LDAP in the works now. CCOM Information Systems is providing LDAP interfaces into PBX and CTI systems, allowing caller ID integration by way of LDAP lookups. FedEx also has an LDAP interface to their package delivery service, allowing you to query their server for package tracking information. Even hardware vendors are getting into the act, looking to provide LDAP interfaces for everything from access switches to firewalls.

LDAP is Too Weak and Too Inflexible

These are interesting alright, but just a few examples. In order for LDAP (and directory services in general) to succeed however, we need a million such examples, rather than a handful. The most powerful thing about LDAP today is that it offers just this possibility. Unlike the proprietary nature of Novell's NDS, Sun's NIS+ and Banyan's Vines, LDAP provides a vendor-independent directory access mechanism. Developers don't have to write to all of the proprietary services, but instead can write to a single open service.

Just as mail-enabled applications began to blossom once the SMTP standard was leveraged, the number and variety of directory-enabled applications will also explode as vendors start leveraging LDAP as a universal directory service API and transport.

What's required to make this happen? Well, several things, although primarily, LDAP just needs to grow up and take on some of the broader functions that its proprietary cousins have offered for a long time. Currently, LDAP does not offer the depth or breadth of the services available with NDS or Vines. There are no decent user authentication services for example, nor access control mechanisms, nor management tools, etc. And until these advanced services are available, LDAP will not live up to its promise.

What's Needed?

Over the next few weeks we'll be exploring some of these issues in more detail, but for now, here's a summary of what will be needed in order for LDAP to succeed as a commodity technology:

There are other issues with LDAP as well, such as replication and internationalization, although these topics are also being dealt with. However, I fear that we're putting technology before usability, and are ignoring the essential components that make a directory service of value to the mainstream communities.

We do so at our own peril. If we truly want directory services to be the next killer app, and if we want LDAP to be the enabling technology behind the next wave of interoperability and convenience, we must address the core issues that prevent it from doing so.

-- 30 --
Copyright © 2010-2017 Eric A. Hall.