rfc2377.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,012 行 · 第 1/3 页

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.

Abstract

   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
   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                      [Page 2]

RFC 2377                A Directory Naming Plan           September 1998


   One approach to their use, for example, is to employ the uid
   attribute as the RDN when reusing an existing store of identifiers
   and the cn attribute as the RDN when creating new identifiers
   specifically for the directory.  A convenient existing identification
   scheme for person objects is the RFC822 mailbox identifier. So an RDN
   for person employing this store of identifiers would be, e.g.,

      uid=[e-mail]

   For leaf objects not conveniently identified with such a scheme, the
   "cn" attribute is used, e.g.,

      cn=Reading Room

   Directory distinguished names will thus have the following structure,
   e.g.,

      uid=[e-mail], dc=acme, dc=com
      uid=[e-mail], dc=corporate, dc=acme, dc=com
      uid=[e-mail], dc=legal, dc=acme, dc=com
      cn=Reading Room, dc=physics, dc=national-lab, dc=edu

2.0 The Problem

   The X.500 Directory model [2] can be used to create a world-wide
   distributed directory. The Internet X.500 Directory Pilot has been
   operational for several years and has grown to a size of about 1.5
   million entries of varying quality.  The rate of growth of the pilot
   is far lower than the rate of growth of the Internet during the pilot
   period.

   There are a substantial number of contributing factors that have
   inhibited the growth of this pilot.  The common X.500 approach to
   naming, while not the preponderant problem, has contributed in
   several ways to limit the growth of an Internet White Pages Service
   based on X.500.

   The conventional way to construct names in the X.500 community is
   documented as an informative (i.e., not officially standardized)
   Annex B to X.521. The relative distinguished name (RDN) of a user
   consists of a common name (cn) attribute. This is meant to be what --
   in the user's particular society -- is customarily understood to be
   the name of that user. The distinguished name of a user is the
   combination of the name of some general object, such as an
   organization or a geographical unit, with the common name. There are
   two main problems with this style of name construction.





Grimstad, et. al.            Informational                      [Page 3]

RFC 2377                A Directory Naming Plan           September 1998


   First, the common name attribute, while seeming to be user-friendly,
   cannot be used generally as an RDN in practice.  In any significant
   set of users to be named under the same Directory Information Tree
   (DIT) node there will be collisions on common name.  There is no way
   to overcome this other than either by forcing uniqueness on common
   names, something they do not possess, or by using an additional
   attribute to prevent collisions.  This additional attribute normally
   needs to be unique in a much larger context to have any practical
   value.  The end result is a RDN that is very long and unpopular with
   users.

   Second, and more serious, X.500 has not been able to use any
   significant number of pre-existing names.  Since X.500 naming models
   typically use organization names as part of the hierarchy [2, 3],
   organization names must be registered.  As organization names are
   frequently tied to trademarks and are used in sales and promotions,
   registration can be a difficult and acrimonious process.

   The North American Directory Forum (NADF, now the North Atlantic
   Directory Forum but still the NADF) proposed to avoid the problem of
   registration by using names that were already registered in the
   "civil naming infrastructure" [4][5].  Directory distinguished names
   would be based on an organization's legal name as recognized by some
   governmental agency (county clerk, state secretary of state, etc.) or
   other registering entity such as ANSI.

   This scheme has the significant advantage of keeping directory
   service providers out of disputes about the right to use a particular
   name, but it leads to rather obscure names.  Among these obscurities,
   the legal name almost invariably takes a form that is less familiar
   and longer than what users typically associate with the organization.
   For example, in the US a large proportion of legal organization names
   end with the text ", Inc." as in "Acme, Inc."  Moreover, in the case
   of the US, the civil naming infrastructure does not operate
   nationally, so the organization names it provides must be located
   under state and regional DIT nodes, making them difficult to find
   while browsing the directory.  NADF proposes a way to algorithmically
   derive multi-attribute RDNs which would allow placement of entries or
   aliases in more convenient places in the DIT, but these derived names
   are cumbersome and unpopular.  For example, suppose Nadir is an
   organization that is registered in New Jersey civil naming
   infrastructure under the name "Nadir Networks, Inc."  Its civil
   distinguished name (DN) would then be

      o="Nadir Networks, Inc.", st=New Jersey, c=US






