📄 rfc1781.txt
字号:
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]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -