Movatterモバイル変換

Network Working Group                                        A. GrimstadRequest for Comments: 2377                                      R. HuberCategory: Informational                                             AT&T                                                             S. Sataluri                                                     Lucent Technologies                                                                 M. Wahl                                                     Critical Angle Inc.                                                          September 1998Naming Plan for Internet Directory-Enabled ApplicationsStatus 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 theRFC822 mailbox identifier. So an RDN   for person employing this store of identifiers would be, e.g.,      uid=John.Smith@acme.com   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=John.Smith@acme.com, dc=acme, dc=com      uid=Mary.Jones@acme.com, dc=corporate, dc=acme, dc=com      uid=J.Smith@worldnet.att.net, dc=legal, dc=acme, dc=com      cn=Reading Room, dc=physics, dc=national-lab, dc=edu2.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=USGrimstad, 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 detailGrimstad, et. al.            Informational                      [Page 5]

RFC 2377                A Directory Naming Plan           September 1998   inSection 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 inSection 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 andRFC822 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 inRFC1274   [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 wouldGrimstad, et. al.            Informational                      [Page 6]

RFC 2377                A Directory Naming Plan           September 1998   construct the DN      dc=acme, dc=com   from its domain name.  It would then use this DN as the root of its   subtree of directory information.   The DN itself can be used to identify a directory organization object   that represents information about the organization. The directory   schema required to enable this is described below insection 5.2.   The subordinates of the DN will be directory objects related to the   organization.  The domain component attribute can be used to name   subdivisions of the organization such as organizational units and   localities.  Acme, for example, might use the domain names   "corporate.acme.com" and "richmond.acme.com" to construct the names      dc=corporate, dc=acme, dc=com      dc=richmond, dc=acme, dc=com   under which to place its directory objects.  The directory schema   required to name organizationalUnit and locality objects in this way   is described below insection 5.2.   Note that subdivisions of the organization such as organizational   units and localities could also be assigned RDNs using the   conventional X.500 naming attributes, e.g.      ou=corporate, dc=acme, dc=com      l=richmond, dc=acme, dc=com.   Use of the dc attribute for the RDN of directory objects of class   "domain" is also possible [1].4.2 User ID (uid)   The userid (uid) attribute is defined and registered inRFC1274   [3][10].   This attribute may be used to construct the RDN for directory objects   subordinate to objects named according to the procedure described inSection 4.1.  This plan does not constrain how this attribute is   used.4.3 Common Name (cn)   The commonName (cn) attribute is defined and registered in X.500   [3][11].Grimstad, et. al.            Informational                      [Page 7]

RFC 2377                A Directory Naming Plan           September 1998   This attribute may be used to construct the RDN for directory objects   subordinate to objects named according to the procedure described inSection 4.1.  This plan does not constrain how this attribute is   used.4.4 Examples of uid and cn Usage   Although this plan places no constraints on the use of the uid and cn   attributes for name construction, we would like to offer some   suggestions by way of examples.   In practice, we have used uid for the RDN for person objects were we   could make use of an existing registry of names and cn for other   objects.   Examples of existing registries of identifiers for person objects areRFC822 mailbox identifiers, employee numbers and employee "handles".   Aside from the convenience to administrators of re-use of an existing   store of identifiers, if it is ever necessary to display to a user   his/her DN, there is some hope that it will be recognizable when such   identifiers are used.   We have foundRFC822 mailbox identifiers a particularly convenient   source for name construction.  When a person has several e-mail   addresses, one will be selected for the purpose of user   identification.  We call this the "distinguished" e-mail address or   the "distinguished"RFC822 mailbox identifier for the user.   For example, if there is a user affiliated with the organization Acme   having distinguished e-mail address J.Smith@acme.com, the uid   attribute will be:      uid=J.Smith@acme.com   The domain component attributes of a user's DN will normally be   constructed from the domain name of his/her distinguished e-mail   address.  That is, for the user uid=J.Smith@acme.com the domain   component attributes would typically be:      dc=acme, dc=com   The full LDAP DN for this user would then be:      uid=J.Smith@acme.com, dc=acme, dc=com   Directory administrators having severalRFC822 identifiers to choose   from when constructing a DN for a user should consider the following   factors:Grimstad, et. al.            Informational                      [Page 8]

RFC 2377                A Directory Naming Plan           September 1998      o Machine-independent addresses are likely to be more stable,        resulting in directory names that change less. Thus an        identifier such as:            js@acme.com        may well be preferable to one such as:            js@blaster.third-floor.acme.com.      o Use of some form of "handle" for the "local" part that is        distinct from a user's real name may result in fewer collisions        and thereby lessen user pain and suffering.  Thus the        identifier:            js@acme.com        may well be preferable to one such as:            J.Smith@acme.com   Practical experience with use of theRFC822 mailbox identifier scheme   described here has shown that there are situations where it is   convenient to use such identifies for all users in a particular   population, although a few users do not, in fact, possess working   mailboxes.  For example, an organization may have a existing unique   identification scheme for all employees that is used as a alias to   the employees' real mailboxes -- which may be quite heterogeneous in   structure.  The identification scheme works for all employees to   identify unambiguously each employee; it only works as an e-mail   alias for those employees having real mailboxes.  For this reason it   would be a bad assumption for directory-enabled applications to   assume the uid to be a valid mailbox; the value(s) of the mail   attribute should always be checked.   It is important to emphasize that the elements of the domain name of   anRFC822 identifier may, BUT NEED NOT, be the same as the domain   components of the DN.  This means that the domain components provide   a degree of freedom to support access control or other directory   structuring requirements that need not be mechanically reflected in   the user's e-mail address.  We do not want under any condition to   force the user's e-mail address to change just to facilitate a new   system requirement such as a modification in an access control   structure.  It should also be noted that while we do not require that   the domain components match theRFC822 identifier, we DO require that   the concatenated domain components form a registered domain name,   that is, one that is represented in the DNS. This automatically   avoids name conflicts in the directory hierarchy.Grimstad, et. al.            Informational                      [Page 9]

RFC 2377                A Directory Naming Plan           September 1998   To provide an example of a DN which deviates from what might be   considered the default structure, consider the following scenario.   Suppose that J.Smith needs to be granted special permissions to   information in the dc=acme, dc=com part of the LDAP DIT.  Since it   will be, in general, easier to organize special users by their name   structure than via groups (an arbitrary collection of DNs), we use   subdomains for this purpose.  Suppose the special permissions were   required by users in the MIS organizational unit.  A subdomain   "mis.acme.com" is established, if it does not already exist,   according to normal DNS procedures.  The special permissions will be   granted to users with the name structure:      uid=*, dc=mis, dc=acme, dc=com   The DN of J.Smith in this case will be:      uid=J.Smith@acme.com, dc=mis, dc=acme, dc=com   In principal, there is nothing to prevent the domain name elements of   theRFC822 identifier from being completely different from the domain   components of the DN.  For instance, the DN for a J.Smith could be:      uid=J.Smith@worldnet.att.net, dc=mis, dc=acme, dc=com   While we do not REQUIRE that the domain name part of the uid match   the dc components of the directory distinguished name, we suggest   that this be done where possible. At a minimum, if the most   significant pieces of the DN and the uid are the same (i.e.,   "dc=acme, dc=com" and "acme.com") the likelihood, based on a   knowledge of a user's e-mail address, of discovering an appropriate   directory system to contact to find information about the user is   greatly enhanced.   The example above represents a situation where this suggestion isn't   possible because some of the users in a population have mailbox   identifiers that differ from the pattern of the rest of the users,   e.g., most mailboxes are of the form local@acme.com, but a   subpopulation have mailboxes from an ISP and therefore mailboxes of   the form local@worldnet.att.net.5.0 Naming Plan and Directories5.1 Directory Services Considerations   We envision the deployment of LDAP-based directory services on the   Internet to take the form of loosely coupled LDAP servers. This   coupling will occur at two levels.Grimstad, et. al.            Informational                     [Page 10]

RFC 2377                A Directory Naming Plan           September 1998   Firstly, LDAP servers will be loosely connected into islands (i.e. a   set of servers sharing a single DN namespace). The glue connecting   the islands will be LDAP referral [12] information configured into   the LDAP servers. An LDAP search directed to any server in such an   island can be answered, if the information is not available to that   server, by an LDAP referral to another, more appropriate server   within the same island.   Secondly, various techniques will be used span LDAP islands. The   concept that enables such techniques is the LDAP URL [13]. By   combining a DNS host name and port (corresponding to one or more LDAP   servers) with a DN, the LDAP URL provides unified high-level   identification scheme (an LDAP URL namespace) for directory objects.   Because an LDAP referral is expressed as one or more LDAP URL, these   two levels of coupling may not sharply distinguished in practice.   We do not envision the X.500 model of a single DIT (i.e. a single DN   namespace) to be viable in an environment of competing service   providers.  This naming plan does not attempt to produce DNs to hide   the possibility that a given real-world object may have independently   managed directory objects with the same DN associated with it.5.2 Directory Schema Implications of the Naming Plan   The traditional directory schema(s) developed for the X.500 standard   and its application to the Internet [4] require extension to be used   with the naming plan developed here. The extensions described below   attempt to reuse existing schema elements as much as possible. The   directory objects for which extensions are required are:   organization, organizational unit, and various classes of leaf   objects. We describe the schema modifications below for organization,   organizationalUnit and selected leaf classes.   So as to continue to use existing structural object classes to the   extent possible, we propose supplementing entries based on these   classes with additional information from two new auxiliary object   classes, dcObject and uidObject. They are specified using the   notation in Section 4 of [14].   The auxiliary object class dcObject is defined in "Using Domains in   LDAP Distinguished Names" [1].Grimstad, et. al.            Informational                     [Page 11]

RFC 2377                A Directory Naming Plan           September 1998   The auxiliary object class uidObject is defined as:   ( 1.3.6.1.1.3.1     NAME uidObject     SUP top     AUXILIARY     MUST uid )5.2.1 Organization Schema   The dc attribute is employed to construct the RDN of an organization   object.  This is enabled by adding the auxiliary class dcObject to   the organization's objectClass attribute.5.2.2 Organizational Unit Schema   The dc attribute is employed to construct the RDN of an   organizationalUnit object (which is subordinate in the DIT to either   an organization or an organizationalUnit object).  This is enabled by   adding the auxiliary class dcObject to the organizational unit's   objectClass attribute.5.2.3 Person Schema   No schema extensions are required for person objects if either the   inetOrgPerson [15] (preferred) or the newPilotPerson object classes   are used. The attribute uid is permissible in each class. For   consistency, the uidObject could be added to person entry objectClass   attributes to assist applications filtering on this object class   attribute value. Use of other classes for person objects with RDN   constructed with the uid attribute such as organizationalPerson   requires the use of the uidObject class.   It has been traditional in X.500 and LDAP directory services to   employ the common name (cn) attribute in naming.  While this naming   plan doesn't require use of the cn attribute in naming, it should be   stressed that it is a required attribute in any class derived from   the person class and is still quite important.  It will play a   significant role in enabling searches to find user entries of   interest.5.2.4 Certification Authority Schema   The certification authority (CA) object class is an auxiliary class,   meaning it is essentially a set of additional attributes for a base   class such as organizationalRole, organization, organizationalUnit or   person.  Except in the case where the base structural class is   inetOrgPerson, use of the uid attribute to construct the RDN of a CAGrimstad, et. al.            Informational                     [Page 12]

RFC 2377                A Directory Naming Plan           September 1998   will require the auxiliary class uidObject to permit the uid   attribute to be used. In the cases where organizationalUnit or   organization is the base class for a CA, use of the auxiliary class   dcObject will permit the RDN of the CA to be a domain component.5.2.5 Server and Server Application Schema   Servers and server applications are typically represented, for want   of anything better, by entries of the object class applicationProcess   (or a class derived from it).  Sometimes the class applicationEntity   is used.  In either case, the uid attribute should probably not be   employed to construct the RDN of a server or server application   object.  The standard schema uses the attribute cn for such RDNs.   Suppose one wants to use this naming plan both in the construction of   DNs for SSL server certificates and for their storage in a directory.   It is customary for clients connecting via SSL to compare the   server's domain name (e.g. from the URL used to contact the server)   with the value of the cn attribute in the subject field (i.e.   subject's DN) of the server's certificate. For this reason, it is   common practice to set the cn attribute to the server's domain name.   The naming and schema to handle this situation is best explained by   an example. Consider the server "host.acme.com". Following the   algorithm in "Using Domains in LDAP Distinguished Names" [1], the DN   dc=host, dc=acme, dc=com is constructed. To conform to the existing   practices just described, the server's subject DN for the SSL server   certificate should be cn=host.acme.com, dc=host, dc=acme, dc=com and   the server's certificate should be stored in a directory entry with   this name. This entry should use application process or application   entity as its structural object class and strong authentication user   as is auxiliary class.5.2.6 Name Forms   For X.500 servers or LDAP servers following the X.500 model, our   schema requires the definition of new name forms, structure rules,   and DIT content rules.  Structure rules and DIT content rules are   locally defined, and do not involve a globally significant object   identifier.   The following name forms are defined using the syntax of section 6.22   of [14] for the convenience of those using such servers.   Note that since the structural object classes organization,   organizationalUnit, locality and organizationalPerson do not permit   inclusion of the dc attribute, an auxiliary object class such as   dcObject [1] must be used for instances of these classes.)Grimstad, et. al.            Informational                     [Page 13]

