rfc1617.txt

RFC 的详细文档！

RARE Working Group on Network Applications Support (WG-NAP)     [Page 7]

RFC 1617      Naming and Structuring Guidelines for X.500       May 1994


                            ROOT

                           / | \
                          /  |  \

                      C=GB  C=FR  C=US

                     /       |       \
                    /        |        \

          O=MultiNat---->O=MultiNat<----O=MultiNat

                         /    |    \
                        /     |     \
                       /      |      \

                 l=abc      ou=def     l=fgi

                     ---> means "alias to"

      Figure 1: The multi-national as a single entity

   The organisation's entries all exist under a single sub-tree. The
   organisational structure beneath the organisation entry should
   reflect the perceived structure of the organisation, and so no
   recommendations on this matter can be made here. To assist the person
   querying the directory, alias entries should be created under all
   countries where the organisation operates.

2.5.2 The Multi-National as a Loose Confederation

   Another common model of organisational structure is that where a
   multi-national consists of a number of national entities, which are
   in large part independent of both sibling national entities, and of
   any central entity. In such cases, the model shown in Figure 2 may be
   a better choice. Organisational entries exist within each country,
   and only that country's localities and organisational units appear
   directly beneath the appropriate organisational entry.













RARE Working Group on Network Applications Support (WG-NAP)     [Page 8]

RFC 1617      Naming and Structuring Guidelines for X.500       May 1994


                              ROOT

                             / | \
                            /  |  \
                        C=GB C=FR C=US

                        /      |     \
                       /       |      \
              O=MultiNat   O=MultiNat   O=MultiNat

             /    |        /    |   \        |    \
            /     |       /     |    \       |     \

        L=FR    L=GB<---L=GB     |   L=US--->L=US   L=FR
          \                      |                 /
           ------------------->L=FR<----------------

                      ---> means "alias to"

      Figure 2: The multi-national as a loose confederation

   Some binding together of the various parts of the organisation can be
   achieved by the use of aliases for localities and organisational
   units, and this can be done in a highly flexible fashion. In some
   cases, the national view might not contain all branches of the
   company, as illustrated in Figure 2.

2.5.3 Loosely Linked DIT Sub-Trees

   A third approach is to avoid aliasing altogether, and to use the
   looser binding provided by an attribute such as seeAlso. This
   approach treats all parts of an organisation as essentially separate.

   A unified view of the organisation can only be achieved by user
   interfaces choosing to follow the seeAlso links. This is a key
   difference with aliasing, where decisions to follow links may be
   specified within the protocol. (Note that it may be better to specify
   another attribute for this purpose, as seeAlso is likely to be used
   for a wide variety of purposes.)

2.5.4 Summary of Advantages and Disadvantages of the Above Approaches

   Providing an internal directory

      All the above methods can be used to provide an internal
      directory. In the first two cases, the linkage to other parts of
      the organisation can be followed by the protocol and thus
      organisation-wide searches can be achieved by single X.500



RARE Working Group on Network Applications Support (WG-NAP)     [Page 9]

RFC 1617      Naming and Structuring Guidelines for X.500       May 1994


      operations. In the last case, interfaces would have to "know" to
      follow the soft links indicated by the seeAlso attribute.

   Impact on naming

      In the single-entity model, all DNs within the organisation will
      be under one country. It could be argued that this will often
      result in rather "unnatural" naming. In the loose- confederation
      model, DNs are more natural, although the need to disambiguate
      between organisational units and localities on an international,
      rather than just a national, basis may have some impact on the
      choice of names. For example, it may be necessary to add in an
      extra level of organisational unit or locality information. In the
      loosely-linked model, there is no impact on naming at all.

   Views of the organisation

      The first method provides a unique view of the organisation.  The
      loose confederacy allows for a variety of views of the
      organisation. The view from the centre of the organisation may
      well be that all constituent organisations should be seen as part
      of the main organisation, whereas other parts of the organisation
      may only be interested in the organisation's centre and a few of
      its sibling organisations. The third model gives an equally
      flexible view of organisational structures.

   Lookup performance

      All methods should perform reasonably well, providing information
      is either held within a single DSA or it is replicated to the
      other DSAs.

