Further Reading

Understanding and Deploying LDAP Directory Services > 2. A Brief History of Directories > General-Purpose, Standards-Based Directories

<  BACK CONTINUE  >
153021169001182127177100019128036004029190136140232051053055078209005198131016003035069

General-Purpose, Standards-Based Directories

In addition to application-specific, special-purpose, and NOS directories there is another category of directories, which we refer to as general-purpose direc-tories. These directories are not limited to a specific purpose, a particular application, or a single operating system. Instead, they are designed to meet the needs of a very wide range of directory-enabled applications. Typically, these directories are designed around open , standard protocols; thus, implementations from multiple vendors can interoperate . These directories are the focus of this book.

The Dawn of Standards Directories: X.500

In the mid-1980s, two separate standards bodies independently started work on directory services that could work across system, corporate, and international boundaries. The first body was the International Telegraph and Telephone Consultative Committee (CCITT) , which later changed its name to the International Telecommunications Union (ITU). CCITT member organizations ( mainly telephone companies) wanted to create a white pages directory that could be used to look up telephone numbers and electronic mail addresses.

The other standards body was the International Organization for Standardization (ISO) , which wanted a directory to serve as a name service for Open Systems Interconnect (OSI) networks and applications. (A name service provides information about network objects; DNS is a familiar example.)

Eventually, the two independent international directory specification efforts merged into one effort, and X.500 was born. The first X.500 standard was approved in late 1988 and published in early 1990 by CCITT; it was subsequently updated in 1993 and 1997, and work continues today. The specification itself references other ISO standards and consists of a series of recommendations, including all of the following:

  • X.501: The Models ”   Describes the concepts and models that underlie an X.500 directory service

  • X.509: Authentication Framework ”   Describes in detail how the authentication of directory clients and servers is handled in X.500

  • X.511: Abstract Service Definition ”   Describes in detail the functional services provided by X.500 directories (for example, search operations, modify operations, and so on)

  • X.518: Procedures for Distributed Operation ”   Describes how directory operations that span multiple servers are handled, among other details

  • X.519: Protocol Specifications ”   Describes all the X.500 protocols, includingDirectory Access Protocol (DAP), Directory System Protocol (DSP), Directory Operational Binding Protocol (DOP), and Directory Information Shadowing Protocol (DISP)

  • X.520: Selected Attribute Types ”   Defines attribute types used by X.500 itself, and some that are generally useful as well (such as the telephoneNumber attribute)

  • X.521: Selected Object Classes ”   Defines object classes used by X.500 itself, and some that are generally useful as well (such as the person object class)

  • X.525: Replication ”   Describes how directory content is replicated among X.500 servers

As you can see, X.500 developers must absorb quite a few documents before they can begin to develop X.500 directory services software! The X.500 documents are published both online and in paper form by the ITU, which currently charges money to access them.

X.500 Innovations

At the time it was originally defined, X.500 had many novel qualities. First, it was one of the first truly general-purpose directory systems, and it was designed from the beginning to be extensible in order to serve the needs of a great variety of applications. Second, X.500 provided a very rich search operation that can support many different kinds of queries. Third, like Grapevine (but on a much broader scale), X.500 was designed to be a highly distributed system in which the servers, data, and administrators could span the globe. Finally, X.500 was an open standard that was not controlled by any one vendor or tied to any specific operating system, networking technology, or application. The dream of the X.500 designers was that there would eventually be one fully interconnected global directory service ”THE Directory.

The major components of an X.500 directory service are shown in Figure 2.4.

Figure 2.4 Components of an X.500 directory service.

X.500 directories rely on a large suite of protocols, including DAP, DSP, DOP, and DISP. Some of X.500's strengths are its information model (which is very flexible and complete), its versatility, and its openness. As we will see, the LDAP designers adopted many of the best ideas from X.500 while removing unneeded complexity.

X.500 Flaws

In practice, X.500 directories suffered from some significant flaws, especially in their first decade of existence. The early implementations were buggy and did not perform or scale very well. Those who tried to deploy distributed X.500 directories discovered some significant barriers to adoption, many of which were not specific to X.500 (such as difficulty obtaining and maintaining good data in a directory service). Also, because of the complexity of the standards themselves and the associated difficulty of implementation, it has taken a very long time for interoperability between different X.500 implementations to become possible.

In addition, X.500 was based on the OSI network protocols. The dream of the OSI designers was that OSI would eventually replace TCP/IP as the networking protocol suite of the future. Unfortunately for them, this never happened . The simplicity, speed, and low cost of TCP/IP proved to be an unbeatable combination.