RFC 2377                A Directory Naming Plan           September 19985.2.6.1 Name Form for Domain Objects   The OIDs in this group are under the   iso.org.dod.internet.directory.NameForm branch of the OID tree   (1.3.6.1.1.2).   ( 1.3.6.1.1.2.1     NAME domainNameForm     OC domain     MUST dc )   The domainNameForm name form indicates that objects of structural   object class domain have their RDN constructed from a value of the   attribute dc.5.2.6.2 Name Form for Organization Objects   ( 1.3.6.1.1.2.2     NAME dcOrganizationNameForm     OC organization     MUST dc )   The dcOrganizationNameForm name form indicates that objects of   structural object class organization have their RDN constructed from   a value of the attribute dc.5.2.6.3 Name Form for Organizational Unit Objects   ( 1.3.6.1.1.2.3     NAME dcOrganizationalUnitNameForm     OC organizationalUnit     MUST dc )   The dcOrganizationalUnitNameForm name form indicates that objects of   structural object class organizationalUnit have their RDN constructed   from a value of the attribute dc.5.2.6.4 Name Form for Locality Objects   ( 1.3.6.1.1.2.4     NAME dcLocalityNameForm     OC locality     MUST dc )   The dcLocalityNameForm name form indicates that objects of structural   object class locality have their RDN constructed from a value of the   attribute dc.Grimstad, et. al.            Informational                     [Page 14]

