rfc1484.txt

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

      Widget Inc,
      GB

   Would match the distinguished name:

      CN=James Hacker,
      L=Basingstoke,
      O=Widget Inc,
      CN=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 Hardcastle-Kille

   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 [HK93].  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 Hardcastle-Kille, University College London, GB

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

      Steve Hardcastle-Kille, University College London






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


   Approximation

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

      Stephen Hardcastle-Kille, CS, UCL, GB

   or

      Steve Keill, Comp Sci, Univarstiy College London, GB

   Friendly Country

   A "friendly country name" can be used instead of the ISO 3166 two
   letter code.  For example:

      UK; USA; France; Deutchland.

3.  Communicating Directory Names

   A goal of this standard is to provide a means of communicating
   directory names.  Two approaches are given, one defined in [HK93],
   and the other here.  A future version of these specifications may
   contain only one of these approaches, or recommend use of one
   approach.  The approach can usually be distinguished implicitly, as
   types are normally omitted in the UFN approach, and are always
   present in the Distinguished Name approach.  No recommendation is
   made here, but the merits of each approach is given.

      1. Distinguished Name or DN. A representation of the distinguished
         name, according to the specification of [HK93].

      2. User Friendly Name or UFN. A purported name, which is expected
         to unambiguously resolve onto the distinguished name.

   When a UFN is communicated, a form which should efficiently and
   unambiguously resolve onto a distinguished name should be chosen.
   Thus it is reasonable to omit types, or to use alternate values which
   will unambiguously identify the entry in question (e.g., by use of an
   alternate value of the RDN attribute type).  It is not reasonable to
   use keys which are (or are likely to become) ambiguous.

   The approach used should be implicit from the context, rather than
   wired into the syntax.  The terms "Directory Name" and "X.500 Name"
   should be used to refer to a name which might be either a DN or UFN.
   An example of appropriate usage of both forms is given in the Section
   which defines the Author's location in section 12.




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


   Advantages of communicating the DN are:

      o The Distinguished Name is an unambiguous and stable reference to
        the user.

      o The DN will be used efficiently by the directory to obtain
        information.

   Advantages of communicating the UFN are:

      o Redundant type information can be omitted (e.g., "California",
        rather than "State=California", where there is known to be no
        ambiguity.

      o Alternate values can be used to identify a component.  This might
        be used to select a value which is meaningful to the recipient, or
        to use a shorter form of the name.  Often the uniqueness
        requirements of registration will lead to long names, which users
        will wish to avoid.

      o Levels of the hierarchy may be omitted.  For example in a very
        small organisation, where a level of hierarchy has been used to
        represent company structure, and the person has a unique name
        within the organisation.

   Where UFN form is used, it is important to specify an unambiguous
   form.  In some ways, this is analogous to writing a postal address.
   There are many legal ways to write it.  Care needs to be taken to
   make the address unambiguous.

4.  Matching a purported name

   The following approach specifies a default algorithm to be used with
   the User Friendly Naming approach.  It is appropriate to modify this
   algorithm, and future specifications may propose alternative
   algorithms.  Two simple algorithms are noted in passing, which may be
   useful in some contexts:

      1. Use type omission only, but otherwise require the value of the
         RDN attribute to be present.

      2. Require each RDN to be identified as in 1), or by an exact
         match on an alternate value of the RDN attribute.

   These algorithms do not offer the flexibility of the default
   algorithm proposed, but give many of the benefits of the approach in
   a very simple manner.




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


   The major utility of the purported name is to provide the important
   "user friendly" characteristic of guessability.  A user will supply a
   purported name to a user interface, and this will be resolved onto a
   distinguished name.  When a user supplies a purported name there is a
   need to derive the DN. In most cases, it should be possible to derive
   a single name from the purported name.  In some cases, ambiguities
   will arise and the user will be prompted to select from a multiple
   matches.  This should also be the case where a component of the name
   did not "match very well".

   There is an assumption that the user will simply enter the name
   correctly.  The purported name variants are designed to make this
   happen!  There is no need for fancy window based interfaces or form
   filling for many applications of the directory.  Note that the fancy
   interfaces still have a role for browsing, and for more complex
   matching.  This type of naming is to deal with cases where
   information on a known user is desired and keyed on the user's name.