Finally, the origins of X.500 itself have to some extent prevented it from succeeding. The Internet grew rapidly in a bottom-up fashion as independent organizations deployed hosts and services at their own pace and without a lot of reliance on others. In contrast, X.500 was designed with the large public service providers in mind, which implies a top-down deployment. This has proved to be impossible to achieve ”and it is certainly at odds with the prevailing Internet culture.

Early X.500 Implementations and Pilots

One of the best-known early X.500 implementations, called Quipu, was developed at University College London. Its name refers to the complicated system of knot-tying the Incan culture used for communication. Part of the reason for Quipu's early popularity was that it was freely available in source code form. Quipu is built on top of an OSI networking package called the ISO Development Environment (ISODE), which allows OSI protocols to run on top of TCP/IP and, thus, the Internet.

The availability of Quipu encouraged many organizations to experiment with X.500 directories. The Quipu implementation served as the basis for a number of X.500 white pages pilot projects centered mainly in Europe and the United States. Unfortunately, these worldwide X.500 directory pilots didn't grow as fast as their sponsors hoped, and interest has waned.

X.500 found its greatest success in large organizations that could afford the time and effort needed to deploy a large, complex directory service. Some early deployers of X.500 included the United Kingdom academic community, Boeing Corporation, The National Aeronautics and Space Administration (NASA), the University of Texas, and the University of Michigan.

The Status of X.500 Directories Today

The X.500 standards themselves have grown from basic user access and distribution to encompass single-master replication (or shadowing , as X.500 calls it), along with a choice of standard access control schemes and many other features. The future of X.500 standardization activities is somewhat unclear at this time because development within ISO has slowed.

A number of available products implement the recent X.500 standards. Without exception, the X.500 products all support LDAP access to their directory services. Some of the prominent X.500 products include

  • ISOCOR's Global Directory Server

  • Datacraft's OpenDirectory Dxserver

  • Control Data's Rialto Global Directory Server

X.500 directories are generally aimed at meeting the needs of organizations performing synchronization of email systems. Typically, the deployment of an X.500 directory service is done in partnership with the X.500 software vendor. Most vendors provide extensive consulting services to help organizations deploy and integrate an X.500 directory into their existing environment.

The Creation and Rise of LDAP

