RFC 2377 (rfc2377) - Page 2 of 18
Naming Plan for Internet Directory-Enabled Applications
Alternative Format: Original Text Document
RFC 2377 A Directory Naming Plan September 1998
This paper describes a directory naming plan for the construction of
an Internet directory infrastructure to support directory-enabled
applications that can serve as an alternative (or extension) to the
conventional X.500 approach.
The plan has the following two main features. First, it bases the
root and upper portions of the name hierarchy on the existing
infrastructure of names from the Domain Name System (DNS). This
component of the plan makes use of the ideas described in the
companion paper to this plan, "Using Domains in LDAP Distinguished
Names" [1]. And second, it provides a number of options for the
assignment of names to directory leaf objects such as person objects,
including an option that allows the reuse of existing Internet
identifiers for people.
Just as the conventional X.500 style of naming is not a formal
standard, use of the naming plan described here is not obligatory for
directory-enabled applications on the Internet. Other approaches are
permissible. However, we believe widespread use of this plan will
largely eliminate naming as a typically thorny issue when
administrators set up an LDAP-based directory service. Further, we
strongly encourage developers of directory-enabled products,
especially LDAP clients and user interfaces, to assume that this
naming plan will see widespread use and design their products
accordingly.
Here, in summary, is our proposal.
The upper portions of the hierarchical directory tree should be
constructed using the components of registered DNS names using the
domain component attribute "dc". The directory name for the
organization having the domain name "acme.com" will then be, e.g.,
dc=acme, dc=com
Organizations can add additional directory structure, for example to
support implementation of access control lists or partitioning of
their directory information, by using registered subdomains of DNS
names, e.g., the subdomain "corporate.acme.com" can be used as the
basis for the directory name
dc=corporate, dc=acme, dc=com
For naming directory leaf objects such as persons, groups, server
applications and certification authorities in a hierarchical
directory, we propose the use of either the "uid" (user identifier)
or the "cn" (common name) attribute for the relative distinguished
name. This plan does not constrain how these two attributes are used.
Grimstad, et. al. Informational