rfc2377.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.


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 in section 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 in section 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 in RFC1274
   [3][10].

   This attribute may be used to construct the RDN for directory objects
   subordinate to objects named according to the procedure described in
   Section 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 in
   Section 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 are
   RFC822 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 found RFC822 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 [e-mail], the uid
   attribute will be:

      uid=[e-mail]

   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=[e-mail] the domain
   component attributes would typically be:

      dc=acme, dc=com

   The full LDAP DN for this user would then be:

      uid=[e-mail], dc=acme, dc=com

   Directory administrators having several RFC822 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:

            [e-mail]

        may well be preferable to one such as:

            [e-mail].

      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:

            [e-mail]

        may well be preferable to one such as:

            [e-mail]

   Practical experience with use of the RFC822 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
   an RFC822 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 the RFC822 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=[e-mail], dc=mis, dc=acme, dc=com

   In principal, there is nothing to prevent the domain name elements of
   the RFC822 identifier from being completely different from the domain
   components of the DN.  For instance, the DN for a J.Smith could be:

      uid=[e-mail], 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 [e-mail], but a
   subpopulation have mailboxes from an ISP and therefore mailboxes of
   the form [e-mail].

5.0 Naming Plan and Directories

5.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 CA



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