RFC 1781
Using the OSI Directory to Achieve User Friendly Naming
Using the OSI Directory to Achieve User Friendly Naming ✨
okay bestie, this one is RFC 1781 🎀 It came out in March 1995, it's a Standards Track doc from the Network Working Group, and S. Kille of the ISODE Consortium wrote it 🫶 It obsoletes RFC 1484, and the title block doesn't list anything it updates 💅
Status of this Memo
this doc specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🦋 for the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚 and distribution of this memo is unlimited 🌈
Abstract
so the OSI Directory is supposed to be user friendly, and that's the whole goal 🥺 but a simple minded usage of the directory doesn't get there. two things it misses:
- A user oriented notation
- Guessability
this proposal sets out some conventions for representing names in a friendly manner, and shows how they can be used to get really friendly naming 💖 that leads to a standard format for representing names, plus procedures to resolve them ✨ the end result is a spec that lets directory names be passed around between humans 🧚 the format here is identical to the one defined in [5], and these specs are meant to be compatible 🫶
Table of Contents
1. Why a notation is needed ................................... 2
2. The Notation ............................................... 3
3. Communicating Directory Names .............................. 7
4. Matching a purported name .................................. 9
4.1 Environment .......................................... 9
4.2 Matching ............................................. 10
4.3 Top Level ............................................ 12
4.4 Intermediate Level ................................... 13
4.5 Bottom Level ......................................... 14
5. Examples ................................................... 14
6. Support required from the standard ......................... 15
7. Support of OSI Services .................................... 15
8. Experience ................................................. 16
9. Relationship to other work ................................. 17
10. Issues ..................................................... 19
11. References ................................................. 20
12. Security Considerations .................................... 21
13. Author's Address ........................................... 21
A. Pseudo-code for the matching algorithm ..................... 22
List of Figures
1. Example usage of User Friendly Naming ................ 18
2. Matching Algorithm ................................... 22
List of Tables
1. Local environment for private DUA .................... 10
2. Local environment for US Public DUA .................. 111. Why a notation is needed 🦋
tbh a LOT of OSI applications use Distinguished Names (DN) from the OSI Directory [1] 💅 the main reason to have a notation for the name format is so you can interact with a user interface 🖥️ this spec is dangerously close to the sin of standardising interfaces 😱 but there are some presentation aspects that are actually worth standardising, so we're doing those 🫶
it's important to have a common format so names are easy to refer to 📇 like putting one on a business card or in an email message 💌 humans need to be able to talk to each other with these names, so the format has to be string based (not ASN.1) and user oriented 🌸
a user is gonna have to input a name a LOT 😭 this notation lets that happen in a uniform way across tons of user interfaces ✨ the vibe is that you can just type the name in 🎀 no form filling, no complicated dialogue, none of that 🙅♀️ you should be able to take the "human" description given at the meeting and use it directly 🍓 how that works will make sense later, I promise 🔥
this approach uses the syntax defined in [5] for representing distinguished names 📖 by relaxing some of the constraints on that spec, you get a more user oriented result 💜 but this syntax can't be mapped onto a distinguished name algorithmically without using a directory 💀
this notation is aimed at a general user oriented system, especially for representing the names of humans 🧑🤝🧑 other syntaxes might suit other uses of the directory better 🌈 for example, the OSF Syntax might be a better fit for some system oriented uses ⭐
(the OSF Syntax uses / as a separator, and forms names in a manner intended to resemble UNIX filenames).
this notation is also targeted at names that follow a particular DIT structure, which is organisationally oriented 🏢 that could make it a bad fit for some types of application 🙈 there might be a requirement to extend this notation to deal more cleanly with fully geographical names 🗺️
basically, this approach defines descriptive names on top of the primitive names that the OSI Directory already defines 🧚👑
2. The Notation 💖
okay so the notation used in this spec is defined over in [5] 💅 it gives us an unambiguous way to write a distinguished name, and this spec is built to be used together with that format. both specs came out of the same piece of research work [4] 🧚 here are some examples so you can see the vibe. the author's User Friendly Name (UFN) might look like:
Steve Kille, Computer Science, University College London, GBor
S. Kille, Computer Science, University College London, GBit can also get folded, which is handy if you're displaying it in multi-column format 📰
Steve Kille,
Computer Science,
University College London,
GBanother UFN could be:
Christian Huitema, INRIA, FRor
James Hacker,
Basingstoke,
Widget Inc,
GBand the final example shows how you quote a comma inside an Organisation name 🙈
L. Eagle, "Sue, Grabbit and Runn", GBa purported name is what a user types into an interface so it can be resolved into one or more distinguished names. a system should almost always store a name as a distinguished name 💾 that's more efficient, and it avoids problems where a purported name gets ambiguous once a new name shows up. a user interface can display a distinguished name using the DN notation, but it's allowed to display a purported name when that'll look more pleasing to the user. examples of that are:
- 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.
here's how a purported name can vary from a distinguished name 👀
Type Omission
there are two cases of this 🎀
- Schema defaulting. In this case, the type isn't present, but 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 using the directory. Using schema defaulting may be useful for improving 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 can be done to emphasise the type structure of a name 💜 in some cases the typing can be left out, and it's done in a way that means lots of common cases don't need attribute types at all. the following type hierarchy (schema) is assumed:
Common Name, (((Organisational Unit)*, Organisation,) Country).explicitly typed RDNs can be slotted into this hierarchy at any point. the least significant component is always of type Common Name, and the other types follow the defined organisational hierarchy. these are equivalent:
Filestore Access, Bells, Computer Science,
University College London, GBand
CN=Filestore Access, OU=Bells, OU=Computer Science,
O=University College London, C=GBto interpret a distinguished name presented in this format, with some or all of the attribute types not specified, the types get derived from the hierarchy using this algorithm 🧮
- If the first attribute type is not specified, it is CommonName.
- If the last attribute type is not specified, it is Country.
- If there is no organisation explicitly specified, the last attribute with type not specified is of type Organisation.
- Any remaining attribute with type unspecified must be before an Organisation or OrganisationalUnit attribute, and is of type OrganisationalUnit.
to go the other way, taking a distinguished name and generating a name in this format with the attribute types omitted, you follow these steps ✨
- If the first attribute is of type CommonName, the type may be omitted.
- If the last attribute is of type Country, the type may be omitted.
- If the last attribute is of type Country, the last Organisation attribute may have the type omitted.
- 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 one fixed schema for type defaulting, but it can be useful to have different defaults in different contexts 🎭 for example, the defaulting convention may be applied in a modified fashion to objects that 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,) CountryData Dependent Defaulting
there are cases where it would be optimal to default according to the data itself 🧠 for example, in:
Einar Stefferud, Network Management Associates, CA, USit 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 doesn't 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,
GBwould match the distinguished name:
CN=James Hacker,
L=Basingstoke,
O=Widget Inc,
C=GBAbbreviation
some of the more significant components of the DN get left out, and then get defaulted in some way (e.g., relative to a local context) 🏠 for example:
Steve Killecould 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 [5] 🗝️ for example, "Organisation" may be recognised as an alternative to "O".
Component Omission
an intermediate component of the name may be omitted, and typically that'll be an organisational unit 🧩 for example:
Steve Kille, University College London, GBin some cases this can be combined with abbreviation too:
Steve Kille, University College LondonApproximation
approximate renditions or alternate values of one or more of the components will be supplied 🌈 for example:
Stephen Kille, CS, UCL, GBor
Steve Keill, Comp Sci, Univarstiy College London, GBFriendly Country
a "friendly country name" can be used instead of the ISO 3166 two letter code 🌍 for example:
UK; USA; France; Deutchland3. Communicating Directory Names ✨
okay so the goal of this standard is to give us a means of communicating directory names 📮 two approaches are given: one defined in [5], and the other right here. a future version of these specs may contain only one of the approaches, or recommend using one approach. you can usually tell which approach is being used just by looking, since 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 are laid out below 💜
- Distinguished Name or DN. A representation of the distinguished name, according to the specification of [5].
- User Friendly Name or UFN. A purported name, which is expected to unambiguously resolve onto the distinguished name.
when a UFN is communicated, pick a form that'll efficiently and unambiguously resolve onto a distinguished name 🎯 so it's reasonable to omit types, or to use alternate values that will unambiguously identify the entry in question (e.g., by use of an alternate value of the RDN attribute type). it's not reasonable to use keys that are (or are likely to become) ambiguous 🚫 the approach 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 that might be either a DN or UFN. an example of appropriate usage of both forms is given in the Section that 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's 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, so 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's 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:
- Use type omission only, but otherwise require the value of the RDN attribute to be present.
- Require each RDN to be identified as in 1), or by an exact match on an alternate value of the RDN attribute.
these algorithms don't offer the flexibility of the default algorithm proposed, but they give many of the benefits of the approach in a very simple manner ✨
the major utility of the purported name is 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's 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 multiple matches. this should also be the case where a component of the name did not "match very well".
there's an assumption that the user will simply enter the name correctly 🙏 the purported name variants are designed to make this happen! there's no need for fancy window based interfaces or form filling for many applications of the directory. note that 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 bestie, so every match happens inside a local environment 🏠. The environment is basically a list of non-leaf objects in the DIT (the directory tree) that your DUA uses as a list of acceptable name shortcuts ✨. It should be controllable by the individual user 💖, and it also sets the order things get tried in 🎀.
The list is defined in terms of how many name components were supplied, which lets the heuristics be tuned so the approach has the "right" behaviour 🦋. Usually the environment starts at a local point in the DIT and then moves upwards 🚀. Tables 1 and 2 (in 4.2 below) show examples. Table 1 is for a typical local DUA with these 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: Most significant component is first assumed to be a national organisation, then a department (this might be reversed in some organisations), and finally a country. 🌍
- Three or more components: The most significant component is first assumed to be a country, then a national organisation, and finally a department. 💅
4.2. Matching ✨
A purported name will be supplied, usually with a small number of components, and it gets matched in the context of an environment 🔍. If there are multiple components to be matched, they get matched sequentially. If an unambiguous DN is determined, the match continues as if the full DN had been supplied. For example, if
+-----------+--------------------------------------+
|Number of |Environment |
|Components | |
+-----------+--------------------------------------+
|1 |Physics, University College London, GB|
| |University College London, GB |
| |GB |
+-----------+--------------------------------------+
|2 |GB |
| |University College London, GB |
| |-- |
+-----------+--------------------------------------+
|3+ |-- |
| |GB |
| |University College London, GB |
+-----------+--------------------------------------+
Table 1: Local environment for private DUA +------------+-----------+
| Number of |Environment|
| Components | |
+------------+-----------+
| 1,2 | US |
| | CA |
| | -- |
+------------+-----------+
| 3+ | -- |
| | US |
| | CA |
+------------+-----------+
Table 2: Local environment for US Public DUASay you're matching Stephen Kille, UCL in the context of environment GB. First, UCL gets resolved to the distinguished name University College London, GB 🎯.
Then the next component of the purported name is taken to determine the final name. If there's an ambiguity (e.g., if UCL had made two matches, both paths are explored to see if the ambiguity can be resolved. Eventually a set of names gets passed back to the user 🙌.
Each component of the environment is taken in turn. If the purported name has more components than the maximum depth, the environment element is skipped. The advantage of this will be seen in the example given later 👀.
A match of a name is considered to have three levels:
- Exact: A DN is specified exactly. 💯
- Good: Initially, a match should be considered good if it is unambiguous, and exactly matches an attribute value in the entry. For human names, a looser metric is probably desirable (e.g.,
S Killeshould be a good match ofS. Kille,S.E. KilleorSteve Killeeven if these are not explicit alternate values). 🫶 - Poor: Any other substring or approximate match. 🥲
Following a match, the reference can be followed, or the user prompted. If there are multiple matches, more than one path may be followed. There'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, which may be modified in the light of experience. The overall aim is to resolve cleanly specified names with a minimum of fuss, but give sufficient user control to prevent undue searching and delay 🛑.
- Always follow an exact match. ✅
- Follow all good matches if there are no exact matches. 👯
- 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. 🙅♀️
- Automatically move to the next element of the environment if no matches are found. ➡️
When the final component is matched, a set of names will be identified. If none are identified, proceed to the next environment element. If the user rejects all of the names, processing of the next environment element should be confirmed.
The exact approach to matching will depend on the level of the tree at which matching is being done. We can now consider how attributes are matched at various levels of the DIT 🌳.
There is an issue of approximate matching. Sometimes it helps, and sometimes 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 will allow a distinction to be made between good and poor matches. It is important that where, for example, an acronym exactly matches an organisation, the user is not prompted about other organisations where it matches as a substring. Main character energy: the exact match wins 👑.
4.3. Top Level 🔝
In this case, a match is being done at the root of the DIT. Three approaches are suggested, dependent on the length of the supplied name. All lead to a single level search of the top level of the DIT 🧭.
Exactly 2
This is assumed to be a 3166 two letter country code, or an exact match on a friendly country or organisation (e.g., UK or UN). Do exact match on country and friendly country. 🇬🇧
Greater than 2
Make an approximate and substring match on friendly country and organisation. 🔎
4.4. Intermediate Level 🧩
Once the root level has been dealt with, intermediate levels will be looking for organisational components (Organisation, Locality, Org Unit). In some cases, private schema control will allow the system to determine which is at the next level. In general this 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.
- If DN has no Organisation or Locality, filter on Organisation and Locality. 🫠
- If DN has Org Unit, filter on Org Unit. 🎯
- If DN has Organisation, filter on Locality and Org Unit. 🏢
- 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 🏎️. Here are a few examples, where a base object has been determined (either by being the environment or by partial resolution of a purported name), and the next element of a purported name is being considered. This will generate a single level search. What varies is the types being filtered against. If the DN is:
University College London, GB
the search should be for Org Unit or Locality. If the DN is:
Organisation=UN
the search should be for Org Unit or Locality.
There may be some improvements with respect to very short keys. Not making approximate or substring matches in these cases seems sensible (it might be desirable to allow "*" as a part of the purported name notation.) ✨
4.5. Bottom Level 🍓
The "Bottom Level" is to deal with leaf entries in the DIT. This will often be a person, but it 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 I have resolved a purported name to the distinguished name University College London, GB and have a single component Bloggs, this will generate a subtree search. 🫧
5. Examples ✨
This is all somewhat confusing, so a few examples are given 🥴. These are all in the context of the environment shown in Table 1 on Page 13.
If "Joe Bloggs" is supplied, a subtree search of Physics, University College London, GB will be made, and the user will be prompted for "Joseph Z. Bloggs" as the only possible match 🙋♀️.
If "Computer Science" is supplied, first Physics, University College London, GB will be searched, and the user will reject the approximate match of "Colin Skin" 🙅. Then a subtree search of University College London, GB will be made, looking for a person. Then a single level search will be made looking for Org Unit, and Computer Science, University College London, GB will be returned without prompting (exact match) 💖.
Supplying "Steve Kille" will lead to a failed subtree search of Physics, University College London, GB and lead straight to a subtree search of University College London, GB. This will lead to an exact value match, and so a single entry returned without prompting 🎀.
If "Andrew Findlay, Brunel" is supplied, the first element of the environment will be skipped. A single level search of "Brunel" under "GB" will find Brunel University, GB, and a subtree search for "Andrew Findlay" gets initiated. This will yield:
Andrew Findlay, Computing and Media Services, Brunel University, GBDr 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's needed is already there! 🥹 It would be useful to have "friendly country name" as a standard attribute 💜.
7. Support of OSI Services ✨
okay so the main goal here is giving Organisations and Users a way to be identified 💖. Identifying applications is a related thing too, and it's giving! When the Application is identified by an AET (Application Entity Title) with an RDN of Common Name, this spec just kinda fits naturally 🎀. Like, if a filestore is named "gannet", it could be identified with this name:
Gannet, Computer Laboratory, Cambridge University, GBIn normal usage, that might lead to accessing it (using a purported name) like this:
FTAM gannet,cambridgeThe second type of access 🦋 is where the user identifies an Organisation (or Organisational Unit) and just expects to get a default service. The service is implied by the application, so it should not require any additional naming as far as the user is concerned. This is supported by User Friendly Naming in the following way 💅:
- Figure out that the purported name identifies a non-leaf object which is of object class
OrganisationorOrganisational UnitorLocality🔍. - Do 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 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 🔬
okay so Colin Robbins wrote an experimental implementation of this 🧑💻. The example in Figure 1 shows that it can be super effective at locating known individuals with a minimum of effort ✨. This code got deployed in the "FRED" interface of the PSI Pilot [9], and also in a prototype interface for managing distribution lists. The user reaction has been favourable 🥰:
Some issues have popped up from this experience 🙈:
- 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 🧠.
9. Relationship to other work 🌸
Colin Robbin's work on the interface "Tom" and implementation of a distribution list interface strongly influenced this specification [6] 🫶.
Some of the ideas used here originally came from a UK Proposal to the ISO/CCITT Directory Group on "New Name Forms" [2]. 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.
-> 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 NamingUntyped and Ordered
This is the type of name proposed here (with some extensions to allow optional typing). It is seen as meeting the key user requirement of disliking typed names, and is efficient to implement 💜.
Typed and Unordered
This sort of name is proposed by others as the key basis for user friendly naming. Neufeld shows how X.500 can be used to provide this [7], and Peterson proposes the Profile system to provide this [8].
The author contends that whilst typed naming is interesting for some types of searching (e.g., yellow page searching), it is less desirable for naming objects. This is borne out by operational experience with OSI Directories [3] 📊.
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 to an Internet Standard. The syntax can be expected to be stable. In light of experience, the algorithm for resolving purported names may be changed 🌟.
11. References 📚
[1] The Directory --- overview of concepts, models and services, 1993. CCITT X.500 Series Recommendations.
[2] S.E. Kille. New name forms, May 1989. ISO/IEC/JTC 21/ WG4/N797 UK National Body Contribution to the Oslo Directory Meeting.
[3] S.E. Kille. The THORN large scale pilot exercise. Computer Networks and ISDN Systems, 16(1):143--145, January 1989.
[4] 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.
[5] Kille, S., "A String Representation of Distinguished Names", RFC 1779, ISODE Consortium, March 1995.
[6] S.E. Kille and C.J. Robbins. The ISO development environment: User's manual (version 7.0), July 1991. Volume 5: QUIPU.
[7] G.W. Neufeld. Descriptive names in X.500. In SIGCOMM 89 Symposiun Communications Architectures and Protocols, pages 64--71, September 1989.
[8] L.L. Petersen. The profile naming service. ACM Transactions on Computing Systems, 6(4):341--364, November 1988.
[9] 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. This is serious business, bestie, so don't skip past it 😬.
13. Author's Address 📮
Steve Kille
ISODE Consortium
The Dome
The Square
Richmond, Surrey
TW9 1DT
England
Phone:+44-181-332-9091
EMail: S.Kille@ISODE.COM
DN: CN=Steve Kille,
O=ISODE Consortium, C=GB
UFN: S. Kille,
ISODE Consortium, GBA. 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 {
type OBJECT IDENTIFIER,
value ANY }
RDN ::= Attribute -- simplification, as can be multi-value
DN ::= SEQUENCE OF RDN
Environment ::= SEQUENCE OF DN
EnvironmentList ::= SEQUENCE OF SEQUENCE {
lower-bound INTEGER,
upper-bound INTEGER,
environment Environment }
friendlyMatch(p: PurportedName; el: EnvironmentList): SET OF DN
{
-- Find correct environment
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));
}
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)
IF matches != NULL THEN
return(matches);
ELSE
return(envMatch(p, tail(e));
}
purportedMatch(base: DN; p: PurportedName): SET OF DN
{
s: String = head(p);
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);
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));
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 hits 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)okay bestie, the search logic is about to get SO dramatic 💅 this is the part where the algorithm picks its favorite result 👑
{
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}));
}Next up is the little helper that checks whether an attribute type is already sitting in a DN, aka the present() check 🧚
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
}And now the dNSelect moment, where the exact matches get the crown and everything else has to fight for second place 👑🔥
dNSelect(s: String; dlist SET OF DN;
alist: SET OF AttributeType):16SET0OF 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 listFigure 2: Matching Algorithm
📦 where this page comes from
- ietf: rfc1781 1995-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms