7 Network Working Group S. Kille
8 Request for Comments: 1781 ISODE Consortium
9 Obsoletes: 1484 March 1995
10 Category: Standards Track
13 Using the OSI Directory to Achieve User Friendly Naming
17 This document specifies an Internet standards track protocol for the
18 Internet community, and requests discussion and suggestions for
19 improvements. Please refer to the current edition of the "Internet
20 Official Protocol Standards" (STD 1) for the standardization state
21 and status of this protocol. Distribution of this memo is unlimited.
25 The OSI Directory has user friendly naming as a goal. A simple
26 minded usage of the directory does not achieve this. Two aspects not
29 o A user oriented notation
33 This proposal sets out some conventions for representing names in a
34 friendly manner, and shows how this can be used to achieve really
35 friendly naming. This then leads to a specification of a standard
36 format for representing names, and to procedures to resolve them.
37 This leads to a specification which allows directory names to be
38 communicated between humans. The format in this specification is
39 identical to that defined in [5], and it is intended that these
40 specifications are compatible.
44 1. Why a notation is needed ................................... 2
45 2. The Notation ............................................... 3
46 3. Communicating Directory Names .............................. 7
47 4. Matching a purported name .................................. 9
48 4.1 Environment .......................................... 9
49 4.2 Matching ............................................. 10
50 4.3 Top Level ............................................ 12
51 4.4 Intermediate Level ................................... 13
52 4.5 Bottom Level ......................................... 14
53 5. Examples ................................................... 14
54 6. Support required from the standard ......................... 15
60 RFC 1781 User Friendly Naming March 1995
63 7. Support of OSI Services .................................... 15
64 8. Experience ................................................. 16
65 9. Relationship to other work ................................. 17
66 10. Issues ..................................................... 19
67 11. References ................................................. 20
68 12. Security Considerations .................................... 21
69 13. Author's Address ........................................... 21
70 A. Pseudo-code for the matching algorithm ..................... 22
72 1. Example usage of User Friendly Naming ................ 18
73 2. Matching Algorithm ................................... 22
75 1. Local environment for private DUA .................... 10
76 2. Local environment for US Public DUA .................. 11
78 1. Why a notation is needed
80 Many OSI Applications make use of Distinguished Names (DN) as defined
81 in the OSI Directory [1]. The main reason for having a notation for
82 name format is to interact with a user interface. This specification
83 is coming dangerously close to the sin of standardising interfaces.
84 However, there are aspects of presentation which it is desirable to
87 It is important to have a common format to be able to conveniently
88 refer to names. This might be done to represent a directory name on
89 a business card or in an email message. There is a need for a format
90 to support human to human communication, which must be string based
91 (not ASN.1) and user oriented.
93 In very many cases, a user will be required to input a name. This
94 notation is designed to allow this to happen in a uniform manner
95 across many user interfaces. The intention is that the name can just
96 be typed in. There should not be any need to engage in form filling
97 or complex dialogue. It should be possible to take the "human"
98 description given at the meeting, and use it directly. The means in
99 which this happens will become clear later.
101 This approach uses the syntax defined in [5] for representing
102 distinguished names. By relaxing some of the constraints on this
103 specification, it is argued that a more user oriented specification
104 is produced. However, this syntax cannot be mapped algorithmically
105 onto a distinguished name without the use of a directory.
107 This notation is targeted towards a general user oriented system, and
108 in particular to represent the names of humans. Other syntaxes may
109 be more appropriate for other uses of the directory. For example,
110 the OSF Syntax may be more appropriate for some system oriented uses.
116 RFC 1781 User Friendly Naming March 1995
119 (The OSF Syntax uses "/" as a separator, and forms names in a manner
120 intended to resemble UNIX filenames).
122 This notation is targeted towards names which follow a particular DIT
123 structure: organisationally oriented. This may make it
124 inappropriate for some types of application. There may be a
125 requirement to extend this notation to deal more cleanly with fully
128 This approach effectively defines a definition of descriptive names
129 on top of the primitive names defined by the OSI Directory.
133 The notation used in this specification is defined in [5]. This
134 notation defines an unambiguous representation of distinguished name,
135 and this specification is designed to be used in conjunction with
136 this format. Both specifications arise from the same piece of
137 research work [4]. Some examples of the specification are given
138 here. The author's User Friendly Name (UFN) might be written:
140 Steve Kille, Computer Science, University College London, GB
144 S. Kille, Computer Science, University College London, GB
146 This may be folded, perhaps to display in multi-column format. For
151 University College London,
154 Another UFN might be:
156 Christian Huitema, INRIA, FR
164 The final example shows quoting of a comma in an Organisation name:
166 L. Eagle, "Sue, Grabbit and Runn", GB
172 RFC 1781 User Friendly Naming March 1995
175 A purported name is what a user supplies to an interface for
176 resolution into one or more distinguished names. A system should
177 almost always store a name as a distinguished name. This will be
178 more efficient, and avoid problems with purported names which become
179 ambiguous when a new name appears. A user interface may display a
180 distinguished name, using the distinguished name notation. However,
181 it may display a purported name in cases where this will be more
182 pleasing to the user. Examples of this might be:
184 o Omission of the higher components of the distinguished name are
185 not displayed (abbreviation).
187 o Omission of attribute types, where the type is unlikely to be
188 needed to resolve ambiguity.
190 The ways in which a purported name may vary from a distinguished name
195 There are two cases of this.
197 o Schema defaulting. In this case, although the type is not
198 present, a schema defaulting is used to deduce the type. The
199 first two types of schema defaulting may be used to deduce a
200 distinguished name without the use of the directory. The use
201 of schema defaulting may be useful to improve the performance
202 of UFN resolution. The types of schema defaulting are:
206 -- Context Dependent Default Schema
208 -- Data Dependent Default Schema
210 o Omission of the type to be resolved by searching.
214 The attribute type of an attribute may always be present. This may
215 be done to emphasise the type structure of a name. In some cases,
216 the typing may be omitted. This is done in a way so that in many
217 common cases, no attribute types are needed. The following type
218 hierarchy (schema) is assumed:
228 RFC 1781 User Friendly Naming March 1995
231 Common Name, (((Organisational Unit)*, Organisation,) Country).
233 Explicitly typed RDNs may be inserted into this hierarchy at any
234 point. The least significant component is always of type Common
235 Name. Other types follow the defined organisational hierarchy.
236 The following are equivalent:
238 Filestore Access, Bells, Computer Science,
239 University College London, GB
243 CN=Filestore Access, OU=Bells, OU=Computer Science,
244 O=University College London, C=GB
246 To interpet a distinguished name presented in this format, with some
247 or all of the attributes with the type not specified, the types are
248 derived according to the type hierarchy by the following algorithm:
250 1. If the first attribute type is not specified, it is
253 2. If the last attribute type is not specified, it is Country.
255 3. If there is no organisation explicitly specified, the last
256 attribute with type not specified is of type Organisation.
258 4. Any remaining attribute with type unspecified must be before
259 an Organisation or OrganisationalUnit attribute, and is of
260 type OrganisationalUnit.
262 To take a distinguished name, and generate a name of this format with
263 attribute types omitted, the following steps are followed.
265 1. If the first attribute is of type CommonName, the type may be
268 2. If the last attribute is of type Country, the type may be
271 3. If the last attribute is of type Country, the last
272 Organisation attribute may have the type omitted.
274 4. All attributes of type OrganisationalUnit may have the type
275 omitted, unless they are after an Organisation attribute or
276 the first attribute is of type OrganisationalUnit.
284 RFC 1781 User Friendly Naming March 1995
287 Context Dependent Default Schema
289 The distinguished name notation defines a fixed schema for type
290 defaulting. It may be useful to have different defaults in different
291 contexts. For example, the defaulting convention may be applied in a
292 modified fashion to objects which are known not to be common name
293 objects. This will always be followed if the least significant
294 component is explicitly typed. In this case, the following hierarchy
297 ((Organisational Unit)*, Organisation,) Country
299 Data Dependent Defaulting
301 There are cases where it would be optimal
302 to default according to the data. For example, in:
304 Einar Stefferud, Network Management Associates, CA, US
306 It would be useful to default "CA" to type State. This might be done
307 by defaulting all two letter attributes under C=US to type State.
311 A type may be omitted in cases where it does not follow a default
312 schema hierarchy, and then type variants can be explored by
313 searching. Thus a distinguished name could be represented by a
314 uniquely matching purported name. For example,
321 Would match the distinguished name:
330 Some of the more significant components of the DN will be omitted,
331 and then defaulted in some way (e.g., relative to a local context).
340 RFC 1781 User Friendly Naming March 1995
343 Could be interpreted in the context of an organisational default.
347 Local values can be used to identify types, in addition to the
348 keywords defined in [5]. For example, "Organisation" may be
349 recognised as an alternative to "O".
353 An intermediate component of the name may be omitted. Typically this
354 will be an organisational unit. For example:
356 Steve Kille, University College London, GB
358 In some cases, this can be combined with abbreviation. For example:
360 Steve Kille, University College London
364 Approximate renditions or alternate values of one or
365 more of the components will be supplied. For example:
367 Stephen Kille, CS, UCL, GB
371 Steve Keill, Comp Sci, Univarstiy College London, GB
375 A "friendly country name" can be used instead of the ISO 3166 two
376 letter code. For example: UK; USA; France; Deutchland.
378 3. Communicating Directory Names
380 A goal of this standard is to provide a means of communicating
381 directory names. Two approaches are given, one defined in [5], and
382 the other here. A future version of these specifications may contain
383 only one of these approaches, or recommend use of one approach. The
384 approach can usually be distinguished implicitly, as types are
385 normally omitted in the UFN approach, and are always present in the
386 Distinguished Name approach. No recommendation is made here, but the
387 merits of each approach is given.
396 RFC 1781 User Friendly Naming March 1995
399 1. Distinguished Name or DN. A representation of the distinguished
400 name, according to the specification of [5].
402 2. User Friendly Name or UFN. A purported name, which is expected to
403 unambiguously resolve onto the distinguished name.
405 When a UFN is communicated, a form which should efficiently and
406 unambiguously resolve onto a distinguished name should be chosen.
407 Thus it is reasonable to omit types, or to use alternate values which
408 will unambiguously identify the entry in question (e.g., by use of an
409 alternate value of the RDN attribute type). It is not reasonable to
410 use keys which are (or are likely to become) ambiguous. The approach
411 used should be implicit from the context, rather than wired into the
412 syntax. The terms "Directory Name" and "X.500 Name" should be used
413 to refer to a name which might be either a DN or UFN. An example of
414 appropriate usage of both forms is given in the Section which defines
415 the Author's location in Section 12. Advantages of communicating the
418 o The Distinguished Name is an unambiguous and stable reference to
421 o The DN will be used efficiently by the directory to obtain
424 Advantages of communicating the UFN are:
426 o Redundant type information can be omitted (e.g., "California",
427 rather than "State=California", where there is known to be no
430 o Alternate values can be used to identify a component. This might
431 be used to select a value which is meaningful to the recipient, or
432 to use a shorter form of the name. Often the uniqueness
433 requirements of registration will lead to long names, which users
436 o Levels of the hierarchy may be omitted. For example in a very
437 small organisation, where a level of hierarchy has been used to
438 represent company structure, and the person has a unique name
439 within the organisation.
441 Where UFN form is used, it is important to specify an unambiguous
442 form. In some ways, this is analogous to writing a postal address.
443 There are many legal ways to write it. Care needs to be taken to
444 make the address unambiguous.
452 RFC 1781 User Friendly Naming March 1995
455 4. Matching a purported name
457 The following approach specifies a default algorithm to be used with
458 the User Friendly Naming approach. It is appropriate to modify this
459 algorithm, and future specifications may propose alternative
460 algorithms. Two simple algorithms are noted in passing, which may be
461 useful in some contexts:
463 1. Use type omission only, but otherwise require the value of the RDN
464 attribute to be present.
466 2. Require each RDN to be identified as in 1), or by an exact match
467 on an alternate value of the RDN attribute.
469 These algorithms do not offer the flexibility of the default
470 algorithm proposed, but give many of the benefits of the approach in
471 a very simple manner.
473 The major utility of the purported name is to provide the important
474 "user friendly" characteristic of guessability. A user will supply a
475 purported name to a user interface, and this will be resolved onto a
476 distinguished name. When a user supplies a purported name there is a
477 need to derive the DN. In most cases, it should be possible to derive
478 a single name from the purported name. In some cases, ambiguities
479 will arise and the user will be prompted to select from a multiple
480 matches. This should also be the case where a component of the name
481 did not "match very well".
483 There is an assumption that the user will simply enter the name
484 correctly. The purported name variants are designed to make this
485 happen! There is no need for fancy window based interfaces or form
486 filling for many applications of the directory. Note that the fancy
487 interfaces still have a role for browsing, and for more complex
488 matching. This type of naming is to deal with cases where
489 information on a known user is desired and keyed on the user's name.
493 All matches occur in the context of a local environment. The local
494 environment defines a sequence of names of a non-leaf objects in the
495 DIT. This environment effectively defines a list of acceptable name
496 abbreviations where the DUA is employed. The environment should be
497 controllable by the individual user. It also defines an order in
500 This list is defined in the context of the number of name components
501 supplied. This allows varying heuristics, depending on the
502 environment, to make the approach have the "right" behaviour. In
508 RFC 1781 User Friendly Naming March 1995
511 most cases, the environment will start at a local point in the DIT,
512 and move upwards. Examples are given in Tables 1 and 2. Table 1
513 shows an example for a typical local DUA, which has the following
518 Assumed first to be a user in the department, then a user or
519 department within the university, then a national organisation, and
524 Most significant component is first assumed to be a national
525 organisation, then a department (this might be reversed in some
526 organisations), and finally a country.
528 Three or more components
530 The most significant component is first assumed to be a country, then
531 a national organisation, and finally a department.
535 A purported name will be supplied, usually with a small number of
536 components. This will be matched in the context of an environment.
537 Where there are multiple components to be matched, these should be
538 matched sequentially. If an unambiguous DN is determined, the match
539 continues as if the full DN had been supplied. For example, if
541 +-----------+--------------------------------------+
542 |Number of |Environment |
544 +-----------+--------------------------------------+
545 |1 |Physics, University College London, GB|
546 | |University College London, GB |
548 +-----------+--------------------------------------+
550 | |University College London, GB |
552 +-----------+--------------------------------------+
555 | |University College London, GB |
556 +-----------+--------------------------------------+
558 Table 1: Local environment for private DUA
564 RFC 1781 User Friendly Naming March 1995
567 +------------+-----------+
568 | Number of |Environment|
570 +------------+-----------+
574 +------------+-----------+
578 +------------+-----------+
580 Table 2: Local environment for US Public DUA
584 is being matched in the context of environment GB, first UCL is
585 resolved to the distinguished name:
587 University College London, GB
589 Then the next component of the purported name is taken to determine
590 the final name. If there is an ambiguity (e.g., if UCL had made two
591 matches, both paths are explored to see if the ambiguity can be
592 resolved. Eventually a set of names will be passed back to the user.
594 Each component of the environment is taken in turn. If the purported
595 name has more components than the maximum depth, the environment
596 element is skipped. The advantage of this will be seen in the
599 A match of a name is considered to have three levels:
601 Exact A DN is specified exactly
603 Good Initially, a match should be considered good if it is
604 unambiguous, and exactly matches an attribute value in the entry.
605 For human names, a looser metric is probably desirable (e.g.,
606 S Kille should be a good match of S. Kille, S.E. Kille or Steve
607 Kille even if these are not explicit alternate values).
609 Poor Any other substring or approximate match
611 Following a match, the reference can be followed, or the user
612 prompted. If there are multiple matches, more than one path may be
613 followed. There is also a shift/reduce type of choice: should any
614 partial matches be followed or should the next element of the
620 RFC 1781 User Friendly Naming March 1995
623 environment be tried. The following heuristics are suggested, which
624 may be modified in the light of experience. The overall aim is to
625 resolve cleanly specified names with a minimum of fuss, but give
626 sufficient user control to prevent undue searching and delay.
628 1. Always follow an exact match.
630 2. Follow all good matches if there are no exact matches.
632 3. If there are only poor matches, prompt the user. If the user
633 accepts one or more matches, they can be considered as good. If
634 all are rejected, this can be treated as no matches.
636 4. Automatically move to the next element of the environment if no
639 When the final component is matched, a set of names will be
640 identified. If none are identified, proceed to the next environment
641 element. If the user rejects all of the names, processing of the
642 next environment element should be confirmed.
644 The exact approach to matching will depend on the level of the tree
645 at which matching is being done. We can now consider how attributes
646 are matched at various levels of the DIT.
648 There is an issue of approximate matching. Sometimes it helps, and
649 sometimes just returns many spurious matches. When a search is
650 requested, all relevant attributes should be returned, so that
651 distinguished and non-distinguished values can be looked at. This
652 will allow a distinction to be made between good and poor matches.
653 It is important that where, for example, an acronym exactly matches
654 an organisation, that the user is not prompted about other
655 organisations where it matches as a substring.
659 In this case, a match is being done at the root of the DIT. Three
660 approaches are suggested, dependent on the length of supplied name.
661 All lead to a single level search of the top level of the DIT.
665 This is assumed to be a 3166 two letter country code, or an exact
666 match on a friendly country or organisation (e.g., UK or UN). Do
667 exact match on country and friendly country.
676 RFC 1781 User Friendly Naming March 1995
681 Make an approximate and substring match on friendly country and
684 4.4 Intermediate Level
686 Once the root level has been dealt with, intermediate levels will be
687 looking for organisational components (Organisation, Locality, Org
688 Unit). In some cases, private schema control will allow the system
689 to determine which is at the next level. In general this will not be
690 possible. In each case, make a substring and approximate match
691 search of one level. The choice depends on the base object used in
694 1. If DN has no Organisation or Locality, filter on Organisation and
697 2. If DN has Org Unit, filter on Org Unit.
699 3. If DN has Organisation, filter on Locality and Org Unit.
701 4. If DN has Locality, filter on Organisation.
703 These allow some optimisation, based on legal choices of schema.
704 Keeping filters short is usually desirable to improve performance. A
705 few examples of this, where a base object has been determined (either
706 by being the environment or by partial resolution of a purported
707 name), and the next element of a purported name is being considered.
708 This will generate a single level search. What varies is the types
709 being filtered against. If the DN is:
711 University College London, GB
713 The search should be for Org Unit or Locality. If the DN is:
717 the search should be for Org Unit or Locality.
719 There may be some improvements with respect to very short keys. Not
720 making approximate or substring matches in these cases seems sensible
721 (It might be desirable to allow "*" as a part of the purported name
732 RFC 1781 User Friendly Naming March 1995
737 The "Bottom Level" is to deal with leaf entries in the DIT. This will
738 often be a person, but may also be a role, an application entity or
741 The last component of a purported name may either reference a leaf or
742 non-leaf. For this reason, both should be tested for. As a
743 heuristic, if the base object for the search has two or more
744 components it should be tested first as a bottom level name and then
745 intermediate. Reverse this for shorter names. This optimises for
746 the (normal) case of non-leaves high up the tree and leaves low down
749 For bottom level names, make an approximate and substring match
750 against Common Name, Surname, and User ID. Where common name is
751 looked for, a full subtree search will be used when at the second
752 level of the DIT or lower, otherwise a single level search.
754 For example, if I have resolved a purported name to the distinguished
757 University College London, GB
759 and have a single component Bloggs, this will generate a subtree
764 This is all somewhat confusing, and a few examples are given. These
765 are all in the context of the environment shown in Table 1 on Page
768 If "Joe Bloggs" is supplied, a subtree search of
770 Physics, University College London, GB
772 will be made, and the user prompted for "Joseph Z. Bloggs" as the
775 If "Computer Science" is supplied, first
777 Physics, University College London, GB
779 will be searched, and the user will reject the approximate match of
780 "Colin Skin". Then a subtree search of
782 University College London, GB
788 RFC 1781 User Friendly Naming March 1995
791 will be made, looking for a person. Then a single level search will
792 be made looking for Org Unit, and
794 Computer Science, University College London, GB
796 will be returned without prompting (exact match). Supplying "Steve
797 Kille" will lead to a failed subtree search of
799 Physics, University College London, GB
801 and lead straight to a subtree search of
803 University College London, GB
805 This will lead to an exact value match, and so a single entry
806 returned without prompting.
808 If "Andrew Findlay, Brunel" is supplied, the first element of the
809 environment will be skipped, single level search of "Brunel" under
812 Brunel University, GB
814 and a subtree search for "Andrew Findlay" initiated. This will yield
816 Andrew Findlay, Computing and Media Services, Brunel University, GB
818 Dr A J Findlay, Manufacturing and Engineering Systems, Brunel
821 and the user will be prompted with a choice.
823 This approach shows how a simple format of this nature will "do the
824 right thing" in many cases.
826 6. Support required from the standard
828 Fortunately, all that is needed is there! It would be useful to have
829 "friendly country name" as a standard attribute.
831 7. Support of OSI Services
833 The major focus of this work has been to provide a mechanism for
834 identifying Organisations and Users. A related function is to
835 identify applications. Where the Application is identified by an AET
836 (Application Entity Title) with an RDN of Common Name, this
837 specification leads to a natural usage. For example, if a filestore
838 is named "gannet", then this could easily be identified by the name:
844 RFC 1781 User Friendly Naming March 1995
847 Gannet, Computer Laboratory, Cambridge University, GB
849 In normal usage, this might lead to access (using a purported name)
852 FTAM gannet,cambridge
854 A second type of access is where the user identifies an Organisation
855 (Organisational Unit), and expects to obtain a default service. The
856 service is implied by the application, and should not require any
857 additional naming as far as the user is concerned. It is proposed
858 that this is supported by User Friendly Naming in the following way.
860 1. Determine that the purported name identifies a non-leaf object,
861 which is of object class Organisation or Organisational Unit or
864 2. Perform a single level search for Application Entities which
865 support the required application contexts. This assumes that all
866 services which are supporting default access for the organisation
867 are registered at one level below (possibly by the use of
868 aliases), and that other services (specific machines or parts of
869 the organisation) are represented further down the tree. This
870 seems to be a reasonable layout, and its utility can be evaluated
875 An experimental implementation of this has been written by Colin
876 Robbins. The example in Figure 1 shows that it can be very effective
877 at locating known individuals with a minimum of effort. This code has
878 been deployed within the "FRED" interface of the PSI Pilot [9], and
879 within an prototype interface for managing distribution lists. The
880 user reaction has been favourable:
882 Some issues have arisen from this experience:
884 o Where there is more than one level of Organisational Unit, and the
885 user guesses one which is not immediately below the organisation,
886 the algorithm works badly. There does not appear to be an easy
887 fix for this. It is not clear if this is a serious deficiency.
889 o Substring searching is currently done with leading and trailing
890 wildcards. As many implementations will not implement leading
891 wildcards efficiently, it may be preferable to only use trailing
892 wildcards. The effect of this on the algorithm needs to be
900 RFC 1781 User Friendly Naming March 1995
903 Implementors of this specification are encouraged to investigate
904 variants of the basic algorithm. A final specification should depend
905 on experience with such variants.
907 9. Relationship to other work
909 Colin Robbin's work on the interface "Tom" and implementation of a
910 distribution list interface strongly influenced this specification
913 Some of the ideas used here originally came from a UK Proposal to the
914 ISO/CCITT Directory Group on "New Name Forms" [2]. This defined, and
915 showed how to implement, four different types of names:
917 Typed and Ordered The current Distinguished Name is a restricted
918 example of this type of name.
956 RFC 1781 User Friendly Naming March 1995
959 -> t hales, csiro, australia
960 Found good match(es) for 'australia'
961 Found exact match(es) for 'csiro'
962 Please select from the following:
963 Trevor Hales, OC, HPCC, DIT, IICT, CSIRO, AU [y/n] ? y
964 The following were matched...
965 Trevor Hales, OC, HPCC, DIT, IICT, CSIRO, AU
967 -> g michaelson, queensland, au
968 Found exact match(es) for 'au'
969 Please select from the following:
970 University of Queensland, AU [y/n] ? y
971 Axolotl, AU [y/n] ? n
972 Please select from the following:
973 George Michaelson, Prentice Computer Centre, University of
976 Manager, University of Queensland, AU [y/n] ? n
977 The following were matched...
978 George Michaelson, Prentice Computer Centre, University of
981 -> r needham, cambridge
982 Found good match(es) for 'cambridge'
983 Please select from the following:
984 Roger Needham, Computer Lab, Cambridge University [y/n] ? y
985 The following were matched...
986 Roger Needham, Computer Lab, Cambridge University
989 Found good match(es) for 'kirstein'
990 The following were matched...
994 Figure 1: Example usage of User Friendly Naming
998 This is the type of name proposed here (with some extensions to allow
999 optional typing). It is seen as meeting the key user requirement of
1000 disliking typed names, and is efficient to implement.
1004 This sort of name is proposed by others as the key basis for user
1005 friendly naming. Neufeld shows how X.500 can be used to provide this
1006 [7], and Peterson proposes the Profile system to provide this [8].
1012 RFC 1781 User Friendly Naming March 1995
1015 The author contends that whilst typed naming is interesting for some
1016 types of searching (e.g., yellow page searching), it is less
1017 desirable for naming objects. This is borne out by operational
1018 experience with OSI Directories [3].
1020 Untyped and Unordered
1022 Surprisingly this form of name can be supported quite easily.
1023 However, a considerable gain in efficiency can be achieved by
1024 requiring ordering. In practice, users can supply this easily.
1025 Therefore, this type of name is not proposed.
1029 The following issues are noted, which would need to be resolved
1030 before this document is progressed as an Internet Standard.
1034 Whilst the intention of the notation is to allow for specification of
1035 alternate values, it inherently allows for ambiguous names to be
1036 specified. It needs to be demonstrated that problems of this
1037 characteristic are outweighed by other benefits of the notation.
1041 Determine that the specification is being implemented and used.
1045 Measurements on the performance implications of using this approach
1050 The utility of the algorithm, and possible variants, should be
1053 This format, and the procedures for resolving purported names, should
1054 be evolved to an Internet Standard. The syntax can be expected to be
1055 stable. In light of experience, the algorithm for resolving
1056 purported names may be changed.
1068 RFC 1781 User Friendly Naming March 1995
1073 [1] The Directory --- overview of concepts, models and services,
1074 1993. CCITT X.500 Series Recommendations.
1076 [2] S.E. Kille. New name forms, May 1989. ISO/IEC/JTC 21/ WG4/N797
1077 UK National Body Contribution to the Oslo Directory Meeting.
1079 [3] S.E. Kille. The THORN large scale pilot exercise. Computer
1080 Networks and ISDN Systems, 16(1):143--145, January 1989.
1082 [4] S.E. Kille. Using the OSI directory to achieve user friendly
1083 naming. Research Note RN/20/29, Department of Computer Science,
1084 University College London, February 1990.
1086 [5] Kille, S., "A String Representation of Distinguished Names", RFC
1087 1779, ISODE Consortium, March 1995.
1089 [6] S.E. Kille and C.J. Robbins. The ISO development environment:
1090 User's manual (version 7.0), July 1991. Volume 5: QUIPU.
1092 [7] G.W. Neufeld. Descriptive names in X.500. In SIGCOMM 89
1093 Symposiun Communications Architectures and Protocols, pages 64--
1096 [8] L.L. Petersen. The profile naming service. ACM Transactions on
1097 Computing Systems, 6(4):341--364, November 1988.
1099 [9] M.T. Rose. Realizing the White Pages using the OSI Directory
1100 Service. Technical Report 90--05--10--1, Performance Systems
1101 International, Inc., May 1990.
1124 RFC 1781 User Friendly Naming March 1995
1127 12. Security Considerations
1129 Security issues are not discussed in this memo.
1131 13. Author's Address
1141 Phone:+44-181-332-9091
1142 EMail: S.Kille@ISODE.COM
1145 O=ISODE Consortium, C=GB
1148 ISODE Consortium, GB
1180 RFC 1781 User Friendly Naming March 1995
1183 A. Pseudo-code for the matching algorithm
1185 The following pseudo-code is intended to clarify the matching
1186 algorithm. The language uses ASN.1 data types, with flow control
1187 "C"-like, but with keywords upper-cased.
1189 PurportedName ::= SEQUENCE OF String
1190 -- simplication, as attribute types can optionally be
1193 -- Each element of the Purported Name is a string
1194 -- which has been parsed from the BNF
1196 Attribute ::= SEQUENCE {
1197 type OBJECT IDENTIFIER,
1200 RDN ::= Attribute -- simplification, as can be multi-value
1202 DN ::= SEQUENCE OF RDN
1204 Environment ::= SEQUENCE OF DN
1206 EnvironmentList ::= SEQUENCE OF SEQUENCE {
1207 lower-bound INTEGER,
1208 upper-bound INTEGER,
1209 environment Environment }
1212 friendlyMatch(p: PurportedName; el: EnvironmentList): SET OF DN
1214 -- Find correct environment
1216 IF length(el) == 0 THEN return(NULL);
1218 IF length(p) <= head(el).upper-bound
1219 && length(p) >= head(el).lower-bound THEN
1220 return envMatch (p, head(el).environment);
1222 return(friendlyMatch(p, tail(el));
1225 envMatch(p: PurportedName; e: Environment): SET OF DN
1227 -- Check elements of environment
1228 -- in the defined order
1236 RFC 1781 User Friendly Naming March 1995
1239 IF length(e) == 0 THEN return(NULL);
1241 matches = purportedMatch(head(e).DN, p)
1242 IF matches != NULL THEN
1245 return(envMatch(p, tail(e));
1249 purportedMatch(base: DN; p: PurportedName): SET OF DN
1251 s: String = head(p);
1252 matches: SET OF DN = NULL;
1254 IF length(p) == 1 THEN
1255 IF length(base) == 0 THEN
1256 IF (matches = rootSearch(s)) != NULL THEN
1258 ELSE return(leafSearch(base, s, one-level);
1259 ELSE IF length(base) == 1 THEN
1260 IF (matches = intSearch(base, s)) != NULL THEN
1262 ELSE return(leafSearch(base, s, one-level);
1264 IF (matches = leafSearch(base, s, subtree)) !=
1265 NULL THEN return(matches);
1266 ELSE return(intsearch(base, s);
1269 IF length(base) == 0 THEN
1270 FOR x IN rootSearch(s) DO
1271 matches += (purportedMatch(x, tail(p));
1273 FOR x IN intSearch(base, s) DO
1274 matches += (purportedMatch(x, tail(p));
1292 RFC 1781 User Friendly Naming March 1995
1295 -- General. Might need to tighten the filter for short strings,
1296 -- in order to stop being flooded. Alternatively, this could be
1297 -- done if the loose search hits a size limit
1299 rootSearch(s: String): SET OF DN
1301 IF length(s) == 2 THEN
1302 return(search(NULL, one-level, s, {CountryName,
1303 FriendlyCountryName, OrganizationName},
1304 {exact}, {Country, Organisation}));
1305 -- test exact match only
1306 -- probably a country code
1308 return(search(NULL, one-level, s, {OrganizationName,
1309 FriendlyCountryName}, {substring, approx},
1310 {Country, Organisation}));
1314 intSearch( base: DN; s: String)
1316 IF present(base, OrgUnitName) THEN
1317 return(search(base, one-level, s, {OrgUnitName},
1318 {substring, approx}, {OrgUnit}));
1319 ELSE IF present(base, OrganisationName) THEN
1320 return(search(base, one-level, s, {OrgUnitName,
1321 LocalityName}, {substring, approx},
1322 {Organization, OrgUnit, Locality}));
1323 ELSE IF present(base, LocalityName) THEN
1324 return(search(base, one-level, s, {OrganisationName},
1325 {substring, approx}, {Locality});
1327 return(search(base, one-level, s, {OrganisationName,
1328 LocalityName}, {substring, approx},
1329 {Organisation, Locality}));
1333 present(d: DN; t: AttributeType): BOOLEAN
1336 IF x.type == t THEN return(TRUE);
1340 SearchScope := ENUMERATED (base-object, one-level, subtree)
1342 leafSearch(base: DN; s: String; search-scope: SearchScope)
1348 RFC 1781 User Friendly Naming March 1995
1352 return(search(base, search-scope, s, {CommonName, Surname,
1353 UserId}, {substring, approx}));
1356 search(base: DN; search-scope: SearchScope; s: string;
1357 alist SET OF AttributeType; matchtypes SET OF MatchType
1358 objectClasses SET OF ObjectClass OPTIONAL): SET OF DN
1360 -- mapped onto Directory Search, with OR conjunction
1363 return dNSelect (s, search-results, alist);
1366 read(base: DN; alist SET OF AttributeType): SET OF Attribute;
1368 -- mapped onto Directory Read
1369 -- Types repeated to deal with multiple values
1370 -- This would be implemented by returning selected info
1371 -- with the search operation
1374 dNSelect(s: String; dlist SET OF DN;
1375 alist: SET OF AttributeType):16SET0OF DN
1377 exact, good: SET OF DN;
1380 IF last(DN).Value == s THEN
1382 ELSE IF FOR y IN read(x, alist) DO
1383 IF y.value == s THEN
1386 IF exact != NULL THEN return(exact);
1387 IF good != NULL THEN return(good);
1388 return(userQuery(dlist));
1391 userQuery(dlist SET OF DN): SET OF DN
1393 -- pass back up for manual checking
1394 -- user can strip all matches to force progres....
1397 head() -- return first element of list
1398 tail() -- return list with first element removed
1404 RFC 1781 User Friendly Naming March 1995
1407 length() -- return size of list
1408 last() -- return last element of list
1410 Figure 2: Matching Algorithm