RFC 1484

Using the OSI Directory to achieve User Friendly Naming (OSI-DS 24 (v1.2))

📅 published July 1993, from ietf

RFC 1484: Using the OSI Directory to achieve User Friendly Naming (OSI-DS 24 (v1.2)) 🎀

okay bestie, here's the deets 💅 This RFC is from the Network Working Group, written by S. Hardcastle-Kille of the ISODE Consortium, and dated July 1993 📅. It's an Experimental doc, not a standard 🧪. The title block doesn't list anything it obsoletes or updates, so there's no drama there 🙅‍♀️

Status of this Memo

This memo defines an Experimental Protocol for the Internet community 🧪 It does not specify an Internet standard. The author wants discussion and suggestions for improvement 💬 For the standardization state and status of this protocol, check the current edition of the "IAB Official Protocol Standards" 📚 Distribution of this memo is unlimited 🌍

Abstract

the OSI Directory is supposed to have user friendly naming as a goal ✨ but a simple minded use of it doesn't get there 😬 Two things it misses:

  • A user oriented notation
  • Guessability

so this proposal sets out some conventions for writing names in a friendly way 🎀 and shows how to use them for really friendly naming 💖 That leads to a format for writing names down, plus procedures for resolving them 🔍 Basically, it lets directory names get passed between humans 🫶 The format here is identical to the one in [HK93], and these specs are meant to be compatible 🦋 Send comments to the author or to the discussion group: <osi-ds@CS.UCL.AC.UK> 💌

Table of Contents

   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 Figures

   1. Example usage of User Friendly Naming.......................... 18
   2. Matching Algorithm............................................. 25

List of Tables

   1. Local environment for private DUA.............................. 11
   2. Local environment for US Public DUA............................ 11

1. Why a notation is needed 🌸

lots of OSI Applications use Distinguished Names (DN) from the OSI Directory [CCI88] 📇 The main reason to have a notation for name format is to work with a user interface 🖥️ This spec is flirting with the sin of standardising interfaces 😱 but there are presentation aspects that are worth standardising anyway 💅

it's important to have a common format so names are easy to refer to 💌 You might put a directory name on a business card or in an email message 💼 There's a need for a format that supports human to human communication, and it has to be string based (not ASN.1) and user oriented 🗣️

in lots of cases, a user has to type in a name 📝 This notation is designed so that happens the same way across many user interfaces ✨ The idea is that you can just type the name in. No form filling or complicated dialogue 🙅‍♀️

you should be able to take the "human" description given at the meeting and use it directly 🤝 How that works will become clear later 🔮

this approach uses the syntax defined in RFC1485 for representing distinguished names [HK93] 📜 By relaxing some constraints on this specification, the argument goes, you get a more user oriented specification 💁 But this syntax can't be mapped algorithmically onto a distinguished name without using a directory 🧩

this notation is targeted at a general user oriented system, especially for representing the names of humans 👩‍💻 Other syntaxes may fit other uses of the directory better 🧐 For example, the OSF Syntax may suit some system oriented uses 💻 (It uses "/" as a separator and forms names to look like UNIX filenames 📁)

this notation is also targeted at names that follow a particular DIT structure, which is organisationally oriented 🏢 That may make it a bad fit for some types of application 🙃 There may be a need to extend it to handle fully geographical names more cleanly 🗺️

overall, this approach basically defines descriptive names on top of the primitive names the OSI Directory already gives you 🦋

to be continued 🎀

2. The Notation ✨

Okay bestie, the notation for this one is defined in [HK93] 💅. It gives you an unambiguous way to write a distinguished name, and this spec is designed to be used together with that format. Both come from the same piece of research work [Kil90] 🧚. Here are some examples so you can see the vibe.

The author's User Friendly Name (UFN) might be written:

Steve Hardcastle-Kille, Computer Science, University College
London, GB

or

S. Hardcastle-Kille, Computer Science, University College London,
GB

It can be folded too, maybe to show up in multi-column format 🌸:

Steve Hardcastle-Kille,
Computer Science,
University College London,
GB

Another UFN might be:

Christian Huitema, INRIA, FR

or

James Hacker,
Basingstoke,
Widget Inc,
GB

And this last one shows how you quote a comma inside an Organisation name 🎀:

L. Eagle, "Sue, Grabbit and Runn", GB

So a purported name is basically what a user types into an interface, which then gets resolved into one or more distinguished names 👀. A system should almost always store a name as a distinguished name. That's way more efficient, and it avoids the drama of purported names turning ambiguous when a new name shows up 😭. A user interface may display a distinguished name using the distinguished name notation. But it may also display a purported name when that's just more pleasing to the user ✨. Some examples of that:

  • Omission of the higher components of the distinguished name is not displayed (abbreviation).
  • Omission of attribute types, where the type is unlikely to be needed to resolve ambiguity.

The ways a purported name can differ from a distinguished name are next, so pay attention 🍓:

Type Omission

There are two cases of this 💜.

  • Schema defaulting. In this case, although the type is not present, a schema defaulting is used to deduce the type. The first two types of schema defaulting may be used to deduce a distinguished name without the use of the directory. The use of schema defaulting may be useful to improve the performance of UFN resolution. The types of schema defaulting are:
    • Default Schema
    • Context Dependent Default Schema
    • Data Dependent Default Schema
  • Omission of the type to be resolved by searching.

Default Schema

The attribute type of an attribute may always be present. This may 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 many common cases, no attribute types are needed. The following type hierarchy (schema) is assumed 🌈:

Common Name, (((Organisational Unit)*,  Organisation,) Country)

Explicitly typed RDNs may be inserted into this hierarchy at any point. The least significant component is always of type Common Name. Other types follow the defined organisational hierarchy. The following are equivalent 🦋:

Filestore Access, Bells, Computer Science,
University College London, GB

and

CN=Filestore Access, OU=Bells, OU=Computer Science,
O=University College London, C=GB

To interpret a distinguished name presented in this format, with some or all of the attributes with the type not specified, the types are derived according to the type hierarchy by the following algorithm 🧠:

  1. If the first attribute type is not specified, it is CommonName.
  2. If the last attribute type is not specified, it is Country.
  3. If there is no organisation explicitly specified, the last attribute with type not specified is of type Organisation.
  4. Any remaining attribute with type unspecified must be before an Organisation or OrganisationalUnit attribute, and is of type OrganisationalUnit.

To take a distinguished name and generate a name of this format with attribute types omitted, the following steps are followed 🫶:

  1. If the first attribute is of type CommonName, the type may be omitted.
  2. If the last attribute is of type Country, the type may be omitted.
  3. If the last attribute is of type Country, the last Organisation attribute may have the type omitted.
  4. All attributes of type OrganisationalUnit may have the type omitted, unless they are after an Organisation attribute or the first attribute is of type OrganisationalUnit.

Context Dependent Default Schema

The distinguished name notation defines a fixed schema for type defaulting. But it may be useful to have different defaults in different contexts 🌸. For example, the defaulting convention may be applied in a modified fashion to objects which are known not to be common name objects. This will always be followed if the least significant component is explicitly typed. In this case, the following hierarchy is followed:

((Organisational Unit)*,  Organisation,) Country

Data Dependent Defaulting

There are cases where it would be optimal to default according to the data 🔥. For example, in:

Einar Stefferud, Network Management Associates, CA, US

It would be useful to default "CA" to type State. This might be done by defaulting all two letter attributes under C=US to type State.

General Defaulting

A type may be omitted in cases where it does not follow a default schema hierarchy, and then type variants can be explored by searching. So a distinguished name could be represented by a uniquely matching purported name 🔍. For example:

James Hacker,
Basingstoke,
Widget Inc,
GB

Would match the distinguished name:

CN=James Hacker,
L=Basingstoke,
O=Widget Inc,
CN=GB

Abbreviation

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

Could be interpreted in the context of an organisational default.

Local Type Keywords

Local values can be used to identify types, in addition to the keywords defined in [HK93] 🎀. For example, "Organisation" may be recognised as an alternative to "O".

Component Omission

An intermediate component of the name may be omitted. Typically this will be an organisational unit 💅. For example:

Steve Hardcastle-Kille, University College London, GB

In some cases, this can be combined with abbreviation. For example:

Steve Hardcastle-Kille, University College London

Approximation

Approximate renditions or alternate values of one or more of the components will be supplied 🦋. For example:

Stephen Hardcastle-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 [HK93], 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 are given 🧐.

  1. Distinguished Name or DN. A representation of the distinguished name, according to the specification of [HK93].
  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. So 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:

  • The Distinguished Name is an unambiguous and stable reference to the user.
  • The DN will be used efficiently by the directory to obtain information.

Advantages of communicating the UFN are:

  • Redundant type information can be omitted (e.g., "California", rather than "State=California", where there is known to be no ambiguity).
  • 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 😩.
  • 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 📬.

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 ✨

Okay so every match happens inside a local environment 🏡. The environment is a sequence of names of non-leaf objects in the DIT, basically a cheat sheet of acceptable name abbreviations wherever the DUA is being used 💅. It also decides the order things get tried in 🎀. The environment should be controllable by the individual user, so you're the boss of it 👑.

The list is defined in the context of how many name components were supplied 🔢. That lets different heuristics fit different environments, so the approach can have the "right" behaviour 🦋.

In most cases the environment starts at a local point in the DIT and moves upwards 🌈. Table 1 shows an example for a typical local DUA, and it's giving very specific vibes 😭:

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

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

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

Table 2 gives the same kind of example, but for a US Public DUA 🇺🇸:

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

Table 2: Local environment for US Public DUA

4.2. Matching ✨

A purported name gets supplied, usually with a small number of components 🧩, and it gets matched in the context of an environment 🔍. When there are multiple components to match, you match them sequentially, one after another 🎯. If you get an unambiguous DN (distinguished name) 💫, the match carries on as if the full DN had been supplied in the first place.

Example time 🙈: say you supply Stephen Hardcastle-Kille, UCL in the context of environment GB. First, UCL resolves 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's an ambiguity (like if UCL made two matches), both paths get explored to see if the ambiguity can be resolved 🕵️. Eventually a set of names gets passed back to the user 💌.

Each component of the environment gets taken in turn 🔄. If the purported name has more components than the maximum depth, that environment element gets skipped. You'll see the advantage of this in an example 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. For example, S Hardcastle-Kille should be a good match of S. Hardcastle-Kille, S.E. Hardcastle-Kille or Steve Hardcastle-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 can be prompted. If there are multiple matches, more than one path may be followed 🛣️. There's also a shift/reduce type of choice: should any partial matches be followed, or should the next element of the environment be tried? 🤔 The following heuristics are suggested, and they 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. Next up: how attributes are matched at various levels of the DIT 🌳.

There is an issue of approximate matching 🌀. Sometimes it helps, and sometimes it 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 allows a distinction to be made between good and poor matches. It is important that, where an acronym exactly matches an organisation, 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, depending on the length of the supplied name. All of them 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 an exact match on country and friendly country.

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 are looking for organisational components (Organisation, Locality, Org Unit) 🏢. In some cases, private schema control will allow the system to determine which one is at the next level. In general this won't 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 the DN has no Organisation or Locality, filter on Organisation and Locality.
  2. If the DN has Org Unit, filter on Org Unit.
  3. If the DN has Organisation, filter on Locality and Org Unit.
  4. If the 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 ⚡.

Here are a few examples 🎈. 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 generates 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 🌟.)

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 reference either a leaf or a 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 as 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 you've 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 😵‍💫, so here are a few examples. They're 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 gets prompted for "Joseph Z. Bloggs" as the only possible match 🙌.

If "Computer Science" is supplied, first Physics, University College London, GB gets searched, and the user rejects the approximate match of "Colin Skin" 🙅. Then a subtree search of University College London, GB is made, looking for a person. Then a single level search is made looking for Org Unit, and Computer Science, University College London, GB is returned without prompting (exact match) 🎉.

Supplying "Steve Hardcastle-Kille" leads to a failed subtree search of Physics, University College London, GB, and then straight to a subtree search of University College London, GB. This leads to an exact value match, so a single entry is returned without prompting 💖.

If "Andrew Findlay, Brunel" is supplied, the first element of the environment is skipped, and a single level search of "Brunel" under "GB" finds Brunel University, GB. A subtree search for "Andrew Findlay" then gets initiated. This yields:

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 ✨

okay so this is where it gets really good 🦋 the whole point of this work is giving Organisations and Users a way to be identified, but applications need identifying too, and that's a related vibe 💖 if the Application is identified by an AET (Application Entity Title) whose RDN is Common Name, this specification just kinda flows naturally 🫶 like, say a filestore is named "gannet". it could be identified with this name:

      Gannet, Computer Laboratory, Cambridge University, GB