RFC 2377                A Directory Naming Plan           September 19985.2.6.5 Name Form for Organizational Person Objects   ( 1.3.6.1.1.2.5     NAME uidOrganizationalPersonNameForm     OC organizationalPerson     MUST uid )   The uidOrganizationalPersonNameForm name form indicates that objects   of structural object class organizationalPerson have their RDN   constructed from a value of the attribute uid.6.0 Security Considerations   Although access controls may be placed on portions of the DIT to deny   browse access to unauthorized clients, it may be possible to infer   directory names and DIT structure in such sensitive portions of the   DIT from the results of DNS queries. Providing public visibility to   some portions of the DIT may assist those make such inferences.7.0 Acknowledgments   This plan has emerged in the course of a number of fruitful   discussions, especially with David Chadwick, John Dale, Joe Gajewski,   Mark Jackson, Ryan Moats, Tom Spencer and Chris Tzu.8.0 References   [1]     Kille, S., Wahl, M., Grimstad, A., Huber, R., and S.           Sataluri, "Using Domains in LDAP Distinguished Names",RFC2247, January 1998.   [2]     X.500: The Directory -- Overview of Concepts, Models, and           Service, CCITT Recommendation X.500, December, 1988.   [3]     Barker, P., and S. Kille, "The COSINE and Internet X.500           Schema",RFC 1274, November 1991.   [4]     The North American Directory Forum, "A Naming Scheme for           c=US",RFC 1255, September 1991.   [5]     The North American Directory Forum, "NADF Standing Documents:           A Brief Overview",RFC 1417, February 1993.   [6]     Yeong, W., Howes, T., and S. Kille, "Lightweight Directory           Access Protocol",RFC 1777, March 1995.   [7]     Wahl, M., Howes, T., and S. Kille, "Lightweight Directory           Access Protocol (v3)",RFC 2251, December 1997.Grimstad, et. al.            Informational                     [Page 15]