The early adopters of X.500 found that DAP (X.500's directory client access protocol) was fairly complex and not well suited for or available on the desktop computers of the day (PCs and Macintoshes). DAP is large, complex, and difficult to implement, and most implementations perform poorly. Because the majority of potential directory services users had ordinary machines on their desks, the people deploying X.500 began to look for an approach that avoided the heavyweight DAP.

Forerunners of LDAP: DIXIE and DAS

Around 1990, two independent groups devised similar protocols that were simpler and easier for desktop computers to implement than DAP. The desktop clients spoke one of these new protocols directly over TCP/IP to an intermediate server, which in turn implemented X.500 DAP. These two groups both brought their work to the Internet Engineering Task Force (IETF).

The IETF

The IETF is a large, open, international group of network researchers, designers, and operators who work on evolving Internet architecture and enhancing its capabilities. The IETF was formally chartered in 1986, although it existed informally for some time before that. The IETF is primarily focused on the task of protocol development and engineering for the Internet. The group is open to any interested individual; there are no membership requirements and only a small fee to cover the cost of meetings. The IETF holds face-to-face meetings three times each year.

The technical work is primarily done within IETF working groups (although individual or vendor contributions are also accepted). The working groups have one or more chairpersons, and the group members meet three times each year at the regularly scheduled IETF meetings. However, most of the work happens outside the meetings on electronic mailing lists that each working group maintains. The working groups are organized into several large areas (routing, security, transport, applications, and so on).

Specifications produced by IETF members are first published in draft documents called, logically enough, Internet Drafts. When consensus is reached in a working group and a series of technical and administrative requirements are adequately met, documents may be published as requests for comments (RFCs). All IETF documents are freely available at no cost on the Internet. It is worth noting that there are several categories of RFCs, ranging from Informational to Experimental to Standards Track, and that very few RFCs are intended to become official Internet Standards. As of mid-1998, almost 2,500 RFCs had been published, but only 58 had reached full Internet Standard status.

The first IETF meeting, held in San Diego in January 1986, was attended by 21 network engineers . A recent IETF meeting held in August 1998 in Chicago was attended by more than 2,000 people. As of late 1998, there were more than 100 active working groups organized into 8 areas within IETF. More information about IETF can be found on its World Wide Web site at http://www.ietf.org .



The two lightweight protocols for desktop computers were called Directory Assistance Service (DAS), defined in RFC 1202; and Directory Interface to X.500 Implemented Efficiently (DIXIE), defined in RFC 1249. The architecture of a directory system that uses a DIXIE client/client/server architecture is shown in Figure 2.5.

Figure 2.5 DIXIE provides a front end to an X.500 directory.

Both protocols were very successful; DIXIE, though, was quickly adopted as the preferred method to access X.500 directory systems. However, one shortcoming of the DAS and DIXIE protocols is that both were tied closely to a single X.500 implementation (Quipu).

The Creation of LDAP

After DIXIE and DAS showed the utility of a lighter-weight access protocol for X.500, the members of the Open System Interconnection “Directory Services (OSI “DS) working group within the IETF decided to join forces and produce a full-featured , lightweight directory access protocol for X.500 directories. Thus, LDAP was born.

The developers of the first LDAP specification were Wengyik Yeong, Steve Kille, Colin Robbins, and Tim Howes, who is one of the authors of this book. It is important to also note that contributions were made by many people from the Internet and X.500 communities. The first LDAP specification was published as RFC 1487 in July 1993. The first version of LDAP to see widespread use was version 2 (LDAPv2); the final specification for LDAPv2 was published as RFC 1777.

LDAP Innovations

The LDAP developers simplified the heavyweight X.500 DAP protocol in four important areas:

  • Functionality ”   LDAP provides most of DAP's functionality at a much lower cost. Redundant operations and rarely used features of DAP were eliminated, simplifying the implementation of LDAP clients and servers.

  • Data representation ”   Most data elements are carried as simple text strings in LDAP, although messages are still wrapped in binary encodings for efficiency. This simplifies implementations and increases performance.

  • Encoding ”   The LDAP protocol data elements are encoded using a subset of the encoding rules used by X.500, thus simplifying implementation.

  • Transport ”   LDAP runs directly over TCP instead of requiring the unwieldy, multilayer OSI networking stack. Implementation is simplified, performance is increased, and the need for OSI is eliminated, which eases the deployment of LDAP directories.

Early LDAP Implementations

At first, LDAP was used exclusively to provide a front end for X.500-based directory services. The first and best-known LDAP implementation was produced by the authors while at the University of Michigan. The U-M LDAP implementation, as it came to be known, was small and fast, and it ran on a wide variety of popular computing platforms. Most important of all, it included a simple, well-specified C language API that implemented all of the client side of LDAP and could be used to develop any kind of LDAP client application. The LDAPv2 client API eventually became a de facto standard and was published in RFC 1823. The components of the early U-M LDAP software releases are depicted in Figure 2.6.

Figure 2.6 Major components of the early U-M LDAP releases.

The first version of the U-M LDAP implementation was released publicly on the Internet in 1992 with a copyright notice that allowed unrestricted use of the software. A wide range of freely available and commercial LDAP client software soon followed, much of which was based on the University of Michigan implementation.

LDAP as a Standalone Directory Service

In early 1995, the LDAP group at U-M found itself on the brink of another revelation. When examining the directory access statistics for the U-M service, the group noticed that well over 99% of the X.500 directory access came through LDAP. This was true of most X.500 directories. The architecture prevalent at the time is shown in Figure 2.7.

Figure 2.7 LDAP directory system architecture, circa 1995.

Although LDAP had solved the directory client access problem, the server implementations were still large, complex, and difficult to deploy. The U-M LDAP group realized that by eliminating the intermediate ldapd server, the overall complexity of the system could be greatly reduced and the performance greatly increased. After all, ldapd spent all its time translating LDAP requests into DAP requests and recasting the DAP results returned from the X.500 servers as LDAP results.

In addition, the promise of a global, interconnected X.500 directory didn't seem to be achievable, and so the need for an X.500 directory server at all was questioned. The concept of a standalone, or native, LDAP server was born. The new server was dubbed SLAPD (for standalone LDAP daemon), and with the aid of a grant from the National Science Foundation, it was quickly implemented. The revised LDAP system architecture is shown in Figure 2.8.

Figure 2.8 LDAP system architecture after the introduction of SLAPD.

While keeping the best pieces of the X.500 models (see Chapter 3, "An Introduction to LDAP," for more information), LDAP had now broken free of the last bit of X.500 and could proudly stand on its own. At the same time, referrals were added to the LDAPv2 protocol as an experimental extension to support an interconnected mesh of SLAPD directory servers. These changes moved LDAP out of its role as a simple, useful protocol for accessing X.500 directories to a much broader role as the foundation for a complete directory service. The first release of the U-M LDAP software to include SLAPD was the U-M LDAP 3.2 release in December 1995.

LDAP Momentum

LDAP's commercial success was assured in April 1996 when Netscape headed a coalition of more than 40 prominent software companies that endorsed LDAP as the Internet directory service protocol of choice. Today, Netscape produces a complete set of enterprise software that is centered around an LDAP-based directory service, and all major network application software vendors support LDAP in their client and server products.

LDAP Version 3 Developed

Recently, LDAP entered an even more mature phase in its evolution with the release of version 3 of the protocol (LDAPv3). Mark Wahl of Innosoft International, Inc., along with some of the original LDAP authors and a cast of hundreds from across the Internet, contributed to the LDAPv3 specification. LDAPv3 improves on LDAPv2 in the following important areas:

  • Internationalization ”   The UTF-8 character set is used everywhere it is appropriate. Because UTF-8 is an encoding of the universal Unicode character set, all the characters used in every language in the world can be stored and manipulated by LDAPv3 directory servers and clients.

  • Referrals ”   A standard mechanism for returning referrals to other servers was added, which allows LDAP servers to be deployed in a bottom-up fashion, just as World Wide Web servers are.

  • Security ”   Support for Simple Authentication and Security Layer (SASL) and Transport Layer Security (TLS) were added to increase LDAP's security and allow a richer set of applications to be supported.

  • Extensibility ”   LDAPv3 can be extended to support new operations, and existing operations can be extended through the use of controls, allowing LDAP to be incrementally enhanced to meet future needs.

  • Feature and schema discovery ”   All LDAPv3 servers publish the versions of the LDAP protocol they support along with other useful information in a special directory entry called the root DSE (DSA or Directory Server-Specific Entry). In addition, LDAPv3 servers publish their supported directory schemas as a set of LDAP attributes. These features help LDAP clients and servers work together more intelligently.

In late 1997, LDAPv3 was the winner of the PC Magazine Award for Technical Excellence in the Networking category. Some vendors are shipping LDAPv3-compliant products today, and you can expect many more to follow. In late 1997, LDAPv3 was approved as a proposed Internet Standard (the first step on its way to becoming a full Internet Standard). The LDAPv3 specification is available as the following series of RFCs:

  • RFC 2251: LDAPv3 Protocol ”   Describes the LDAP protocol itself

  • RFC 2252: LDAPv3 Attribute Syntax Definitions ”   Defines attribute syntaxes used by LDAP and its applications, including how these values are represented as simple strings

  • RFC 2253: LDAPv3 UTF-8 String Representation of Distinguished Names ”   Describes how distinguished names are represented as simple strings using the UTF-8 character set

  • RFC 2254: The String Representation of LDAP Search Filters ”   Defines a scheme for representing LDAP search filters (which may be complex Boolean expressions involving multiple terms) as simple strings for use in LDAP URLs and APIs

  • RFC 2255: The LDAP URL Format ”   Defines a uniform resource locator (URL) scheme to represent LDAP search requests

  • RFC 2256: A Summary of the X.500(96) User Schema for Use with LDAPv3 ”   Provides a list of useful directory schemas (attributes and object classes) that are pulled from the X.500 specifications

Like their X.500 counterparts, developers of LDAP directories must absorb quite a few documents before they can successfully develop LDAP software. Fortunately, all RFCs are freely available on the Internet, and most related to LDAP are fairly short and easy to read. Unfortunately, some of the LDAP documents assume that the reader has knowledge that can only be obtained by consulting the X.500 standards.

Status of LDAP Directories Today

LDAP is now shepherded by the LDAP Extensions (LDAPEXT) working group within the IETF. People from a variety of companies, universities, and research organizations are contributing to the evolution of LDAP. Current areas of work include access control, replication, and a variety of small but useful extensions to the LDAPv3 protocol. Thanks to the simple but flexible extension mechanisms that are included in LDAPv3, no one expects an LDAP version 4 to be needed any time soon.

Most of the available LDAP directory services products are modeled after the original University of Michigan SLAPD concept. Typically, they are built around a standalone LDAP server that includes a high-performance embedded database. In some cases, the implementation is actually based on the U-M code; in other cases, vendors of X.500 or other directory services embraced LDAP strongly and have made it their directory access and operational protocol of choice. Some examples of general-purpose LDAP directory services available at the time of this writing include

  • Netscape's Directory Server

  • Innosoft Distributed Directory Server

  • Lucent Technologies's Internet Directory Server

  • Sun Microsystems's Directory Services

  • IBM's DSSeries LDAP Directory

  • University of Michigan's SLAPD server

These directory products are designed to support a variety of Internet, intranet, and extranet applications. They usually provide good integration with other services that are based on Internet protocols, such as SMTP-based messaging servers, HTTP-based Web servers, and the like. They provide good administrative tools, are relatively inexpensive, and aim to be easy to deploy

IETF Directory Services Working Groups

Over the years , a number of different IETF working groups have dealt with LDAP. All these groups have been chartered within the Applications or Operations areas of the IETF.

The first group to deal with LDAP was OSI “DS. Some work that was focused on adapting X.500 for the Internet along with all the early DAS, DIXIE, and LDAP work was done within the confines of OSI “DS.

In 1993, the directory services efforts in the IETF were split into several groups. These groups included Access, Searching, and Indexing of Directories (ASID) and Integrated Directory Services (IDS). The core LDAPv3 work was done within the ASID group; IDS focused mainly on directory service issues that were not specific to LDAP, such as security and privacy.

Recently, the ASID and IDS groups were disbanded, and a series of new working groups was chartered to continue LDAP's evolution. The LDAPEXT working group is focused on standardizing important extensions to LDAPv3 itself, such as a common access control scheme. The LDAP Duplication/ Replication/Update Protocol group (LDUP) is working on a multimaster replication standard for LDAP directory services. The SCHEMA group is designing a schema registration service for LDAP. Finally, the LDAP Service Deployment (LSD) group concerns itself with work that makes it easier for LDAP deployments to succeed.

More information about these IETF working groups can be found on the IETF's World Wide Web site at http://www.ietf.org./html. charters /wg.dir.html.



and maintain. Netscape has gone farther than most of the other vendors, as it has articulated and pursued a ive strategy to move all of its intranet applications, administration, and security services to LDAP.

Other Standards-Based, General-Purpose Directories

A variety of other directory services were developed in parallel with or shortly after the X.500 and LDAP directories. Many of these directories came out of the Internet community and were either niche services or competitors to X.500 and LDAP themselves. Although none of these services were ever widely endorsed like LDAP was, a number of organizations experimented with these services and may in some cases still be running directory services based on them.

CSO Nameserver

One of the best-known and widely used early Internet directories was the CSO Nameserver, which was developed at the University of Illinois. Sometimes known as ph (referring to the name of one of the programs used to access it), this service is typically used to store information about electronic mail users. CSO Nameserver, used by many Internet sites (mostly universities), became popular because of the availability of free software and client support from one of the earliest and best Internet email clients, Eudora. QUALCOMM, Inc. now develops and markets Eudora as a commercial product.

Competitors to LDAP

When it became clear that X.500 directories were not going to take the world by storm , several other efforts to produce lighter-weight services sprung up. Among these are WHOIS++ (RFC 1834), RWHOIS (RFC 1714), and SOLO. As you can guess by the names, the first two of these were designed as extensions (albeit, extensive in and of themselves) to the original WHOIS Internet protocol. SOLO, designed to fill some of the same needs as LDAP, borrowed ideas from both WHOIS++ and LDAP.



Understanding and Deploying LDAP Directory Services,  2002 New Riders Publishing
<  BACK CONTINUE  >

Index terms contained in this section

CCITT (International Telegraph and Telephone Consultative Committee)
components
          X.500 directory standard
CSO Nameserver
DAS
          LDAP development 2nd 3rd 4th 5th
data
         representation
                    LDAP innovations
directories
         history of
                    standards-based directories 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st
distribution
          X.500 standard
DIXIE
          LDAP development 2nd 3rd 4th 5th
encoding
          LDAP innovations
extensibility
          LDAPv3
          LDAPv3 improvements
flaws
          X.500 standard 2nd
functionality
          LDAP innovations
general-purpose directories 2nd 3rd 4th 5th
          CSO Nameserver
          LDAP 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
                    DIXIE and DAS 2nd 3rd 4th 5th
                    IETF (Internet Engineering Task Force) 2nd 3rd 4th 5th 6th
                    LDAPEXT working group (IETF)
                    native servers 2nd 3rd
                    software company software
                    U-M implementation 2nd
                    version 3 2nd 3rd 4th 5th 6th 7th
                    X.500 DAP innovations 2nd
          X.500 standard 2nd 3rd 4th 5th 6th
                    components
                    distribution
                    flaws 2nd
                    implementing
                    protocols
                    query support
                    Quipu 2nd
                    shadowing
                    X.501
                    X.509
                    X.511
                    X.518
                    X.519
                    X.520
                    X.521
                    X.525
Global Directory Server
history of directories
          standards-based directories 2nd
                    CSO Nameserver
                    LDAP 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
                    RWHOIS (RFC 1714)
                    SOLO
                    WHOIS++ (RFC 1834
                    X.500 standard 2nd 3rd 4th 5th 6th
Howes, Tim
IETF (Internet Engineering Task Force) 2nd 3rd 4th
          working groups 2nd
IIETF
          LDAPEXT working group
implementations
         LDAP
                    U-M 2nd
         X.500 standard
                    Quipu 2nd
implementing
          X.500 standard
International Organization for Standardization (ISO)
International Telegraph and Telephone Consultative Committee (CCITT)
internationalization
          LDAPv3 improvements
Internet Engineering Task Force (IETF) 2nd 3rd 4th
          working groups 2nd
ISO (International Organization for Standardization)
ITU (International Telecommunications Union)
Kille, Steve
LDAP directory standard 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
          IETF (Internet Engineering Task Force) 2nd 3rd 4th
                    working groups 2nd
          LDAPEXT working group (IETF)
          native servers 2nd 3rd
          software company support
          U-M implementation 2nd
          version 3
                    extensibility
                    internationalization
                    RFCs 2nd
                    security
                    server referrals
          X.500 DAP innovations 2nd
LDAP directory standard:DIXIE and DAS 2nd 3rd 4th 5th
LDAPv3
         improvements
                    extensibility
                    internationalization
                    RFCs 2nd
                    security
                    server referrals
native LDAP servers 2nd 3rd
networks
          OSI (Open Systems Interconnect)
OpenDirectory Dxserver
OSI (Open Systems Interconnect) networks
protocols
          X.500 standard
queries
          X.500 support
Quipu
          X.500 standard 2nd
referrals
         servers
                    LDAPv3
RFCs
          LDAPv3 improvements 2nd
Rialto Global Directory Server
Robbins, Colin
RWHOIS (RFC 1714) 2nd
security
          LDAPv3 improvements
servers
         LDAP
                    native 2nd 3rd
         referrals
                    LDAPv3 improvements
shadowing
          X.500 standard
single-master replication, see shadowing
software
         companies
                    LDAP support
SOLO 2nd
standalone LDAP servers 2nd 3rd
standards-based directories 2nd
          CSO Nameserver
          LDAP 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
                    IETF (Internet Engineering Task Force) 2nd 3rd 4th 5th 6th
                    LDAPEXT working group (IETF)
                    native servers 2nd 3rd
                    software company support
                    U-M implementation 2nd
                    version 3 2nd 3rd 4th 5th 6th 7th
                    X.500 DAP innovations 2nd
          LDAPlDIXIE and DAS 2nd 3rd 4th 5th
          RWHOIS (RFC 1714)
          SOLO
          WHOIS++ (RFC 1834
          X.500 standard 2nd 3rd 4th 5th 6th
                    compnents
                    distribution
                    flaws 2nd
                    implementing
                    protocols
                    query support
                    Quipu 2nd
                    shadowing
                    X.501
                    X.509
                    X.511
                    X.518
                    X.519
                    X.520
                    X.521
                    X.525
transport
          LDAP innovations
U-M LDAP implementation 2nd
Wahl, Mark
WHOIS++ (RFC 1834)
working groups
          IETF 2nd
X.500 directory standard 2nd 3rd 4th 5th 6th
          components
          distribution
          flaws 2nd
          implementing
          protocols
          query support
          Quipu 2nd
          shadowing
          X.501
          X.509
          X.511
          X.518
          X.519
          X.520
          X.521
          X.525
X.501 directory standard
X.509 directory standard
X.511 directory standard
X.518 directory standard
X.519 directory standard
X.520 directory standard
X.521 directory standard
X.525 directory standard
Yeong, Wengyik

2002, O'Reilly & Associates, Inc.



Understanding and Deploying LDAP Directory Services
Understanding and Deploying LDAP Directory Services (2nd Edition)
ISBN: 0672323168
EAN: 2147483647
Year: 1997
Pages: 245

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net