LDAP Version 2

Comparison of the LDAP and JNDI Models

LDAP Version 2

Recognizing the need for an X.500-like service, but faced with different underlying network infrastructure (TCP/IP instead of OSI), the Internet community designed a new protocol based on the X.500 DAP protocol, called Lightweight DAP, or LDAP. RFC 1777 defines what is now referred to as version 2 of the Lightweight Directory Access Protocol (or LDAP v2).
The goal of the LDAP v2 was to have a protocol that could be easily implemented, with special focus on being able to build small and simple clients. One of the ways that it attempted to achieve simplification was to use a lot of strings and to minimize wherever possible the use of structures. Distinguished names, for example, are represented in the protocol as strings, as are attribute type names and many attribute values. The protocol consists of the client sending requests to the server, to which the server responds, though not necessarily in the same order in which the requests were sent. Each request is tagged with an ID so that requests and responses can be matched. The protocol works over either TCP or UDP, although it is the TCP version that is most commonly used.
With the focus on clients, the LDAP community also defined standards for the string representation of distinguished names (RFC 1779), search filters (RFC 1960), attribute syntaxes (RFC 1778), for a C-language-based API (RFC 1823), and for the format of URLs for accessing LDAP services (RFC 1959).
To further promote widespread use, University of Michigan gave away the LDAP client and servers for free.
Operations
The LDAP v2 defines the following operations.

Operation Description

bind The LDAP is a connection-oriented protocol. This operation is used to start a connection with the LDAP server. The client specifies the protocol version and the client authentication information.

unbind This operation is used to terminate the connection with the LDAP server.

search This operation is used to search the directory. The client specifies the starting point (base object) of the search, the search scope (the object only, its children, or the subtree rooted at the object), and a search filter (RFC 1960). It can also supply other information to control the search, such as the names of the attributes to return, and the size and time limits. The search results consist of LDAP entries (and the attributes requested) that satisfy the filter.
modify This operation is used to modify an existing entry. The client specifies the name of the object to be modified and a list of modifications. Each modification consists of an attribute and information regarding whether its values are to be added, deleted, or replaced.

add This operation is used to add a new entry. The client specifies the name of the new entry and a set of attributes for the new entry.

delete This operation is used to remove an existing entry. The client specifes the name of the entry to remove.

modify RDN This operation is used to change the RDN of the last component of an existing entry. (That is, to assign the entry a new name in the same context). The client specifies the (distinguished) name of the entry and the new RDN.

compare This operation is to used to test whether an entry has an attribute-value pair. The client specifies the name of the entry, and the name and value to check.

abandon This operation is used to terminate an outstanding request.

Compared with the X.500 Standard

At a very high level, the LDAP v2 looks a lot like the X.500. Both define a hierarchical directory information tree (DIT) comprising entries named using distinguished names. Each entry consists of a set of attributes. Both directories can be searched using search filters that contained (at the structural level) more or less the same elements. The operations defined by both protocols (such as search) are very similar.
There are of course many implementation differences between the X.500 and the LDAP. Most notably, their underlying protocol stacks are different: the X.500 protocols sits on top of the session/presentation layer of the OSI stack, while the LDAP runs on top of TCP. Furthermore, while the X.500 standard is comprehensive, with details specified to maximize interoperability in client-server and server-server interactions, the LDAP v2 standard is much more minimal because of its goals.

Operation	Description
bind	The LDAP is a connection-oriented protocol. This operation is used to start a connection with the LDAP server. The client specifies the protocol version and the client authentication information.
unbind	This operation is used to terminate the connection with the LDAP server.
search	This operation is used to search the directory. The client specifies the starting point (base object) of the search, the search scope (the object only, its children, or the subtree rooted at the object), and a search filter (RFC 1960). It can also supply other information to control the search, such as the names of the attributes to return, and the size and time limits. The search results consist of LDAP entries (and the attributes requested) that satisfy the filter.
modify	This operation is used to modify an existing entry. The client specifies the name of the object to be modified and a list of modifications. Each modification consists of an attribute and information regarding whether its values are to be added, deleted, or replaced.
add	This operation is used to add a new entry. The client specifies the name of the new entry and a set of attributes for the new entry.
delete	This operation is used to remove an existing entry. The client specifes the name of the entry to remove.
modify RDN	This operation is used to change the RDN of the last component of an existing entry. (That is, to assign the entry a new name in the same context). The client specifies the (distinguished) name of the entry and the new RDN.
compare	This operation is to used to test whether an entry has an attribute-value pair. The client specifies the name of the entry, and the name and value to check.
abandon	This operation is used to terminate an outstanding request.

Comparison of the LDAP and JNDI Models