RFC 2377                A Directory Naming Plan           September 1998   [8]     Kille, S., "A String Representation of Distinguished Names",RFC 1779, March 1995.   [9]     Wahl, M., Kille, S., and T. Howes, "Lightweight Directory           Access Protocol (v3): UTF-8 String Representation of           Distinguished Names",RFC 2253, December 1997.   [10]    Wahl, M., "A Summary of the Pilot X.500 Schema for use           in LDAPv3", Work in Progress.   [11]    Wahl, M., "A Summary of the X.500 User Schema for use with           LDAPv3",RFC 2256, December 1997.   [12]    Howes, T., and M. Wahl, "Referrals and Knowledge References           in LDAP Directories", Work in Progress.   [13]    Howes, T., and M. Smith, "The LDAP URL Format",RFC 2255,           December 1997.   [14]    Wahl, M., Coulbeck, A., Howes, T., and S. Kille,           "Lightweight Directory Access Protocol (v3): Attribute Syntax           Definitions",RFC 2252, December 1997.   [15]    Smith, M.,"Definition of the inetOrgPerson Object Class",           Work in Progress.Grimstad, et. al.            Informational                     [Page 16]

RFC 2377                A Directory Naming Plan           September 199812.  Authors' Addresses   Al Grimstad   AT&T   Room 1C-429, 101 Crawfords Corner Road   Holmdel, NJ 07733-3030   USA   EMail:  alg@att.com   Rick Huber   AT&T   Room 1B-433, 101 Crawfords Corner Road   Holmdel, NJ 07733-3030   USA   EMail:  rvh@att.com   Sri Sataluri   Lucent Technologies   Room 4D-335, 101 Crawfords Corner Road   Holmdel, NJ 07733-3030   USA   EMail:  srs@lucent.com   Mark Wahl   Critical Angle Inc.   4815 W Braker Lane #502-385   Austin, TX 78759   USA   EMail:  M.Wahl@critical-angle.comGrimstad, et. al.            Informational                     [Page 17]

RFC 2377                A Directory Naming Plan           September 199813.  Full Copyright Statement   Copyright (C) The Internet Society (1998).  All Rights Reserved.   This document and translations of it may be copied and furnished to   others, and derivative works that comment on or otherwise explain it   or assist in its implementation may be prepared, copied, published   and distributed, in whole or in part, without restriction of any   kind, provided that the above copyright notice and this paragraph are   included on all such copies and derivative works.  However, this   document itself may not be modified in any way, such as by removing   the copyright notice or references to the Internet Society or other   Internet organizations, except as needed for the purpose of   developing Internet standards in which case the procedures for   copyrights defined in the Internet Standards process must be   followed, or as required to translate it into languages other than   English.   The limited permissions granted above are perpetual and will not be   revoked by the Internet Society or its successors or assigns.   This document and the information contained herein is provided on an   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Grimstad, et. al.            Informational                     [Page 18]