rfc1384.txt

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

Network Working Group                                          P. Barker
Requests for Comments 1384                     University College London
                                                   S.E. Hardcastle-Kille
                                                        ISODE Consortium
                                                            January 1993


                 Naming Guidelines for Directory Pilots

Status of this Memo

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

Abstract

   Deployment of a Directory will benefit from following certain
   guidelines.  This document defines a number of naming guidelines.
   Alignment to these guidelines is recommended for directory pilots.

1  Introduction

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

2  DIT structure

   The majority of this document is concerned with DIT structure and
   naming for organisations, organisational units and personal entries.
   This section briefly notes three other key issues.

2.1  The top level of the DIT

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

   Participating Countries
      The entries should contain suitable values of the "Friendly
      Country" attribute.

   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
      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



Barker & Hardcastle-Kille                                       [Page 1]

RFC 1384                   Naming Guidelines                January 1993


      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.  The only
      international organisation registered so far is:  Internet.  This
      is not a formal registration, but is adopted for the Internet
      Directory Service.

   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 benefits of additional top level
   registration outweighs these problems.  However, this potential
   problem should be noted by anyone making use of such a registration.

2.2  The DNS within the DIT

   The rules for the DNS parts of the DIT are defined in [3].  One
   modification to this is that the DNS tree will be rooted under
   "O=Internet", rather than at the root of the DIT.

2.3  Access control

   An entry's object class attribute, and any attribute(s) used for
   naming an entry are of special significance and may be considered to
   be "structural".  Any inability to access these attributes will often
   militate against successful querying of the Directory.  For example,
   user interfaces typically limit the scope of their searches by
   searching for entries of a particular type, where the type of entry
   is indicated by its object class.  Thus, unless the intention is to
   bar public access to an entry or set of entries, the object class and



Barker & Hardcastle-Kille                                       [Page 2]

RFC 1384                   Naming Guidelines                January 1993


   naming attributes should be publicly readable.

3  Naming Style

   The first goal of naming is to provide unique identifiers for
   entries.  Once this is achieve, 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 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.

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

3.1  National Guidelines

   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 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.2  Structure Rules

   A DIT structure is suggested in Annex B of X.521, and it is
   recommended that Directory Pilots should follow a slightly modified
   form of these guidelines.  The rules should be extended for handling
   DNS [3].  Some simple restrictions should be applied, as described
   below.

   For most countries pilots, 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.  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



Barker & Hardcastle-Kille                                       [Page 3]

RFC 1384                   Naming Guidelines                January 1993


   people and roles will be stored beneath organisations or
   organisational units.  An example plan evolving for the US is the
   work of the North American Directory Forum [2].

   As noted above, there will be a few exceptions to this basic
   structure.  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
   later.

3.3  Depth of tree

   The broad recommendation 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



Barker & Hardcastle-Kille                                       [Page 4]

RFC 1384                   Naming Guidelines                January 1993


   at all.  It is noted that there may be some problems with choice of
   unique RDNs when using a flat DIT structure.  Multiple value RDNs can
   alleviate this problem.  The standard recommends that an
   organizationalUnitName attribute can also be used as a naming
   attribute to disambiguate entries.  Further disambiguation may be
   achieved by the use of a personalTitle attribute in the RDN.

3.4  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 organisations such as
   Alcoholics Anonymous and American Airlines which 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:

   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



Barker & Hardcastle-Kille                                       [Page 5]

RFC 1384                   Naming Guidelines                January 1993


   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 names which are either memorable or
   guessable.  Minimising of typing may be achieved by use of carefully
   selected alternate values.

3.5  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.  It is proposed that pilots should
   ignore the standard's recommendations on storing personal titles, and
   letters indicating academic and professional qualifications within
   the commonName attribute, as this overloads the commonName attribute.
   A personalTitle attribute has already been specified in the COSINE
   and Internet Schema, and another attribute could be specified for
   information about qualifications.

   Furthermore, 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.  If such attributes have to be used to disambiguate entries,
   multi-valued RDNs should be used, such that other attribute(s) be
   used for naming in addition to a common name.

   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 Hardcastle-Kille is
   preferred as the RDN choice for one of this document's co-authors,
   while Stephen E. Hardcastle-Kille is stored as an alternative
   commonName value.  Sets of initials should not be concatenated into a
   single "word", but be separated by spaces and/or "." characters.
   Pragmatic choices will have to be made for other cultures.

3.6  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



Barker & Hardcastle-Kille                                       [Page 6]