in normal usage, that could lead to access (using a purported name) like this:

      FTAM gannet,cambridge

second type of access: the user identifies an Organisation (Organisational Unit) and just wants a default service 🎀 the service is implied by the application, and the user should not have to do any additional naming as far as they're concerned. it's 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 🔥

Colin Robbins built an experimental implementation of this, and Figure 1 shows it can be super effective at finding known individuals with minimal effort 😭 this code got deployed within the "FRED" interface of the PSI Pilot [Ros90], and within a prototype interface for managing distribution lists 📋 the user reaction has been favourable 💅

some issues popped up from this experience, so let's spill 👀

  • 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.
  • Substring searching is currently done with leading and trailing wildcards. As many implementations will not implement leading 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] 🫶

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. this is the main character here 💅
  • 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 argues 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 backed up 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

Whilst the intention of the notation is to allow for specification of alternate values, it inherently allows for ambiguous names to be specified. It needs to be demonstrated that problems of this characteristic are outweighed by other benefits of the notation. 🤔

Utility

Determine that the specification is being implemented and used.

Performance

Measurements on the performance implications of using this approach should be made. 📊

Alogrithm

The utility of the algorithm, and possible variants, should be investigated.

this format, and the procedures for resolving purported names, should be evolved. The syntax can be expected to be stable. In light of experience, the algorithm for resolving purported names may be changed 🦋

11. References 📚

  • [CCI88] The Directory --- overview of concepts, models and services, December 1988. CCITT X.500 Series Recommendations.
  • [HK93] S.E. Hardcastle-Kille. A string representation of distinguished names. RFC 1485, Department of Computer 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 Directory Meeting.
  • [Kil89b] S.E. Kille. The THORN large scale pilot exercise. Computer Networks and ISDN Systems, 16(1):143--145, January 1989.
  • [Kil90] S.E. Kille. Using the OSI directory to achieve user friendly naming. Research Note RN/20/29, Department of Computer Science, University College London, February 1990.
  • [KRRT90] S.E. Kille, C.J. Robbins, M. Roe, and A. Turland. The ISO 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, pages 64--71, September 1989.
  • [Pet88] L.L. Petersen. The profile naming service. ACM Transactions on Computing Systems, 6(4):341--364, November 1988.
  • [Ros90] M.T. Rose. Realizing the White Pages using the OSI Directory Service. Technical Report 90--05--10--1, Performance Systems International, Inc., May 1990.

12. Security Considerations 💀

Security issues are not discussed in this memo. 💀

13. Author's Address 💌

here's where to find the author, bestie 🧚

   Steve Hardcastle-Kille
   ISODE Consortium
   P.O. Box 505
   London
   SW11 1DX
   England

   Phone:+44-71-223-4062

   EMail:  S.Kille@ISODE.COM

   DN: CN=Steve Hardcastle-Kille,
   O=ISODE Consortium, C=GB

   UFN: S. Hardcastle-Kille,
   ISODE Consortium, GB

A. Pseudo-code for the matching algorithm 🧮

the following pseudo-code is intended to clarify the matching algorithm. The language uses ASN.1 data types, with flow control "C"-like,but with keywords upper--cased. 💖

   ____________________________________________________________________

PurportedName ::= SEQUENCE OF String
                -- simplication, as attribute types can optionally be
                -- specified

                -- Each element of the Purported Name is a string
                -- which has been parsed from the BNF

Attribute ::= SEQUENCE {                                            10
        type OBJECT IDENTIFIER,
        value ANY }

RDN ::= Attribute -- simplification, as can be multi-value

DN ::= SEQUENCE OF RDN
Environment ::= SEQUENCE OF DN

                                                                    20
EnvironmentList ::= SEQUENCE OF SEQUENCE {
                        lower-bound INTEGER,
                        upper-bound INTEGER,
                        environment Environment }