3. Naming Style

   The first goal of naming is to provide unique identifiers for
   entries. Once this is achieved, the next major goal in naming entries
   should be to facilitate querying of the Directory. In particular,
   support for a naming structure which facilitates use of user friendly
   naming [5] is desirable. Other considerations, such as accurately
   reflecting the organisational structure of an organisation, should be
   disregarded if this has an adverse effect on normal querying. Early
   experience in the pilot has shown that a consistent approach to
   structure and naming is an aid to querying using a wide range of user
   interfaces, as interfaces are often optimised for DIT structures
   which appear prevalent. In addition, the X.501 standard notes that
   "RDNs are intended to be long-lived so that the users of the
   Directory can store the distinguished names of objects..." and "It is
   preferable that distinguished names of objects which humans have to



RARE Working Group on Network Applications Support (WG-NAP)    [Page 10]

RFC 1617      Naming and Structuring Guidelines for X.500       May 1994


   deal with be user-friendly." [2]

   Naming is dependent on a number of factors and these are now
   considered in turn.

3.1 Multi-Component Relative Distinguished Names

   According to the standard, relative distinguished names may have more
   than one component selected from the set of the attributes of the
   entry to be named. This is useful when there are, for example, two
   "John Smiths" in one department. The use of multi-component relative
   distinguished names allows one to avoid artificial naming values such
   as "John Smith 1" or "John Smith-2". Attributes which could be used
   as the additional naming attribute include: personalTitle,
   roomNumber, telephoneNumber, and userId.

3.2 National Guidelines for Naming

   Where naming is being done in a country which has established
   guidelines for naming, these guidelines should in general be
   followed. These guidelines might be based on an established
   registration authority, or may make use of an existing registration
   mechanism (e.g., company name registration).

   Where an organisation has a name which is nationally registered in an
   existing registry, this name is likely to be appropriate for use in
   the Directory, even in cases where there are no national guidelines.

3.3 Naming Organisation and Organisational Unit Names

   The naming of organisations in the Directory will ultimately come
   under the jurisdiction of official naming authorities. In the
   interim, it is recommended that pilots and organisations follow these
   guidelines. An organisation's RDN should usually be the full name of
   the organisation, rather than just a set of initials. This means that
   University College London should be preferred over UCL.  An example
   of the problems which a short name might cause is given by the
   proposed registration of AA for the Automobile Association.  This
   seems reasonable at first glance, as the Automobile Association is
   well known by this acronym. However, it seems less reasonable in a
   broader perspective when you consider that organisations such as
   Alcoholics Anonymous and American Airlines use the same acronym.

   Just as initials should usually be avoided for organisational RDNs,
   so should formal names which, for example, exist only on official
   charters and are not generally well known. There are two reasons for
   this approach:




RARE Working Group on Network Applications Support (WG-NAP)    [Page 11]

RFC 1617      Naming and Structuring Guidelines for X.500       May 1994


      1.   The names should be meaningful.

      2.   The names should uniquely identify the organisation, and be
           a name which is unlikely to be challenged in an open
           registration process. For example, UCL might well be
           challenged by United Carriers Ltd.

   The same arguments on naming style can be applied with even greater
   force to the choice of RDNs for organisational units. While
   abbreviated names will be in common parlance within an organisation,
   they will almost always be meaningless outside of that organisation.
   While many people in academic computing habitually refer to CS when
   thinking of Computer Science, CS may be given several different
   interpretations. It could equally be interpreted as Computing
   Services, Cognitive Science, Clinical Science or even Counselling
   Services.

   For both organisations and organisational units, extra naming
   information should be stored in the directory as alternative values
   of the naming attribute. Thus, for University College London, UCL
   should be stored as an alternative organizationName attribute value.
   Similarly CS could be stored as an alternative organizationalUnitName
   value for Computer Science and any of the other departments cited
   earlier. In general, entries will be located by searching, and so it
   is not essential to have RDNs which are either the most memorable or
   guessable, although names should be recognisable. The need for users
   not to type long names may be achieved by use of carefully selected
   alternative values.

3.4 Naming Human Users

   A reasonably consistent approach to naming people is particularly
   critical as a large percentage of directory usage will be looking up
   information about people. User interfaces will be better able to
   assist users if entries have names conforming to a common format, or
   small group of formats. It is suggested that the RDN should follow
   such a format. Alternative values of the common name attribute should
   be used to store extra naming information. It seems sensible to try
   to ensure that the RDN commonName value is genuinely the most common
   name for a person as it is likely that user interfaces may choose to
   place greater weight on matches on the RDN than on matches on one of
   the alternative names.

   The choice of RDN for humans will be influenced by cultural
   considerations. In many countries the best choice will be of the form
   familiar-first-name surname. Thus, Steve Kille is preferred as the
   RDN choice for one of this document's co-authors, while Stephen E.
   Kille is stored as an alternative commonName value. Pragmatic choices



RARE Working Group on Network Applications Support (WG-NAP)    [Page 12]

RFC 1617      Naming and Structuring Guidelines for X.500       May 1994


   will have to be made for other cultures. The common name attribute
   should not be used to hold other attribute information such as
   telephone numbers, room numbers, or local codes. Such information
   should be stored within the appropriate attributes as defined in the
   COSINE and Internet X.500 Schema. Section 3.1 on multi-component RDNs
   shows how clashing names can be made unique.

   The choice of a naming strategy should not be made on the basis of
   the possibilities of the currently available user interface
   implementations. For example, it is inappropriate to use common names
   of the form 'surname firstname' merely because a user interface
   presents results in a more satisfactory order by so doing. Use the
   best structure for human names, and fix the user interface!

   More details on the use of commonName in section 4.4.1.

3.5 Application Entities

   The guidelines of X.521 should be followed, in that the application
   entity should always be named relative to an Organisation or
   Organisational Unit. The application process will often correspond to
   a system or host. In this case, the application entities should be
   named by Common Names which identify the service (e.g., "FTAM
   Service"). In cases where there is no useful distinction between
   application process and application entity, the application process
   may be omitted (This is often done for DSAs in the current pilot).

4. Attribute Values

   In general the attribute values should be used as documented in the
   standards. Sometimes the standard is not very precise about which
   attribute to use and how to represent a value.

   The following sections give recommendations how to use them in X.500
   pilot projects.

4.1 Basic Attribute Syntaxes

   Every attribute type has a definition of the attribute syntaxes its
   values may be use. Most attribute types make use the basic attribute
   syntaxes only.










RARE Working Group on Network Applications Support (WG-NAP)    [Page 13]

RFC 1617      Naming and Structuring Guidelines for X.500       May 1994


4.1.1 Printable String

   This most simple syntax uses a subset of characters from ISO 646 IRV.

    A-Z   a-z   0-9   '     (     )     +

    ,     -     .     /     :     ?     space

    Tab 1: Characters in PrintableString

4.1.2 IA5 String - T.50

   The International Alphabet No. 5 (IA5) is known from the X.400
   message handling service. It covers a wider range of characters than
   the printable string. The international reference version of IA5
   offers the same set of characters as ISO 646 IRV.

4.1.3 Teletex String - T.61

   The Teletex character set is a very unusual one in the computing
   environment because it uses mixed one and two octet character codes
   which are more difficult to handle than single octet codes. Most of
   the characters can be mapped to the more often supported 8-bit
   character set standard ISO 8859-1 (ISO Latin-1).

4.1.4 Case Ignore String

   Many attributes use this case insensitive syntax. It allows attribute
   values to be represented using a mixture of upper and lower case
   letters, as appropriate. Matching of attribute values, however, is
   performed such that no significance is given to case.

4.1.5 Distinguished Name

   A Distinguished Name should currently never contain a value in T.61
   string syntax because most users would not be able to view or type it
   correctly by lack of appropriate hardware/software configuration.
   Therefore, only the characters defined in printable string syntax
   should be used as part of a RDN. The correct representation of the
   name should be added as additional attribute value to match for
   search operations.

4.2 Languages & Transliteration

   The standard as available has no support at all for the use of
   different languages in the Directory. It is e.g., not possible to add
   a language qualifier to a description attribute nor is it possible to
   use characters beyond the Teletex character set.



RARE Working Group on Network Applications Support (WG-NAP)    [Page 14]