4.1  Environment

   All matches occur in the context of a local environment.  The local
   environment defines a sequence of name of a non-leaf objects in the
   DIT. This environment effectively defines a list of acceptable name
   abbreviations where the DUA is employed.  The environment should be
   controllable by the individual user.  It also defines an order in
   which to operate.

   This list is defined in the context of the number of name components
   supplied.  This allows varying heuristics, depending on the
   environment, to make the approach have the "right" behaviour.

   In most cases, the environment will start at a local point in the
   DIT, and move upwards.  Examples are given in Tables 1 and 2.  Table
   1 shows an example for a typical local DUA, which has the following
   characteristics:

   One component

   Assumed first to be a user in the department, then a user or
   department within the university, the a national organisation, and
   finally a country.

   Two components

   Most significant component is first assumed to be a national
   organisation, then a department (this might be reversed in some
   organisations), and finally a country.




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


   Three or more components

   The most significant component is first assumed to be a country, then
   a national organisation, and finally a department.

           +----------------------------------------------------+
           | Number of  |  Environment                          |
           | Components |                                       |
           +----------------------------------------------------+
           | 1          | Physics, University College London, GB|
           |            | University College London, GB         |
           |            | GB                                    |
           |            | __                                    |
           +----------------------------------------------------+
           | 2          | GB                                    |
           |            | University College London, GB         |
           |            | __                                    |
           +----------------------------------------------------+
           | 3+         | __                                    |
           |            | GB                                    |
           |            | University College London, GB         |
           +----------------------------------------------------+

                Table 1:  Local environment for private DUA

                 +--------------------------------------+
                 | Number of  | Environment             |
                 | Components |                         |
                 +--------------------------------------+
                 | 1,2        | US                      |
                 |            | CA                      |
                 |            | __                      |
                 +--------------------------------------+
                 | 3+         | __                      |
                 |            | US                      |
                 |            | CA                      |
                 +--------------------------------------+

               Table 2:  Local environment for US Public DUA












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


4.2  Matching

   A purported name will be supplied, usually with a small number of
   components.  This will be matched in the context of an environment.
   Where there are multiple components to be matched, these should be
   matched sequentially.  If an unambiguous DN is determined, the match
   continues as if the full DN had been supplied.  For example if

      Stephen Hardcastle-Kille, UCL

   is being matched in the context of environment GB, first UCL is
   resolved to the distinguished name:

      University College London, GB

   Then the next component of the purported name is taken to determine
   the final name.  If there is an ambiguity (e.g., if UCL had made two
   matches, both paths are explored to see if the ambiguity can be
   resolved.  Eventually a set of names will be passed back to the user.

   Each component of the environment is taken in turn.  If the purported
   name has more components than the maximum depth, the environment
   element is skipped.  The advantage of this will be seen in the
   example given later.

   A match of a name is considered to have three levels:

   Exact

   A DN is specified exactly

   Good

   Initially, a match should be considered good if it is unambiguous,
   and exactly matches an attribute value in the entry.  For human
   names, a looser metric is probably desirable (e.g., S Hardcastle-
   Kille should be a good match of S. Hardcastle-Kille, S.E.
   Hardcastle-Kille or Steve Hardcastle-Kille even if these are not
   explicit alternate values).

   Poor

   Any other substring or approximate match

   Following a match, the reference can be followed, or the user
   prompted.  If there are multiple matches, more than one path may be
   followed.  There is also a shift/reduce type of choice:  should any
   partial matches be followed or should the next element of the



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


   environment be tried.  The following heuristics are suggested, which
   may be modified in the light of experience.  The overall aim is to
   resolve cleanly specified names with a minimum of fuss, but give
   sufficient user control to prevent undue searching and delay.

      1. Always follow an exact match.

      2. Follow all good matches if there are no exact matches.

      3. If there are only poor matches, prompt the user.  If the user
         accepts one or more match, they can be considered as good.
         If all are rejected, this can be treated as no matches.

      4. Automatically move to the next element of the environment if no
         matches are found.

   When the final component is matched, a set of names will be
   identified.  If none are identified, proceed to the next environment
   element.  If the user rejects all of the names, processing of the
   next environment element should be confirmed.

   The exact approach to matching will depend on the level of the tree
   at which matching is being done.  We can now consider how attributes
   are matched at various levels of the DIT.