Naming Plan for Internet Directory-Enabled Applications
RFC 2377

Document Type RFC - Informational (September 1998; No errata)
Updated by RFC 4519
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2377 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                        A. Grimstad
Request for Comments: 2377                                      R. Huber
Category: Informational                                             AT&T
                                                             S. Sataluri
                                                     Lucent Technologies
                                                                 M. Wahl
                                                     Critical Angle Inc.
                                                          September 1998

        Naming Plan for Internet Directory-Enabled Applications

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.


   Application of the conventional X.500 approach to naming has
   heretofore, in the experience of the authors, proven to be an
   obstacle to the wide deployment of directory-enabled applications on
   the Internet.  We propose a new directory naming plan that leverages
   the strengths of the most popular and successful Internet naming
   schemes for naming objects in a hierarchical directory.  This plan
   can, we believe, by extending the X.500 approach to naming,
   facilitate the creation of an Internet White Pages Service (IWPS) and
   other directory-enabled applications by overcoming the problems
   encountered by those using the conventional X.500 approach.

1.0 Executive Summary

   Application of the conventional X.500 approach to naming has
   heretofore, in the experience of the authors, proven to be an
   obstacle to the wide deployment of directory-enabled applications on
   the Internet.  The required registration infrastructure is either
   non-existent or largely ignored.  The infrastructure that does exist
   is cumbersome to use and tends to produce counterproductive results.
   The attributes used for naming have been confusing for users and
   inflexible to managers and operators of directory servers.

Grimstad, et. al.            Informational                      [Page 1]
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

   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 "" 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 "" 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.
Show full document text