rfc1484.txt

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

Network Working Group                               S. Hardcastle-Kille
Request for Comments: 1484                             ISODE Consortium
                                                              July 1993


                   Using the OSI Directory to achieve
                          User Friendly Naming
                           (OSI-DS 24 (v1.2))

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard.  Discussion and
   suggestions for improvement are requested.  Please refer to the
   current edition of the "IAB Official Protocol Standards" for the
   standardization state and status of this protocol.  Distribution of
   this memo is unlimited.

Abstract

   The OSI Directory has user friendly naming as a goal.  A simple
   minded usage of the directory does not achieve this.  Two aspects not
   achieved are:

      o A user oriented notation

      o Guessability

   This proposal sets out some conventions for representing names in a
   friendly manner, and shows how this can be used to achieve really
   friendly naming.  This then leads to a specification of a format for
   representing names, and to procedures to resolve them.  This leads to
   a specification which allows directory names to be communicated
   between humans.  The format in this specification is identical to
   that defined in [HK93], and it is intended that these specifications
   are compatible.  Please send comments to the author or to the
   discussion group: <[e-mail]>.














Hardcastle-Kille                                                [Page 1]

RFC 1484                  User Friendly Naming                 July 1993


Table of Contents

   1.  Why a notation is needed......................................  2
   2.  The Notation..................................................  3
   3.  Communicating Directory Names.................................  8
   4.  Matching a purported name.....................................  9
   4.1 Environment................................................... 10
   4.2 Matching...................................................... 12
   4.3 Top Level..................................................... 13
   4.4 Intermediate Level............................................ 14
   4.5 Bottom Level.................................................. 15
   5.  Examples...................................................... 15
   6.  Support required from the standard............................ 16
   7.  Support of OSI Services....................................... 16
   8.  Experience.................................................... 17
   9.  Relationship to other work.................................... 18
   10. Issues........................................................ 19
   11. References.................................................... 20
   12. Security Considerations....................................... 21
   13. Author's Address.............................................. 21
   A.  Pseudo-code for the matching algorithm ....................... 21

List of Figures

   1. Example usage of User Friendly Naming.......................... 18
   2. Matching Algorithm............................................. 25

List of Tables

   1. Local environment for private DUA.............................. 11
   2. Local environment for US Public DUA............................ 11

1.  Why a notation is needed

   Many OSI Applications make use of Distinguished Names (DN) as defined
   in the OSI Directory [CCI88].  The main reason for having a notation
   for name format is to interact with a user interface.  This
   specification is coming dangerously close to the sin of standardising
   interfaces.  However, there are aspects of presentation which it is
   desirable to standardise.

   It is important to have a common format to be able to conveniently
   refer to names.  This might be done to represent a directory name on
   a business card or in an email message.  There is a need for a format
   to support human to human communication, which must be string based
   (not ASN.1) and user oriented.





Hardcastle-Kille                                                [Page 2]

RFC 1484                  User Friendly Naming                 July 1993


   In very many cases, a user will be required to input a name.  This
   notation is designed to allow this to happen in a uniform manner
   across many user interfaces.  The intention is that the name can just
   be typed in.  There should not be any need to engage in form filling
   or complex dialogue.

   It should be possible to take the "human" description given at the
   meeting, and use it directly.  The means in which this happens will
   become clear later.

   This approach uses the syntax defined in RFC1485 for representing
   distinguished names [HK93].  By relaxing some of the constraints on
   this specification, it is argued that a more user oriented
   specification is produced.  However, this syntax cannot be mapped
   algorithmically onto a distinguished name without the use of a
   directory.

   This notation is targeted towards a general user oriented system, and
   in particular to represent the names of humans.  Other syntaxes may
   be more appropriate for other uses of the directory.  For example,
   the OSF Syntax may be more appropriate for some system oriented uses.
   (The OSF Syntax uses "/" as a separator, and forms names in a manner
   intended to resemble UNIX filenames).

   This notation is targeted towards names which follow a particular DIT
   structure: organisationally oriented.  This may make it inappropriate
   for some types of application.  There may be a requirement to extend
   this notation to deal more cleanly with fully geographical names.

   This approach effectively defines a definition of descriptive names
   on top of the primitive names defined by the OSI Directory.

2.  The Notation

   The notation used in this specification is defined in [HK93].  This
   notation defines an unambiguous representation of distinguished name,
   and this specification is designed to be used in conjunction with
   this format.  Both specifications arise from the same piece of
   research work [Kil90].  Some examples of the specification are given
   here.

   The author's User Friendly Name (UFN) might be written:

      Steve Hardcastle-Kille, Computer Science, University College
      London, GB

   or




Hardcastle-Kille                                                [Page 3]

