RFC 2377 (rfc2377) - Page 2 of 18

Naming Plan for Internet Directory-Enabled Applications

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