As per Relevance of the word environment, we have this rfc below:
Network Working Group S. Hardcastle-
Request for Comments: 1484 ISODE
July 1993
Using the OSI Directory to
User Friendly
(OSI-DS 24 (v1.2))
Status of this
This memo defines an Experimental Protocol for the
community. It does not specify an Internet standard. Discussion
suggestions for improvement are requested. Please refer to
current edition of the "IAB Official Protocol Standards" for
standardization state and status of this protocol. Distribution
this memo is unlimited
The OSI Directory has user friendly naming as a goal. A
minded usage of the directory does not achieve this. Two aspects
achieved are
o A user oriented
o
This proposal sets out some conventions for representing names in
friendly manner, and shows how this can be used to achieve
friendly naming. This then leads to a specification of a format
representing names, and to procedures to resolve them. This leads
a specification which allows directory names to be
between humans. The format in this specification is identical
that defined in [HK93], and it is intended that these
are compatible. Please send comments to the author or to
discussion group: .
Hardcastle-Kille [Page 1]
RFC 1484 User Friendly Naming July 1993
Table of
1. Why a notation is needed...................................... 2
2. The Notation.................................................. 3
3. Communicating Directory Names................................. 8
4. Matching a purported name..................................... 9
4.1 Environment................................................... 10
4.2 Matching...................................................... 12
4.3 Top Level..................................................... 13
4.4 Intermediate Level............................................ 14
4.5 Bottom Level.................................................. 15
5. Examples...................................................... 15
6. Support required from the standard............................ 16
7. Support of OSI Services....................................... 16
8. Experience.................................................... 17
9. Relationship to other work.................................... 18
10. Issues........................................................ 19
11. References.................................................... 20
12. Security Considerations....................................... 21
13. Author's Address.............................................. 21
A. Pseudo-code for the matching algorithm ....................... 21
List of
1. Example usage of User Friendly Naming.......................... 18
2. Matching Algorithm............................................. 25
List of
1. Local environment for private DUA.............................. 11
2. Local environment for US Public DUA............................ 11
1. Why a notation is
Many OSI Applications make use of Distinguished Names (DN) as
in the OSI Directory [CCI88]. The main reason for having a
for name format is to interact with a user interface.
specification is coming dangerously close to the sin of
interfaces. However, there are aspects of presentation which it
desirable to standardise
It is important to have a common format to be able to
refer to names. This might be done to represent a directory name
a business card or in an email message. There is a need for a
to support human to human communication, which must be string
(not ASN.1) and user oriented
Hardcastle-Kille [Page 2]
RFC 1484 User Friendly Naming July 1993
In very many cases, a user will be required to input a name.
notation is designed to allow this to happen in a uniform
across many user interfaces. The intention is that the name can
be typed in. There should not be any need to engage in form
or complex dialogue
It should be possible to take the "human" description given at
meeting, and use it directly. The means in which this happens
become clear later
This approach uses the syntax defined in RFC1485 for
distinguished names [HK93]. By relaxing some of the constraints
this specification, it is argued that a more user
specification is produced. However, this syntax cannot be
algorithmically onto a distinguished name without the use of
directory
This notation is targeted towards a general user oriented system,
in particular to represent the names of humans. Other syntaxes
be more appropriate for other uses of the directory. For example
the OSF Syntax may be more appropriate for some system oriented uses
(The OSF Syntax uses "/" as a separator, and forms names in a
intended to resemble UNIX filenames).
This notation is targeted towards names which follow a particular
structure: organisationally oriented. This may make it
for some types of application. There may be a requirement to
this notation to deal more cleanly with fully geographical names
This approach effectively defines a definition of descriptive
on top of the primitive names defined by the OSI Directory
2. The
The notation used in this specification is defined in [HK93].
notation defines an unambiguous representation of distinguished name
and this specification is designed to be used in conjunction
this format. Both specifications arise from the same piece
research work [Kil90]. Some examples of the specification are
here
The author's User Friendly Name (UFN) might be written
Steve Hardcastle-Kille, Computer Science, University
London,
Hardcastle-Kille [Page 3]
RFC 1484 User Friendly Naming July 1993
S. Hardcastle-Kille, Computer Science, University College London
This may be folded, perhaps to display in multi-column format.
example
Steve Hardcastle-Kille
Computer Science
University College London
Another UFN might be
Christian Huitema, INRIA,
James Hacker
Basingstoke
Widget Inc
The final example shows quoting of a comma in an Organisation name
L. Eagle, "Sue, Grabbit and Runn",
A purported name is what a user supplies to an interface
resolution into one or more distinguished names. A system
almost always store a name as a distinguished name. This will
more efficient, and avoid problems with purported names which
ambiguous when a new name appears. A user interface may display
distinguished name, using the distinguished name notation. However
it may display a purported name in cases where this will be
pleasing to the user. Examples of this might be
o Omission of the higher components of the distinguished name
not displayed (abbreviation).
o Omission of attribute types, where the type is unlikely to
needed to resolve ambiguity
The ways in which a purported name may vary from a distinguished
are now described
Hardcastle-Kille [Page 4]
RFC 1484 User Friendly Naming July 1993
Type
There are two cases of this
o Schema defaulting. In this case, although the type is
present, a schema defaulting is used to deduce the type.
first two types of schema defaulting may be used to deduce
distinguished name without the use of the directory. The
of schema defaulting may be useful to improve the
of UFN resolution. The types of schema defaulting are
-- Default
-- Context Dependent Default
-- Data Dependent Default
o Omission of the type to be resolved by searching
Default
The attribute type of an attribute may always be present. This
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
common cases, no attribute types are needed. The following
hierarchy (schema) is assumed
Common Name, (((Organisational Unit)*, Organisation,) Country
Explicitly typed RDNs may be inserted into this hierarchy at
point. The least significant component is always of type
Name. Other types follow the defined organisational hierarchy.
following are equivalent
Filestore Access, Bells, Computer Science
University College London,
CN=Filestore Access, OU=Bells, OU=Computer Science
O=University College London, C=
To interpet a distinguished name presented in this format, with
or all of the attributes with the type not specified, the types
derived according to the type hierarchy by the following algorithm
1. If the first attribute type is not specified, it
CommonName
Hardcastle-Kille [Page 5]
RFC 1484 User Friendly Naming July 1993
2. If the last attribute type is not specified, it is Country
3. If there is no organisation explicitly specified, the
attribute with type not specified is of type Organisation
4. Any remaining attribute with type unspecified must be
an Organisation or OrganisationalUnit attribute, and is
type OrganisationalUnit
To take a distinguished name, and generate a name of this format
attribute types omitted, the following steps are followed
1. If the first attribute is of type CommonName, the type may
omitted
2. If the last attribute is of type Country, the type may
omitted
3. If the last attribute is of type Country, the last
attribute may have the type omitted
4. All attributes of type OrganisationalUnit may have the
omitted, unless they are after an Organisation attribute
the first attribute is of type OrganisationalUnit
Context Dependent Default
The distinguished name notation defines a fixed schema for
defaulting. It may be useful to have different defaults in
contexts. For example, the defaulting convention may be applied in
modified fashion to objects which are known not to be common
objects. This will always be followed if the least
component is explicitly typed. In this case, the following
is followed
((Organisational Unit)*, Organisation,)
Data Dependent
There are cases where it would be optimal to default according to
data. For example, in
Einar Stefferud, Network Management Associates, CA,
It would be useful to default "CA" to type State. This might be
by defaulting all two letter attributes under C=US to type State
Hardcastle-Kille [Page 6]
RFC 1484 User Friendly Naming July 1993
General
A type may be omitted in cases where it does not follow a
schema hierarchy, and then type variants can be explored
searching. Thus a distinguished name could be represented by
uniquely matching purported name. For example
James Hacker
Basingstoke
Widget Inc
Would match the distinguished name
CN=James Hacker
L=Basingstoke
O=Widget Inc
CN=
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-
Could be interpreted in the context of an organisational default
Local Type
Local values can be used to identify types, in addition to
keywords defined in [HK93]. For example, "Organisation" may
recognised as an alternative to "O".
Component
An intermediate component of the name may be omitted. Typically
will be an organisational unit. For example
Steve Hardcastle-Kille, University College London,
In some cases, this can be combined with abbreviation. For example
Steve Hardcastle-Kille, University College
Hardcastle-Kille [Page 7]
RFC 1484 User Friendly Naming July 1993
Approximate renditions or alternate values of one or more of
components will be supplied. For example
Stephen Hardcastle-Kille, CS, UCL,
Steve Keill, Comp Sci, Univarstiy College London,
Friendly
A "friendly country name" can be used instead of the ISO 3166
letter code. For example
UK; USA; France; Deutchland
3. Communicating Directory
A goal of this standard is to provide a means of
directory names. Two approaches are given, one defined in [HK93],
and the other here. A future version of these specifications
contain only one of these approaches, or recommend use of
approach. The approach can usually be distinguished implicitly,
types are normally omitted in the UFN approach, and are
present in the Distinguished Name approach. No recommendation
made here, but the merits of each approach is given
1. Distinguished Name or DN. A representation of the
name, according to the specification of [HK93].
2. User Friendly Name or UFN. A purported name, which is
to unambiguously resolve onto the distinguished name
When a UFN is communicated, a form which should efficiently
unambiguously resolve onto a distinguished name should be chosen
Thus it is reasonable to omit types, or to use alternate values
will unambiguously identify the entry in question (e.g., by use of
alternate value of the RDN attribute type). It is not reasonable
use keys which are (or are likely to become) ambiguous
The approach used should be implicit from the context, rather
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
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
the user
o The DN will be used efficiently by the directory to
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
ambiguity
o Alternate values can be used to identify a component. This
be used to select a value which is meaningful to the recipient,
to use a shorter form of the name. Often the
requirements of registration will lead to long names, which
will wish to avoid
o Levels of the hierarchy may be omitted. For example in a
small organisation, where a level of hierarchy has been used
represent company structure, and the person has a unique
within the organisation
Where UFN form is used, it is important to specify an
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
make the address unambiguous
4. Matching a purported
The following approach specifies a default algorithm to be used
the User Friendly Naming approach. It is appropriate to modify
algorithm, and future specifications may propose
algorithms. Two simple algorithms are noted in passing, which may
useful in some contexts
1. Use type omission only, but otherwise require the value of
RDN attribute to be present
2. Require each RDN to be identified as in 1), or by an
match on an alternate value of the RDN attribute
These algorithms do not offer the flexibility of the
algorithm proposed, but give many of the benefits of the approach
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
"user friendly" characteristic of guessability. A user will supply
purported name to a user interface, and this will be resolved onto
distinguished name. When a user supplies a purported name there is
need to derive the DN. In most cases, it should be possible to
a single name from the purported name. In some cases,
will arise and the user will be prompted to select from a
matches. This should also be the case where a component of the
did not "match very well".
There is an assumption that the user will simply enter the
correctly. The purported name variants are designed to make
happen! There is no need for fancy window based interfaces or
filling for many applications of the directory. Note that the
interfaces still have a role for browsing, and for more
matching. This type of naming is to deal with cases
information on a known user is desired and keyed on the user's name
4.1
All matches occur in the context of a local environment. The
environment defines a sequence of name of a non-leaf objects in
DIT. This environment effectively defines a list of acceptable
abbreviations where the DUA is employed. The environment should
controllable by the individual user. It also defines an order
which to operate
This list is defined in the context of the number of name
supplied. This allows varying heuristics, depending on
environment, to make the approach have the "right" behaviour
In most cases, the environment will start at a local point in
DIT, and move upwards. Examples are given in Tables 1 and 2.
1 shows an example for a typical local DUA, which has the
characteristics
One
Assumed first to be a user in the department, then a user
department within the university, the a national organisation,
finally a country
Two
Most significant component is first assumed to be a
organisation, then a department (this might be reversed in
organisations), and finally a country
Hardcastle-Kille [Page 10]
RFC 1484 User Friendly Naming July 1993
Three or more
The most significant component is first assumed to be a country,
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
+--------------------------------------+
| Number of | Environment |
| Components | |
+--------------------------------------+
| 1,2 | US |
| | CA |
| | __ |
+--------------------------------------+
| 3+ | __ |
| | US |
| | CA |
+--------------------------------------+
Table 2: Local environment for US Public
Hardcastle-Kille [Page 11]
RFC 1484 User Friendly Naming July 1993
4.2
A purported name will be supplied, usually with a small number
components. This will be matched in the context of an environment
Where there are multiple components to be matched, these should
matched sequentially. If an unambiguous DN is determined, the
continues as if the full DN had been supplied. For example
Stephen Hardcastle-Kille,
is being matched in the context of environment GB, first UCL
resolved to the distinguished name
University College London,
Then the next component of the purported name is taken to
the final name. If there is an ambiguity (e.g., if UCL had made
matches, both paths are explored to see if the ambiguity can
resolved. Eventually a set of names will be passed back to the user
Each component of the environment is taken in turn. If the
name has more components than the maximum depth, the
element is skipped. The advantage of this will be seen in
example given later
A match of a name is considered to have three levels
A DN is specified
Initially, a match should be considered good if it is unambiguous
and exactly matches an attribute value in the entry. For
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
explicit alternate values).
Any other substring or approximate
Following a match, the reference can be followed, or the
prompted. If there are multiple matches, more than one path may
followed. There is also a shift/reduce type of choice: should
partial matches be followed or should the next element of
Hardcastle-Kille [Page 12]
RFC 1484 User Friendly Naming July 1993
environment be tried. The following heuristics are suggested,
may be modified in the light of experience. The overall aim is
resolve cleanly specified names with a minimum of fuss, but
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
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
matches are found
When the final component is matched, a set of names will
identified. If none are identified, proceed to the next
element. If the user rejects all of the names, processing of
next environment element should be confirmed
The exact approach to matching will depend on the level of the
at which matching is being done. We can now consider how
are matched at various levels of the DIT
There is an issue of approximate matching. Sometimes it helps,
sometimes just returns many spurious matches. When a search
requested, all relevant attributes should be returned, so
distinguished and non-distinguished values can be looked at.
will allow a distinction to be made between good and poor matches
It is important that where, for example, an acronym exactly
an organisation, that the user is not prompted about
organisations where it matches as a substring
4.3 Top
In this case, a match is being done at the root of the DIT.
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
match on a friendly country or organisation (e.g., UK or UN).
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
organisation
4.4 Intermediate
Once the root level has been dealt with, intermediate levels will
looking for organisational components (Organisation, Locality,
Unit). In some cases, private schema control will allow the
to determine which is at the next level. In general this will not
possible. In each case, make a substring and approximate
search of one level. The choice depends on the base object used
the search
1. If DN has no Organisation or Locality, filter on
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
(either by being the environment or by partial resolution of
purported name), and the next element of a purported name is
considered. This will generate a single level search. What
is the types being filtered against. If the DN is
University College London,
The search should be for Org Unit or Locality. If the DN is
Organisation=
the search should be for Org Unit or Locality
There may be some improvements with respect to very short keys.
making approximate or substring matches in these cases
sensible. (It might be desirable to allow "*" as a part of
purported name notation).
Hardcastle-Kille [Page 14]
RFC 1484 User Friendly Naming July 1993
4.5 Bottom
The "Bottom Level" is to deal with leaf entries in the DIT. This
often be a person, but may also be a role, an application entity
something else
The last component of a purported name may either reference a leaf
non-leaf. For this reason, both should be tested for. As
heuristic, if the base object for the search has two or
components it should be tested first as a bottom level name and
intermediate. Reverse this for shorter names. This optimises
the (normal) case of non-leaves high up the tree and leaves low
the tree
For bottom level names, make an approximate and substring
against Common Name, Surname, and User ID. Where common name
looked for, a full subtree search will be used when at the
level of the DIT or lower, otherwise a single level search
For example, if I have resolved a purported name to the
University College London,
and have a single component Bloggs, this will generate a
search
5.
This is all somewhat confusing, and a few examples are given.
are all in the context of the environment shown in Table 1 in
4.1.
If "Joe Bloggs" is supplied, a subtree search
Physics, University College London,
will be made, and the user prompted for "Joseph Z. Bloggs" as
only possible match
If "Computer Science" is supplied,
Physics, University College London,
will be searched, and the user will reject the approximate match
"Colin Skin". Then a subtree search
University College London,
Hardcastle-Kille [Page 15]
RFC 1484 User Friendly Naming July 1993
will be made, looking for a person. Then a single level search
be made looking for Org Unit,
Computer Science, University College London,
will be returned without prompting (exact match). Supplying "
Hardcastle-Kille" will lead to a failed subtree search
Physics, University College London,
and lead straight to a subtree search
University College London,
This will lead to an exact value match, and so a single
returned without prompting
If "Andrew Findlay, Brunel" is supplied, the first element of
environment will be skipped, single level search of "Brunel"
"GB" will find
Brunel University,
and a subtree search for "Andrew Findlay" initiated. This will
Andrew Findlay, Computing and Media Services, Brunel University
Dr A J Findlay, Manufacturing and Engineering Systems,
University,
and the user will be prompted with a choice
This approach shows how a simple format of this nature will "do
right thing" in many cases
6. Support required from the
Fortunately, all that is needed is there! It would be useful to
"friendly country name" as a standard attribute
7. Support of OSI
The major focus of this work has been to provide a mechanism
identifying Organisations and Users. A related function is
identify applications. Where the Application is identified by an
(Application Entity Title) with an RDN of Common Name,
specification leads to a natural usage. For example, if a
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,
In normal usage, this might lead to access (using a purported name
of
FTAM gannet,
A second type of access is where the user identifies an
(Organisational Unit), and expects to obtain a default service.
service is implied by the application, and should not require
additional naming as far as the user is concerned. It is
that this is supported by User Friendly Naming in the following way
1. Determine that the purported name identifies a non-
object, which is of object class Organisation or
Unit or Locality
2. Perform a single level search for Application Entities
support the required application contexts. This assumes
all services which are supporting default access for
organisation are registered at one level below (possibly by
use of aliases), and that other services (specific machines
parts of the organisation) are represented further down
tree. This seems to be a reasonable layout, and its utility
be evaluated by experiment
8.
An experimental implementation of this has been written by
Robbins. The example in Figure 1 shows that it can be very
at locating known individuals with a minimum of effort. This
has been deployed within the "FRED" interface of the PSI
[Ros90], and within an prototype interface for managing
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,
the user guesses one which is not immediately below
organisation, the algorithm works badly. There does not
to be an easy fix for this. It is not clear if this is a
deficiency
o Substring searching is currently done with leading and
wildcards. As many implementations will not implement
Hardcastle-Kille [Page 17]
RFC 1484 User Friendly Naming July 1993
wildcards efficiently, it may be preferable to only use
wildcards. The effect of this on the algorithm needs to
investigated
Implementors of this specification are encouraged to
variants of the basic algorithm. A final specification should
on experience with such variants
-> t hales, csiro,
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] ?
The following were matched...
Trevor Hales, OC, HPCC, DIT, IICT, CSIRO,
-> g michaelson, queensland,
Found exact match(es) for 'au
Please select from the following
University of Queensland, AU [y/n] ?
Axolotl, AU [y/n] ?
Please select from the following
George Michaelson, Prentice Computer Centre, University
Queensland, AU [y/n] ?
Manager, University of Queensland, AU [y/n] ?
The following were matched...
George Michaelson, Prentice Computer Centre, University
Queensland,
-> r needham,
Found good match(es) for 'cambridge
Please select from the following
Roger Needham, Computer Lab, Cambridge University [y/n] ?
The following were matched...
Roger Needham, Computer Lab, Cambridge
->
Found good match(es) for 'kirstein
The following were matched...
Peter
Figure 1: Example usage of User Friendly
9. Relationship to other
Colin Robbin's work on the interface "Tom" and implementation of
distribution list interface strongly influenced this
[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
ISO/CCITT Directory Group on "New Name Forms" [Kil89a].
defined, and showed how to implement, four different types of names
Typed and
The current Distinguished Name is a restricted example of this
of name
Untyped and
This is the type of name proposed here (with some extensions to
optional typing). It is seen as meeting the key user requirement
disliking typed names, and is efficient to implement
Typed and
This sort of name is proposed by others as the key basis for
friendly naming. Neufeld shows how X.500 can be used to provide
[Neu89], and Peterson proposes the Profile system to provide
[Pet88]. The author contends that whilst typed naming is
for some types of searching (e.g., yellow page searching), it is
desirable for naming objects. This is born out by
experience with OSI Directories [Kil89b].
Untyped and
Surprisingly this form of name can be supported quite easily
However, a considerable gain in efficiency can be achieved
requiring ordering. In practice, users can supply this easily
Therefore, this type of name is not proposed
10.
The following issues are noted, which would need to be
before this document is progressed as an Internet Standard
Potential
Whilst the intention of the notation is to allow for specification
alternate values, it inherently allows for ambiguous names to
specified. It needs to be demonstrated that problems of
characteristic are outweighed by other benefits of the notation
Determine that the specification is being implemented and used
Hardcastle-Kille [Page 19]
RFC 1484 User Friendly Naming July 1993
Measurements on the performance implications of using this
should be made
The utility of the algorithm, and possible variants, should
investigated
This format, and the procedures for resolving purported names,
be evolved. The syntax can be expected to be stable. In light
experience, the algorithm for resolving purported names may
changed
11.
[CCI88] The Directory --- overview of concepts, models and services
December 1988. CCITT X.500 Series Recommendations
[HK93] S.E. Hardcastle-Kille. A string representation
distinguished names. RFC 1485, Department of
Science, University College London, July 1993.
[Kil89a] S.E. Kille. New name forms, May 1989. ISO/IEC/JTC 21/
WG4/N797 UK National Body Contribution to the Oslo
Meeting
[Kil89b] S.E. Kille. The THORN large scale pilot exercise.
Networks and ISDN Systems, 16(1):143--145, January 1989.
[Kil90] S.E. Kille. Using the OSI directory to achieve user
naming. Research Note RN/20/29, Department of
Science, University College London, February 1990.
[KRRT90] S.E. Kille, C.J. Robbins, M. Roe, and A. Turland. The
development environment: User's manual (version 6.0),
January 1990. Volume 5: QUIPU
[Neu89] G.W. Neufeld. Descriptive names in X.500. In SIGCOMM 89
Symposiun Communications Architectures and Protocols,
64--71, September 1989.
[Pet88] L.L. Petersen. The profile naming service. ACM
on Computing Systems, 6(4):341--364, November 1988.
Hardcastle-Kille [Page 20]
RFC 1484 User Friendly Naming July 1993
[Ros90] M.T. Rose. Realizing the White Pages using the OSI
Service. Technical Report 90--05--10--1, Performance
International, Inc., May 1990.
12. Security
Security issues are not discussed in this memo
13. Author's
Steve Hardcastle-
ISODE
P.O. Box 505
SW11 1
Phone:+44-71-223-4062
EMail: S.Kille@ISODE.
DN: CN=Steve Hardcastle-Kille
O=ISODE Consortium, C=
UFN: S. Hardcastle-Kille
ISODE Consortium,
A. Pseudo-code for the matching
The following pseudo-code is intended to clarify the
algorithm. The language uses ASN.1 data types, with flow
"C"-like,but with keywords upper--cased
____________________________________________________________________
PurportedName ::= SEQUENCE OF
-- simplication, as attribute types can optionally
--
-- Each element of the Purported Name is a
-- which has been parsed from the
Attribute ::= SEQUENCE { 10
type OBJECT IDENTIFIER
value ANY }
RDN ::= Attribute -- simplification, as can be multi-
DN ::= SEQUENCE OF
Hardcastle-Kille [Page 21]
RFC 1484 User Friendly Naming July 1993
Environment ::= SEQUENCE OF
20
EnvironmentList ::= SEQUENCE OF SEQUENCE {
lower-bound INTEGER
upper-bound INTEGER
environment Environment }
friendlyMatch(p: PurportedName; el: EnvironmentList): SET OF
-- Find correct
30
IF length(el) == 0 THEN return(NULL);
IF length(p) <= head(el).upper-
&& length(p) >= head(el).lower-bound
return envMatch (p, head(el).environment);
return(friendlyMatch(p, tail(el));
40
envMatch(p: PurportedName; e: Environment): SET OF
-- Check elements of
-- in the defined
matches: SET OF DN
IF length(e) == 0 THEN return(NULL);
matches = purportedMatch(head(e).DN, p) 50
IF matches != NULL
return(matches);
return(envMatch(p, tail(e));
purportedMatch(base: DN; p: PurportedName): SET OF
s: String = head(p); 60
matches: SET OF DN = NULL
IF length(p) == 1
IF length(base) == 0
IF (matches = rootSearch(s)) != NULL
return(matches);
ELSE return(leafSearch(base, s, one-level);
ELSE IF length(base) == 1
Hardcastle-Kille [Page 22]
RFC 1484 User Friendly Naming July 1993
IF (matches = intSearch(base, s)) != NULL
return(matches); 70
ELSE return(leafSearch(base, s, one-level);
IF (matches = leafSearch(base, s, subtree)) !=
NULL
return(matches);
ELSE return(intsearch(base, s);
IF length(base) == 0
FOR x IN rootSearch(s)
matches += (purportedMatch(x, tail(p)); 80
FOR x IN intSearch(base, s)
matches += (purportedMatch(x, tail(p));
return(matches);
-- General. Might need to tighten the filter for short strings
-- in order to stop being flooded. Alternatively, this could
-- done if the loose search hists a size limit 90
rootSearch(s: String): SET OF
IF length(s) == 2
return(search(NULL, one-level, s, {CountryName
FriendlyCountryName, OrganizationName},
{exact}, {Country, Organisation}));
-- test exact match
-- probably a country
ELSE 100
return(search(NULL, one-level, s, {OrganizationName
FriendlyCountryName}, {substring, approx},
{Country, Organisation}));
intSearch( base: DN; s: String
IF present(base, OrgUnitName)
return(search(base, one-level, s, {OrgUnitName}, 110
{substring, approx}, {OrgUnit}));
ELSE IF present(base, OrganisationName)
return(search(base, one-level, s, {OrgUnitName
LocalityName}, {substring, approx},
{Organization, OrgUnit, Locality}));
ELSE IF present(base, LocalityName)
return(search(base, one-level, s, {OrganisationName},
{substring, approx}, {Locality});
Hardcastle-Kille [Page 23]
RFC 1484 User Friendly Naming July 1993
return(search(base, one-level, s, {OrganisationName,120
LocalityName}, {substring, approx},
{Organisation, Locality}));
present(d: DN; t: AttributeType):
FOR x IN d
IF x.type == t THEN return(TRUE);
return(FALSE); 130
SearchScope := ENUMERATED (base-object, one-level, subtree
leafSearch(base: DN; s: String; search-scope: SearchScope
return(search(base, search-scope, s, {CommonName, Surname
UserId}, {substring, approx}));
140
search(base: DN; search-scope: SearchScope; s: string
alist SET OF AttributeType; matchtypes SET OF
objectClasses SET OF ObjectClass OPTIONAL): SET OF
-- mapped onto Directory Search, with OR
-- of filter
return dNSelect (s, search-results, alist);
} 150
read(base: DN; alist SET OF AttributeType): SET OF Attribute
-- mapped onto Directory
-- Types repeated to deal with multiple
-- This would be implemented by returning selected
-- with the search
dNSelect(s: String; dlist SET OF DN; alist: SET OF AttributeType):
16SET0OF
exact, good: SET OF DN
FOR x IN dlist
IF last(DN).Value == s
exact += x
ELSE IF FOR y IN read(x, alist)
IF y.value == s
good += x
170
Hardcastle-Kille [Page 24]
RFC 1484 User Friendly Naming July 1993
IF exact != NULL THEN return(exact);
IF good != NULL THEN return(good);
return(userQuery(dlist));
userQuery(dlist SET OF DN): SET OF
-- pass back up for manual checking 180
-- user can strip all matches to force progres....
head() -- return first element of
tail() -- return list with first element
length() -- return size of
last() -- return last element of
Figure 2: Matching
______________________________________________________________________
Hardcastle-Kille [Page 25]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
