rfc1484.txt

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

   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.






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


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






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


4.5  Bottom Level

   The "Bottom Level" is to deal with leaf entries in the DIT. This will
   often be a person, but may also be a role, an application entity or
   something else.

   The last component of a purported name may either reference a leaf or
   non-leaf.  For this reason, both should be tested for.  As a
   heuristic, if the base object for the search has two or more
   components it should be tested first as a bottom level name and then
   intermediate.  Reverse this for shorter names.  This optimises for
   the (normal) case of non-leaves high up the tree and leaves low down
   the tree.

   For bottom level names, make an approximate and substring match
   against Common Name, Surname, and User ID. Where common name is
   looked for, a full subtree search will be used when at the second
   level of the DIT or lower, otherwise a single level search.

   For example, if I have resolved a purported name to the distinguished
   name

      University College London, GB

   and have a single component Bloggs, this will generate a subtree
   search.

5.  Examples

   This is all somewhat confusing, and a few examples are given.  These
   are all in the context of the environment shown in Table 1 in section
   4.1.

   If "Joe Bloggs" is supplied, a subtree search of

      Physics, University College London, GB

   will be made, and the user prompted for "Joseph Z. Bloggs" as the
   only possible match.

   If "Computer Science" is supplied, first

      Physics, University College London, GB

   will be searched, and the user will reject the approximate match of
   "Colin Skin".  Then a subtree search of

      University College London, GB



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


   will be made, looking for a person.  Then a single level search will
   be made looking for Org Unit, and

      Computer Science, University College London, GB

   will be returned without prompting (exact match).  Supplying "Steve
   Hardcastle-Kille" will lead to a failed subtree search of

      Physics, University College London, GB

   and lead straight to a subtree search of

      University College London, GB

   This will lead to an exact value match, and so a single entry
   returned without prompting.

   If "Andrew Findlay, Brunel" is supplied, the first element of the
   environment will be skipped, single level search of "Brunel" under
   "GB" will find:

      Brunel University, GB

   and a subtree search for "Andrew Findlay" initiated.  This will yield

      Andrew Findlay, Computing and Media Services, Brunel University,
      GB

      Dr A J Findlay, Manufacturing and Engineering Systems, Brunel
      University, GB

   and the user will be prompted with a choice.

   This approach shows how a simple format of this nature will "do the
   right thing" in many cases.

6.  Support required from the standard

   Fortunately, all that is needed is there!  It would be useful to have
   "friendly country name" as a standard attribute.

7.  Support of OSI Services

   The major focus of this work has been to provide a mechanism for
   identifying Organisations and Users.  A related function is to
   identify applications.  Where the Application is identified by an AET
   (Application Entity Title) with an RDN of Common Name, this
   specification leads to a natural usage.  For example, if a filestore



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


   in named "gannet", then this could easily be identified by the name:

      Gannet, Computer Laboratory, Cambridge University, GB

   In normal usage, this might lead to access (using a purported name)
   of:

      FTAM gannet,cambridge

   A second type of access is where the user identifies an Organisation
   (Organisational Unit), and expects to obtain a default service.  The
   service is implied by the application, and should not require any
   additional naming as far as the user is concerned.  It is proposed
   that this is supported by User Friendly Naming in the following way.


      1. Determine that the purported name identifies a non-leaf
         object, which is of object class Organisation or Organisational
         Unit or Locality.

      2. Perform a single level search for Application Entities which
         support the required application contexts.  This assumes that
         all services which are supporting default access for the
         organisation are registered at one level below (possibly by the
         use of aliases), and that other services (specific machines or
         parts of the organisation) are represented further down the
         tree. This seems to be a reasonable layout, and its utility can
         be evaluated by experiment.

8. Experience

   An experimental implementation of this has been written by Colin
   Robbins.  The example in Figure 1 shows that it can be very effective
   at locating known individuals with a minimum of effort.  This code
   has been deployed within the "FRED" interface of the PSI Pilot
   [Ros90], and within an prototype interface for managing distribution
   lists.  The user reaction has been favourable.

   Some issues have arisen from this experience:

     o Where there is more than one level of Organisational Unit, and
       the user guesses one which is not immediately below the
       organisation, the algorithm works badly.  There does not appear
       to be an easy fix for this.  It is not clear if this is a serious
       deficiency.

     o Substring searching is currently done with leading and trailing
       wildcards.  As many implementations will not implement leading



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


       wildcards efficiently, it may be preferable to only use trailing
       wildcards.  The effect of this on the algorithm needs to be
       investigated.

   Implementors of this specification are encouraged to investigate
   variants of the basic algorithm.  A final specification should depend
   on experience with such variants.

      -> t hales, csiro, australia
      Found good match(es) for 'australia'
      Found exact match(es) for 'csiro'
      Please select from the following:
         Trevor Hales, OC, HPCC, DIT, IICT, CSIRO, AU [y/n] ? y
      The following were matched...
         Trevor Hales, OC, HPCC, DIT, IICT, CSIRO, AU

      -> g michaelson, queensland, au
      Found exact match(es) for 'au'
      Please select from the following:
         University of Queensland, AU [y/n] ? y
         Axolotl, AU [y/n] ? n
      Please select from the following:
         George Michaelson, Prentice Computer Centre, University of
      Queensland, AU [y/n] ? y
         Manager, University of Queensland, AU [y/n] ? n
      The following were matched...
         George Michaelson, Prentice Computer Centre, University of
       Queensland, AU

      -> r needham, cambridge
      Found good match(es) for 'cambridge'
      Please select from the following:
         Roger Needham, Computer Lab, Cambridge University [y/n] ? y
      The following were matched...
         Roger Needham, Computer Lab, Cambridge University

      -> kirstein
      Found good match(es) for 'kirstein'
      The following were matched...
         Peter Kirstein

               Figure 1:  Example usage of User Friendly Naming

9. Relationship to other work

   Colin Robbin's work on the interface "Tom" and implementation of a
   distribution list interface strongly influenced this specification
   [KRRT90].



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


   Some of the ideas used here originally came from a UK Proposal to the
   ISO/CCITT Directory Group on "New Name Forms" [Kil89a].  This
   defined, and showed how to implement, four different types of names:

   Typed and Ordered

   The current Distinguished Name is a restricted example of this type
   of name.

   Untyped and Ordered

   This is the type of name proposed here (with some extensions to allow
   optional typing).  It is seen as meeting the key user requirement of
   disliking typed names, and is efficient to implement.

   Typed and Unordered

   This sort of name is proposed by others as the key basis for user
   friendly naming.  Neufeld shows how X.500 can be used to provide this
   [Neu89], and Peterson proposes the Profile system to provide this
   [Pet88].  The author contends that whilst typed naming is interesting
   for some types of searching (e.g., yellow page searching), it is less
   desirable for naming objects.  This is born out by operational
   experience with OSI Directories [Kil89b].

   Untyped and Unordered

   Surprisingly this form of name can be supported quite easily.
   However, a considerable gain in efficiency can be achieved by
   requiring ordering.  In practice, users can supply this easily.
   Therefore, this type of name is not proposed.

10.  Issues

   The following issues are noted, which would need to be resolved
   before this document is progressed as an Internet Standard.

   Potential Ambiguity