rfc1617.txt

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

Network Working Group                                          P. Barker
Request for Comments: 1617                     University College London
RARE Technical Report: 11                                       S. Kille
Obsoletes: 1384                                         ISODE Consortium
Category: Informational                                  T. Lenggenhager
                                                                  SWITCH
                                                                May 1994


      Naming and Structuring Guidelines for X.500 Directory Pilots

Status of this Memo

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

Abstract

   Deployment of a Directory will benefit from following certain
   guidelines. This document defines a number of naming and structuring
   guidelines focused on White Pages usage. Alignment to these
   guidelines is recommended for directory pilots. The final version of
   this document will replace RFC 1384.

Table of Contents

    1. Introduction                                                2
    2. DIT Structure                                               3
    2.1. Structure Rules                                           3
    2.2. The Top Level of the DIT                                  3
    2.3. Countries                                                 4
    2.4. Organisations                                             5
    2.4.1. Directory Manager, Postmaster & Secretary               5
    2.4.2. Depth of tree                                           6
    2.4.3. Real World Organisational Structure                     7
    2.5. Multi-National Organisations                              7
    2.5.1. The Multi-National as a Single Entity                   7
    2.5.2. The Multi-National as a Loose Confederation             8
    2.5.3. Loosely Linked DIT Sub-Trees                            9
    2.5.4. Summary of Advantages and Disadvantages of the
           Above Approaches                                        9
    3. Naming Style                                               10
    3.1. Multi-Component Relative Distinguished Names             11
    3.2. National Guidelines for Naming                           11
    3.3. Naming Organisation and Organisational Unit Names        11
    3.4. Naming Human Users                                       12
    3.5. Application Entities                                     13



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


    4. Attribute Values                                           13
    4.1. Basic Attribute Syntaxes                                 13
    4.1.1. Printable String                                       14
    4.1.2. IA5 String - T.50                                      14
    4.1.3. Teletex String - T.61                                  14
    4.1.4. Case Ignore String                                     14
    4.1.5. Distinguished Name                                     14
    4.2. Languages & Transliteration                              14
    4.2.1. Languages other than English                           15
    4.2.2. Transliteration                                        15
    4.3. Access control                                           15
    4.4. Selected Attributes                                      16
    4.4.1. Personal Attributes                                    16
    4.4.2. Organisational Attributes                              18
    4.4.3. Local Attributes                                       19
    4.4.4. Miscellaneous Attributes                               20
    4.4.5. MHS Attributes                                         21
    4.4.6. Postal Attributes                                      21
    4.4.7. Telecom Attributes                                     22
    5. Miscellany                                                 22
    5.1. Schema consistency of aliases                            22
    5.2. Organisational Units                                     23
    6. References                                                 23
    7. Security Considerations                                    23
    8. Authors' Addresses                                         24
    9. Appendix - Example Entries                                 25

1. Introduction

   The intended audience for this document are mainly data managers
   using X.500 Directory Services. With the help of these guidelines it
   should be easier for them to define the structure for the part of the
   Directory Information Tree they want to model, e.g., the
   representation of their organisation in the Directory. In addition,
   decisions like which data elements to store for each kind of entry
   shall be supported.

   These guidelines concentrate mainly on the White Pages use of the
   Directory, the X.500 application with most operational experience
   today, nonetheless many recommendations are also valid for other
   applications of the Directory.

   As a pre-requisite to this document, it is assumed that the COSINE
   and Internet X.500 Schema is followed [1].







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


2. DIT Structure

   The majority of this document is concerned with DIT structure, naming
   and the usage of attributes for organisations, organisational units
   and personal entries.

   This section briefly notes five other key issues.

