rfc1781.txt

RFC 的详细文档！

Network Working Group                                           S. Kille
Request for Comments: 1781                              ISODE Consortium
Obsoletes: 1484                                               March 1995
Category: Standards Track


        Using the OSI Directory to Achieve User Friendly Naming

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) 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 standard
   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 [5], and it is intended that these
   specifications are compatible.

Table of Contents

   1.   Why a notation is needed ...................................   2
   2.   The Notation ...............................................   3
   3.   Communicating Directory Names ..............................   7
   4.   Matching a purported name ..................................   9
       4.1    Environment ..........................................   9
       4.2    Matching .............................................  10
       4.3    Top Level ............................................  12
       4.4    Intermediate Level ...................................  13
       4.5    Bottom Level .........................................  14
   5.   Examples ...................................................  14
   6.   Support required from the standard .........................  15



Kille                                                           [Page 1]

RFC 1781                  User Friendly Naming                March 1995


   7.   Support of OSI Services ....................................  15
   8.   Experience .................................................  16
   9.   Relationship to other work .................................  17
   10.  Issues .....................................................  19
   11.  References .................................................  20
   12.  Security Considerations ....................................  21
   13.  Author's Address ...........................................  21
   A.   Pseudo-code for the matching algorithm .....................  22
   List of Figures
       1.     Example usage of User Friendly Naming ................  18
       2.     Matching Algorithm ...................................  22
   List of Tables
       1.     Local environment for private DUA ....................  10
       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 [1].  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.

   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 [5] for representing
   distinguished names.  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.



Kille                                                           [Page 2]

RFC 1781                  User Friendly Naming                March 1995


   (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 [5].  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 [4].  Some examples of the specification are given
   here.  The author's User Friendly Name (UFN) might be written:

   Steve Kille, Computer Science, University College London, GB

   or

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

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

   Steve 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



Kille                                                           [Page 3]

RFC 1781                  User Friendly Naming                March 1995


   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:

   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:







Kille                                                           [Page 4]

RFC 1781                  User Friendly Naming                March 1995


   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.

    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.





Kille                                                           [Page 5]

RFC 1781                  User Friendly Naming                March 1995


   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.

   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,
   Widget Inc,
   GB

   Would match the distinguished name:

   CN=James Hacker,
   L=Basingstoke,
   O=Widget Inc,
   C=GB

   Abbreviation

   Some of the more significant components of the DN will be omitted,
   and then defaulted in some way (e.g., relative to a local context).
   For example:

   Steve Kille



Kille                                                           [Page 6]

RFC 1781                  User Friendly Naming                March 1995


   Could be interpreted in the context of an organisational default.

   Local Type Keywords

   Local values can be used to identify types, in addition to the
   keywords defined in [5].  For example, "Organisation" may be
   recognised as an alternative to "O".

   Component Omission

   An intermediate component of the name may be omitted.  Typically this
   will be an organisational unit.  For example:

   Steve Kille, University College London, GB

   In some cases, this can be combined with abbreviation.  For example:

   Steve Kille, University College London

   Approximation

   Approximate renditions or alternate values of one or
   more of the components will be supplied.  For example: