Global
Directory:
Paradise Postponed?
by Steve Kille, MessagingDirect.
(Originally published in Messaging Magazine, July/August
1999)
In the early 1980s, work started to build a global directory, to support messaging and other telecommunications services. This work led to X.500 and then to LDAP, and resulted in various efforts to build a global directory, most notably the PARADISE project that builds a significant distributed worldwide directory. Despite almost 20 years of effort, the global directory has not happened. This paper looks at the history of global directory, and what did and did not happen. The importance of the extranet is considered, and why this will require and lead to a global directory.
Early Developments and PARADISEThe push to build a global directory started in the early 1980s, when Jim White, Ron Uhlig, Doug Steedman and a host of others (including me) developed a framework for directories under the aegis of IFIP (International Federation For Information Processing) Working Group 6.5. This work was published in 1984 in a paper "A User-Friendly Naming Convention for Use in Communication Networks," and in parallel led to the first drafts of a directory specification that was to become the X.500 standard in 1988.
I led a research group at University-College London to develop the first widely deployed X.500 system called QUIPU. One of the key reasons that QUIPU was deployed so rapidly was that it implemented a number of extensions to the X.500 standard to address issues which included: operation over the Internet, Schema Extensions, Access Control, and Replication. These extensions were standardized by an early IETF (Internet Engineering Task Force) Working Group, and published as RFCs 1274-79. This working group went on to develop a range of additional functionality to deploy directories, including LDAP, which was developed to enable simple access to an X.500 directory by users on PCs and Macintoshes.
In the early 1990s, there were several attempts to deploy directory services based on X.500 and RFCs 1274-79. The most notable of these were the Nysernet (subsequently PSI) White Pages Pilot, funded by PSI and led by Marshall Rose and PARADISE, funded by the EEC and led by David Goodman and me. These pilots were primarily deployment of the QUIPU system. These directory activities were integrated under PARADISE and led quite rapidly to a worldwide system with hundreds of servers and millions of entries. Many anticipated that this would evolve naturally and rapidly into a global directory. While PARADISE has continued to grow, and provides a useful directory service for some parts of the research community, it has not led to a global directory. The rest of this paper looks at why this did not happen and considers the future of global directory.
Why Global Directory Didn’t Happen First Time Around
A number of views have been put forward as to why PARADISE did not "take off." The first of these is a technical one, which notes the relative complexity of deploying the QUIPU system (which was a research prototype). The clear migration path for PARADISE was to X.500 (1993), which provided significant extensions to the original X.500 (1988) and, in particular, replication. Various attempts were made to do this, which were hampered significantly by non-trivial differences between the manner in which PARADISE and X.500 (93) handled replication and management of the distributed configuration. A second argument is that there is insufficient benefit from global directory service to justify the operational resources needed to make it happen.
Although both of these points have some validity, neither of them is the primary reason for the failure. The core problem is that PARADISE has a very top-down approach, which requires non-trivial centralized control and administration. As various Post Telecommunications and Telegraph (PTT)/Telco attempts to look at directory services, they have discovered there is no clear direct business case for a centrally driven directory service. The primary benefit of directory is that it enables other things, but operating a national directory in order to provide the framework in order to interconnect various enterprise directories will not make money directly. The PARADISE approach to global directory inherently requires significant centralized effort and service operation. Related to this, the PARADISE approach requires a single authority for each country, and this is not realistic in today’s deregulated environment.
Enterprise Directory and Vendor Pressures
Although global directory has not happened, directory deployment has grown significantly. The LDAP protocol has been central to this, as it provides an open directory access protocol, which can be used to access a range of directories. This has enabled vendors such as Novell and Microsoft to provide open LDAP access to proprietary directory products, and allow a wide range of products to be directory enabled using LDAP. The primary driver for directories has been within the enterprise (intranet), and an increasing number of organizations are adopting LDAP accessible enterprise directories.
While the widespread adoption of LDAP has been significantly enabled by the fact that it does not mandate support of X.500 (or any other system for provision of a directory service) as this has enabled a range of directory products to offer LDAP access. However, this has also caused significant problems as most organizations are arriving at the situation where they have multiple vendor directory services, which although they support a common access protocol, cannot be linked together to form a single enterprise directory. This is leading to a short-term requirement for a range of directory synchronization products, and clearly demonstrating the requirement for an open approach to provision of directory service within the enterprise, such as that provided by X.500.
Another consequence of enterprises adopting LDAP directories that often do not support X.500 is that the basic hooks for participation in a global X.500 directory (or any other type of global directory) are not present. Thus although LDAP has been key to enabling directories, it has in many ways led to a movement away from provision of global directory. This fragmenting effect of LDAP is unfortunate.
Extranet Requirements: Pushing Beyond Enterprise Directory
Intranet (enterprise) systems are now managing to move forward with directories, using LDAP as the common access protocol. In the Internet (global) environment, the DNS (domain name system) provides a basic framework for e-mail and Web-based communication. This framework is working well in the Internet, and there is no significant pressure to replace or extend it.
An extranet provides the framework for communication between an enterprise and its customers and suppliers. There are two extranet characteristics that are important when considering directories.
Extranet is much broader than an intranet and, in general, organizations and individuals will participate in multiple extranets. Because of this, it will not be practical to use proprietary frameworks in the extranet. Everything will have to be standards-based (either open standards or de facto standards).
There will be a significantly higher level of integration and requirements for security on the extranet than on the Internet. This will lead to the requirements to share information between extranet participants, in support of extranet Service and security. The Internet DNS framework is inadequate to support this extra level of service, and so directory will become a key part of the extranet.
Enterprises will often wish to participate in multiple extranets. It would be very inefficient for an enterprise to construct a separate directory for each extranet in which it participates. A consequence of this is that enterprises will start to link their directories together in order to build integrated extranets supporting secure communication between the extranet participants.
The interesting consequence of extranet requirements is that they will cause directories to grow beyond the enterprise. As multiple extranets grow and increase in scope, so will the overall level of directory interconnection.
Global Directory Will Happen in the End
The extranet drive will cause enterprises to start to interconnect directories. As the number of extranets increase, so will the level of directory interconnect and number of directories participating in directory interconnect. In the end, this will lead to a global directory, developed from the bottom up, rather than top down. There will be a range of activities needed to support this. This will include:
Need for a common naming framework. It is quite likely that the DNS naming structure will suffice to start with, although there is likely to be pressure for a naming model which supports a broader character set than domain names (e.g., enable names which have spaces, characters such as "&" and accented characters).
If there is a new naming framework, this will lead to requirements for registration of names, and the need for a structure to manage this.
Procedures for directory interconnection and sharing of "knowledge information" to enable this bottom-up directory to be able to work. This is likely to include new protocols, which may come from the International Telecommunications Union (ITU) as extensions to X.500 or from the IETF as procedures for use with LDAP.
There is still clearly a lot to do, but I strongly believe that we will see a Global Directory deployed. MM