Grimstad, et. al.            Informational                      [Page 4]

RFC 2377                A Directory Naming Plan           September 1998


   while its derived name which is unambiguous under c=US directly is

      o="Nadir Networks, Inc." + st=New Jersey, c=US

   More generally, the requirement for registration of organizations in
   X.500 naming has led to the establishment of national registration
   authorities whose function is mainly limited to assignment of X.500
   organization names.  Because of the very limited attraction of X.500,
   interest in registering an organization with one of these national
   authorities has been minimal.  Finally, multi-national organizations
   are frustrated by a lack of an international registration authority.

3.0 Requirements

   A directory naming plan must provide a guide for the construction of
   names (identifiers, labels) for directory objects that are
   unambiguous (identify only one directory object) within some context
   (namespace), at a minimum within one isolated directory server.

   A directory object is simply a set of attribute values. The
   association between a real-world object and a directory object is
   made by directory-enabled applications and is, in the general case,
   one to many.

   The following additional naming characteristics are requirements that
   this naming plan seeks to satisfy:

   a) hierarchical

   The Internet, consisting of a very large number of objects and
   management domains, requires hierarchical names.  Such names permit
   delegation in the name assignment process and partitioning of
   directory information among directory servers.

   b) friendly to loose coupling of directory servers

   One purpose of this naming plan is to define a naming pattern that
   will facilitate one form or another of loose coupling of potentially
   autonomous directory servers into a larger system.

   A name in such a loosely-coupled system should unambiguously identify
   one real-world object.  The real-world object may, however, be
   represented differently (i.e. by different directory objects having
   different attributes but the same DN) in different (e.g.
   independently managed) servers in the loosely-coupled system.  The
   plan does not attempt to produce names to overcome this likely
   scenario.  That is, it does not attempt to produce a single namespace
   for all directory objects. (This issue is considered in more detail



Grimstad, et. al.            Informational                      [Page 5]

RFC 2377                A Directory Naming Plan           September 1998


   in Section 5.1.)

   c) readily usable by LDAP clients and servers

   As of this writing, a substantial number of the Lightweight Directory
   Access Protocol (LDAP) [6][7] implementations are currently available
   or soon will be.  The names specified by this naming plan should be
   readily usable by these implementations and applications based on
   them.

   d) friendly to re-use of existing Internet name registries

   As described in Section 2 above, creation of new global name
   registries has been highly problematic.  Therefore, a fundamental
   requirement this plan addresses is to enable the reuse of existing
   Internet name registries such as DNS names and RFC822 mailbox
   identifiers when constructing directory names.

   e) minimally user-friendly

   Although we expect that user interfaces of directory-enabled
   applications will avoid exposing users to DNs, it is unlikely that
   users can be totally insulated from them.  For this reason, the
   naming plan should permit use of familiar information in name
   construction.  Minimally, a user should be capable of recognizing the
   information encoded in his/her own DN.  Names that are totally opaque
   to users cannot meet this requirement.

4.0 Name Construction

   The paper assumes familiarity with the terminology and concepts
   behind the terms distinguished name (DN) and relative distinguished
   name (RDN) [2][8][9].

   We describe how DNs can be constructed using three attribute types,
   domainComponent (dc), userID (uid) and commonName (cn).  They are
   each described in turn.

4.1 Domain Component (dc)

   The domain component attribute is defined and registered in RFC1274
   [3][10].  It is used in the construction of a DN from a domain name.
   Details of the construction algorithm is described in "Using Domains
   in LDAP Distinguished Names" [1].

   An organization wishing to deploy a directory following this naming
   plan would proceed as follows.  Consider an organization, for example
   "Acme, Inc.", having the registered domain name "acme.com".  It would



Grimstad, et. al.            Informational                      [Page 6]