copied from java.sun.com
The X.500 directory service is a global directory service. Its components cooperate to manage information about objects such as countries, organizations, people, machines, and so on in a worldwide scope. It provides the capability to look up information by name (a white-pages service) and to browse and search for information (a yellow-pages service).
The information is held in a directory information base (DIB). Entries in the DIB are arranged in a tree structure called the directory information tree (DIT). Each entry is a named object and consists of a set of attributes. Each attribute has a defined attribute type and one or more values. The directory schema defines the mandatory and optional attributes for each class of object (called the object class ). Each named object may have one or more object classes associated with it.
The X.500 namespace is hierarchical. An entry is unambiguously identified by a distinguished name (DN). A distinguished name is the concatenation of selected attributes from each entry, called the relative distinguished name (RDN), in the tree along a path leading from the root down to the named entry.
Users of the X.500 directory may (subject to access control) interrogate and modify the entries and attributes in the DIB.
For more information on the X.500, refer to the CCITT X.500 (1988/1993)/ISO Directory.
Although the concepts of distinguished names and relative distinguished names are core to the X.500 model, the X.500 standard itself does not define any string representation for names. What is communicated between the X.500 components is the structural form of names. The reasoning behind this is that the standard is sufficient to allow different implementations to interoperate. String names are never communicated between different implementations. Instead, they are necessary only for interaction with end-users. For that purpose, the standard allows any representation, not necessarily only string representations.
Systems that are based on the X.500, such as the LDAP, the DCE Directory, Novell's NDS , and Microsoft's Active Directory, each define its own string representation. For example, in the LDAP, a DN's RDNs are arranged right to left, separated by the comma character (","). Here's an example of a name that starts with "c=us" at the top and leads to "cn=Rosanna Lee" at the leaf. cn=Rosanna Lee, ou=People, o=Sun, c=us
Here's an example of the same name using the string representation of the DCE Directory and Microsoft's Active Directory. /c=us/o=Sun/ou=People/cn=Rosanna Lee The convention for these systems is that RDNs are ordered left to right and separated by the forward slash character ("/").
The X.500 standard defines a protocol (among others) for a client application to access the X.500 directory. Called the Directory Access Protocol (DAP), it is layered on top of the Open Systems Interconnection (OSI) protocol stack.
Application Programming Interfaces
The X.500 standard itself does not define an API for accessing the directory. Again, the X.500 standard is mainly concerned with interoperability between directory clients and directory servers and between different directory servers.
One standard API that has been defined for the X.500 is the X/Open Specifications API to Directory Services (XDS), a C language-based API that client programs use for accessing X.500 directories.