2.1 Structure Rules

   A DIT structure is suggested in Annex B of X.521 [2], and it is
   recommended that Directory Pilots for White Pages services should
   follow these guidelines. Some simple restrictions should be applied,
   as described below. For further usage of the Directory like e-mail
   routing with the Directory or storage of network information in the
   Directory it will be necessary to follow the guidelines specified in
   the respective documents.

   One of the few exceptions to the basic DIT structure is, that
   international organisations will be stored immediately under the root
   of the tree. Multi-national organisations will be stored within the
   framework outlined, but with some use of aliases and attributes such
   as seeAlso to help bind together the constituent parts of these
   organisations. This is discussed in more detail in section 2.5.

   A general rule for the depth of a subtree is as follows: When a
   subtree is mainly accessed via searching, it should be as flat as
   possible to improve the performance, when the access will be mainly
   through read operations, the depth of the subtree is not a
   significant parameter for performance.

2.2 The Top Level of the DIT

   The following information will be present at the top level of the
   DIT:

   Participating Countries

      According to the standard the RDN is the ISO 3166 country code. In
      addition, the entries should contain suitable values of the
      friendlyCountryName attribute specified in RFC 1274. Use of this
      attribute is described in more detail in section 4.4.4.

   International Organisations

      An international organisation is an organisation, such as the
      United Nations, which inherently has a brief and scope covering
      many nations.  Such organisations might be considered to be



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


      supra-national and this, indeed, is the raison-d'etre of such
      organisations. Such organisations will almost all be governmental
      or quasi-governmental. A multi-national organisation is an
      organisation which operates in more than one country, but is not
      supra-national. This classification includes the large commercial
      organisations whose production and sales are spread throughout a
      large number of countries.

      International organisations may be registered at the top level.
      This will not be done for multi-national organisations. Currently
      three organisations are registered so far: Inmarsat, Internet and
      North Atlantic Treaty Organization.

   Localities

      A few localities will be registered under the root. The chief
      purpose of these locality entries is to provide a "natural" parent
      node for organisations which are supra-national, and yet which do
      not have global authority in their particular field. Such
      organisations will usually be governmental or quasi-governmental.
      Example localities might include: Europe, Africa, West Indies.
      Example organisations within Europe might include: European Court
      of Justice, European Space Agency, European Commission.

   DSA Information

      Some information on DSAs may be needed at the top level.  This
      should be kept to a minimum.

   The only directory information for which there is a recognised top
   level registration authority is countries. Registration of other
   information at the top level may potentially cause problems. At this
   stage, it is argued that the benefit of limiting additional top level
   registrations outweighs these problems. However, this potential
   problem should be noted by anyone making use of such a registration.

2.3 Countries

   The national standardisation bodies will define national guidelines
   for the structure of the national part of the DIT. In the interim,
   the following simple structure should suffice. The country entry will
   appear immediately beneath the root of the tree. Organisations which
   have national significance should have entries immediately beneath
   their respective country entries. Smaller organisations which are
   only known in a particular locality should be placed underneath
   locality entries representing states or similar geographical
   divisions. Entry for private persons will be listed under the
   locality entries. An example plan evolving for the US is the work of



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


   the North American Directory Forum [3]. Another example is the
   organisation of the X.500 namespace as standardized in Australia [4].

2.4 Organisations

   Large organisations will probably need to be sub-divided by
   organisational units to help in the disambiguation of entries for
   people with common names. Entries for people and roles will be stored
   beneath organisations or organisational units.

   The organisation entry itself shall contain the information necessary
   to contact the organisation: for example, postal address, telephone
   and fax numbers.

   Although the structure of organisations often changes considerably
   over time, the aim should be to minimise the number of changes to the
   DIT. Note that renaming a superior, department entry has the effect
   of changing the DN of all subordinate entries. This has an
   undesirable impact on the service for several reasons. Alias entries
   and certain attributes or ordinary entries such as seeAlso, secretary
   and roleOccupant use DNs to maintain links with other entries. These
   references are one-way only and the Directory standard offers no
   support to automatically update all references to an entry once its
   DN changes.