RFC 1484                  User Friendly Naming                 July 1993


      S. Hardcastle-Kille, Computer Science, University College London,
      GB

   This may be folded, perhaps to display in multi-column format. For
   example:

      Steve Hardcastle-Kille,
      Computer Science,
      University College London,
      GB

   Another UFN might be:

      Christian Huitema, INRIA, FR

   or

      James Hacker,
      Basingstoke,
      Widget Inc,
      GB

   The final example shows quoting of a comma in an Organisation name:

      L. Eagle, "Sue, Grabbit and Runn", GB

   A purported name is what a user supplies to an interface for
   resolution into one or more distinguished names.  A system should
   almost always store a name as a distinguished name.  This will be
   more efficient, and avoid problems with purported names which become
   ambiguous when a new name appears.  A user interface may display a
   distinguished name, using the distinguished name notation.  However,
   it may display a purported name in cases where this will be more
   pleasing to the user.  Examples of this might be:

     o  Omission of the higher components of the distinguished name are
        not displayed (abbreviation).

     o  Omission of attribute types, where the type is unlikely to be
        needed to resolve ambiguity.

   The ways in which a purported name may vary from a distinguished name
   are now described:








Hardcastle-Kille                                                [Page 4]

RFC 1484                  User Friendly Naming                 July 1993


   Type Omission

   There are two cases of this.

     o  Schema defaulting.  In this case, although the type is not
        present, a schema defaulting is used to deduce the type.  The
        first two types of schema defaulting may be used to deduce a
        distinguished name without the use of the directory.  The use
        of schema defaulting may be useful to improve the performance
        of UFN resolution.  The types of schema defaulting are:

         --  Default Schema

         --  Context Dependent Default Schema

         --  Data Dependent Default Schema

     o  Omission of the type to be resolved by searching.

   Default Schema

   The attribute type of an attribute may always be present.  This may
   be done to emphasise the type structure of a name.  In some cases,
   the typing may be omitted.  This is done in a way so that in many
   common cases, no attribute types are needed.  The following type
   hierarchy (schema) is assumed:

      Common Name, (((Organisational Unit)*,  Organisation,) Country)

   Explicitly typed RDNs may be inserted into this hierarchy at any
   point.  The least significant component is always of type Common
   Name.  Other types follow the defined organisational hierarchy.  The
   following are equivalent:

      Filestore Access, Bells, Computer Science,
      University College London, GB

   and

      CN=Filestore Access, OU=Bells, OU=Computer Science,
      O=University College London, C=GB

   To interpet a distinguished name presented in this format, with some
   or all of the attributes with the type not specified, the types are
   derived according to the type hierarchy by the following algorithm:

      1.  If the first attribute type is not specified, it is
          CommonName.



Hardcastle-Kille                                                [Page 5]

RFC 1484                  User Friendly Naming                 July 1993


      2.  If the last attribute type is not specified, it is Country.

      3.  If there is no organisation explicitly specified, the last
          attribute with type not specified is of type Organisation.

      4.  Any remaining attribute with type unspecified must be before
          an Organisation or OrganisationalUnit attribute, and is of
          type OrganisationalUnit.

   To take a distinguished name, and generate a name of this format with
   attribute types omitted, the following steps are followed.

      1. If the first attribute is of type CommonName, the type may be
         omitted.

      2. If the last attribute is of type Country, the type may be
         omitted.

      3. If the last attribute is of type Country, the last Organisation
         attribute may have the type omitted.

      4. All attributes of type OrganisationalUnit may have the type
         omitted, unless they are after an Organisation attribute or
         the first attribute is of type OrganisationalUnit.

   Context Dependent Default Schema

   The distinguished name notation defines a fixed schema for type
   defaulting.  It may be useful to have different defaults in different
   contexts.  For example, the defaulting convention may be applied in a
   modified fashion to objects which are known not to be common name
   objects.  This will always be followed if the least significant
   component is explicitly typed.  In this case, the following hierarchy
   is followed:

             ((Organisational Unit)*,  Organisation,) Country

   Data Dependent Defaulting

   There are cases where it would be optimal to default according to the
   data.  For example, in:

      Einar Stefferud, Network Management Associates, CA, US

   It would be useful to default "CA" to type State.  This might be done
   by defaulting all two letter attributes under C=US to type State.





Hardcastle-Kille                                                [Page 6]

RFC 1484                  User Friendly Naming                 July 1993


   General Defaulting

   A type may be omitted in cases where it does not follow a default
   schema hierarchy, and then type variants can be explored by
   searching.  Thus a distinguished name could be represented by a
   uniquely matching purported name.  For example,

      James Hacker,
      Basingstoke,