friendlyMatch(p:  PurportedName; el:  EnvironmentList):    SET OF DN
{
                                -- Find correct environment
                                                                    30
        IF length(el) == 0 THEN return(NULL);

        IF length(p) <= head(el).upper-bound
                        && length(p) >= head(el).lower-bound THEN
                return envMatch (p, head(el).environment);
        ELSE
                return(friendlyMatch(p, tail(el));
}
                                                                    40
envMatch(p:  PurportedName; e:  Environment):    SET OF DN
{
                                -- Check elements of environment
                                -- in the defined order

        matches:  SET OF DN;

        IF length(e) == 0 THEN return(NULL);

        matches = purportedMatch(head(e).DN, p)                     50
        IF matches != NULL THEN
                return(matches);
        ELSE
                return(envMatch(p, tail(e));
}
purportedMatch(base:  DN; p:  PurportedName):  SET OF DN
{
        s:  String = head(p);                                       60
        matches:  SET OF DN = NULL;

        IF length(p) == 1 THEN
                IF length(base) == 0 THEN
                        IF (matches = rootSearch(s)) != NULL THEN
                                return(matches);
                        ELSE return(leafSearch(base, s, one-level);
                ELSE IF length(base) == 1 THEN

                        IF (matches = intSearch(base, s)) != NULL THEN
                                return(matches);                    70
                        ELSE return(leafSearch(base, s, one-level);
                ELSE
                        IF (matches = leafSearch(base, s, subtree)) !=
                NULL THEN
                                return(matches);
                        ELSE return(intsearch(base, s);

        IF length(base) == 0 THEN
                FOR x IN rootSearch(s) DO
                        matches += (purportedMatch(x, tail(p));     80
        ELSE

                FOR x IN intSearch(base, s) DO
                        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 be
-- done if the loose search hists a size limit

rootSearch(s:  String):  SET OF DN
{
        IF length(s) == 2 THEN
                return(search(NULL, one-level, s, {CountryName,
                        FriendlyCountryName, OrganizationName},
                        {exact}, {Country, Organisation}));
                        -- test exact match only
                        -- probably a country code
        ELSE
                return(search(NULL, one-level, s, {OrganizationName,
                        FriendlyCountryName}, {substring, approx},
                        {Country, Organisation}));
}

intSearch( base:  DN; s:  String)
{
        IF present(base, OrgUnitName) THEN
                return(search(base, one-level, s, {OrgUnitName},
                        {substring, approx}, {OrgUnit}));
        ELSE IF present(base, OrganisationName) THEN
                return(search(base, one-level, s, {OrgUnitName,
                        LocalityName}, {substring, approx},
                        {Organization, OrgUnit, Locality}));
        ELSE IF present(base, LocalityName) THEN
                return(search(base, one-level, s, {OrganisationName},
                        {substring, approx}, {Locality});

        ELSE
                return(search(base, one-level, s, {OrganisationName,
                        LocalityName}, {substring, approx},
                        {Organisation, Locality}));
}
present(d:  DN; t:  AttributeType):  BOOLEAN
{
        FOR x IN d DO
                IF x.type == t THEN return(TRUE);
        return(FALSE);
}

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}));
}

search(base:  DN; search-scope:  SearchScope; s:  string;
        alist SET OF AttributeType; matchtypes SET OF MatchType
        objectClasses SET OF ObjectClass OPTIONAL): SET OF DN
{
        -- mapped onto Directory Search, with OR conjunction
        -- of filter items

        return dNSelect (s, search-results, alist);
}
read(base:  DN; alist SET OF AttributeType):  SET OF Attribute;
{
        -- mapped onto Directory Read
        -- Types repeated to deal with multiple values
        -- This would be implemented by returning selected info
        -- with the search operation
}
dNSelect(s:  String; dlist SET OF DN; alist:  SET OF AttributeType):
SET OF DN
{
        exact, good:  SET OF DN;

        FOR x IN dlist DO
                IF last(DN).Value == s THEN
                        exact += x;
                ELSE IF FOR y IN read(x, alist) DO
                        IF y.value == s THEN
                                good += x;

        IF exact != NULL THEN return(exact);
        IF good != NULL THEN return(good);
        return(userQuery(dlist));
}
userQuery(dlist SET OF DN): SET OF DN
{
        -- pass back up for manual checking
        -- user can strip all matches to force progres....
}
head()    -- return first element of list
tail()    -- return list with first element removed
length()  -- return size of list
last()    -- return last element of list

Figure 2: Matching Algorithm 💅✨

📦 where this page comes from