2.4.1 Directory Manager, Postmaster & Secretary

   Similar to messaging, where every domain has its postmaster address
   it is highly recommended that each organisation in the X.500
   Directory has two entries: Postmaster and Directory Manager. In
   addition, Secretary entries for an organisation and its units should
   be listed. If this guidance is followed, users will benefit because
   it will be straightforward to find the right contacts for questions
   or problems with the service.

   These entries should use the object class organizationalRole with the
   roleOccupant attributes containing the distinguished names of the
   persons in charge of this role. The values

      CN=Directory Manager

      CN=Postmaster

      CN=Secretary

   should be added as additional values whenever another language than
   English is used for the name of the entries.




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


2.4.2 Depth of tree

   The broad recommendation for White Pages is that the DIT should be as
   flat as possible. A flat tree means that Directory names will be
   relatively short, and probably somewhat similar in length and
   component structure to paper mail addresses. A deep DIT would imply
   long Directory names, with somewhat arbitrary component parts, with a
   result which it is argued seems less natural. Any artificiality in
   the choice of names militates against successful querying.

   A presumption behind this style of naming is that most querying will
   be supported by the user specifying convenient strings of characters
   which will be mapped onto powerful search operations.  The
   alternative approach of the user browsing their way down the tree and
   selecting names from large numbers of possibilities may be more
   appropriate in some cases, and a deeper tree facilitates this.
   However, these guidelines recommend a shallow tree, and implicitly a
   search oriented approach.

   It may be considered that there are two determinants of DIT depth:
   first, how far down the DIT an organisation is placed; second, the
   structure of the DIT within organisations.

   The structure of the upper levels of the tree will be determined in
   due course by various registration authorities, and the pilot will
   have to work within the given structure. However, it is important
   that the various pilots are cognisant of what the structures are
   likely to be, and move early to adopt these structures.

   The other principal determinant of DIT depth is whether an
   organisation splits its entries over a number of organisational
   units, and if so, the number of levels. The recommendation here is
   that this sub-division of organisations is kept to a minimum. A
   maximum of two levels of organisational unit should suffice even for
   large organisations. Organisations with only a few tens or hundreds
   of employees should strongly consider not using organisational units
   at all. It is noted that there may be some problems with choice of
   unique RDNs when using a flat DIT structure. Multi-component RDNs can
   alleviate this problem: see section 3.1. The standard X.521
   recommends that an organizationalUnitName attribute can also be used
   as a naming attribute to disambiguate entries [2]. Further
   disambiguation may be achieved by the use of a personalTitle or
   userId attribute in the RDN.








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


2.4.3 Real World Organisational Structure

   Another aspect on designing the DIT structure for an organisation is
   the administrative structure within a company. Using the same
   structure in the DIT might help in distributing maintenance authority
   to the different units. Please note comments on the stability of the
   DIT structure in section 2.4.

2.5 Multi-National Organisations

   The standard says that only international organisations may be placed
   under the root of the DIT. This implies that multi-national
   organisations must be represented as a number of separate entries
   underneath country or locality entries. This structure makes it more
   awkward to use X.500 within a multi-national to provide an internal
   organisational directory, as the data is now spread widely throughout
   the DIT, rather than all being grouped within a single sub-tree.

   Many people have expressed the view that this restriction is a severe
   limitation of X.500, and argue that the intentions of the standard
   should be ignored in this respect. This note argues, though, that the
   standard should be followed.

   No attempt to precisely define multinational organisation is essayed
   here. Instead, the observation is made that the term is applied to a
   variety of organisational structures, where an organisation operates
   in more than one country. This suggests that a variety of DIT
   structures may be appropriate to accommodate these different
   organisational structures. This document suggests three approaches,
   and notes some of the characteristics associated with each of these
   approaches.

   Before considering the approaches, it is worth bearing in mind again
   that a major aim in the choice of a DIT structure is to facilitate
   querying, and that approaches which militate against this should be
   avoided wherever possible.

2.5.1 The Multi-National as a Single Entity

   In many cases, a multi-national organisation will operate with a
   highly centralised structure. While the organisation may have large
   operations in a number of countries, the organisation is strongly
   controlled from the centre and the disparate parts of the
   organisation exist only as limbs of the main organisation. In such a
   situation, the model shown in figure 1 may be the best choice.