rfc1781.txt

中、英文RFC文档大全打包下载完全版 .

   Stephen 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 [5], 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.






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


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

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





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


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.

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



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


   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, then 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.

   Three or more components

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

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

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



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


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

            Table 2:  Local environment for US Public DUA

   Stephen 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 Kille should be a good match of S. Kille, S.E. Kille or Steve
       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



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


   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 matches, 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.

   There is an issue of approximate matching.  Sometimes it helps, and
   sometimes just returns many spurious matches.  When a search is
   requested, all relevant attributes should be returned, so that
   distinguished and non-distinguished values can be looked at.  This
   will allow a distinction to be made between good and poor matches.
   It is important that where, for example, an acronym exactly matches
   an organisation, that the user is not prompted about other
   organisations where it matches as a substring.

4.3  Top Level

   In this case, a match is being done at the root of the DIT. Three
   approaches are suggested, dependent on the length of supplied name.
   All lead to a single level search of the top level of the DIT.

   Exactly 2

   This is assumed to be a 3166 two letter country code, or an exact
   match on a friendly country or organisation (e.g., UK or UN). Do
   exact match on country and friendly country.






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


   Greater than 2

   Make an approximate and substring match on friendly country and
   organisation.

4.4  Intermediate Level

   Once the root level has been dealt with, intermediate levels will be
   looking for organisational components (Organisation, Locality, Org
   Unit).  In some cases, private schema control will allow the system
   to determine which is at the next level.  In general this will not be
   possible.  In each case, make a substring and approximate match
   search of one level.  The choice depends on the base object used in
   the search.

   1.  If DN has no Organisation or Locality, filter on Organisation and
       Locality.

   2.  If DN has Org Unit, filter on Org Unit.

   3.  If DN has Organisation, filter on Locality and Org Unit.

   4.  If DN has Locality, filter on Organisation.

   These allow some optimisation, based on legal choices of schema.
   Keeping filters short is usually desirable to improve performance.  A
   few examples of this, where a base object has been determined (either
   by being the environment or by partial resolution of a purported
   name), and the next element of a purported name is being considered.
   This will generate a single level search.  What varies is the types
   being filtered against.  If the DN is:

   University College London, GB

   The search should be for Org Unit or Locality.  If the DN is:

   Organisation=UN

   the search should be for Org Unit or Locality.

   There may be some improvements with respect to very short keys.  Not
   making approximate or substring matches in these cases seems sensible
   (It might be desirable to allow "*" as a part of the purported name
   notation.)







Kille                                                          [Page 13]