RFCs in HTML Format


RFC 1484

Network Working Group                               S. Hardcastle-Kille
Request for Comments: 1484                             ISODE Consortium
                                                              July 1993


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









Hardcastle-Kille                                                [Page 1]

RFC 1484 User Friendly Naming July 1993 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 Many OSI Applications make use of Distinguished Names (DN) as defined in the OSI Directory [CCI88]. The main reason for having a notation for name format is to interact with a user interface. This specification is coming dangerously close to the sin of standardising interfaces. However, there are aspects of presentation which it is desirable to standardise. It is important to have a common format to be able to conveniently refer to names. This might be done to represent a directory name on a business card or in an email message. There is a need for a format to support human to human communication, which must be string based (not ASN.1) and user oriented. Hardcastle-Kille [Page 2]
RFC 1484 User Friendly Naming July 1993 In very many cases, a user will be required to input a name. This notation is designed to allow this to happen in a uniform manner across many user interfaces. The intention is that the name can just be typed in. There should not be any need to engage in form filling or complex dialogue. It should be possible to take the "human" description given at the meeting, and use it directly. The means in which this happens will become clear later. This approach uses the syntax defined in RFC1485 for representing distinguished names [HK93]. By relaxing some of the constraints on this specification, it is argued that a more user oriented specification is produced. However, this syntax cannot be mapped algorithmically onto a distinguished name without the use of a directory. This notation is targeted towards a general user oriented system, and in particular to represent the names of humans. Other syntaxes may be more appropriate for other uses of the directory. For example, the OSF Syntax may be more appropriate for some system oriented uses. (The OSF Syntax uses "/" as a separator, and forms names in a manner intended to resemble UNIX filenames). This notation is targeted towards names which follow a particular DIT structure: organisationally oriented. This may make it inappropriate for some types of application. There may be a requirement to extend this notation to deal more cleanly with fully geographical names. This approach effectively defines a definition of descriptive names on top of the primitive names defined by the OSI Directory. 2. The Notation The notation used in this specification is defined in [HK93]. This notation defines an unambiguous representation of distinguished name, and this specification is designed to be used in conjunction with this format. Both specifications arise from the same piece of research work [Kil90]. Some examples of the specification are given here. The author's User Friendly Name (UFN) might be written: Steve Hardcastle-Kille, Computer Science, University College London, GB or Hardcastle-Kille [Page 3]
RFC 1484 User Friendly Naming July 1993 S. Hardcastle-Kille, Computer Science, University College London, GB This may be folded, perhaps to display in multi-column format. For example: Steve Hardcastle-Kille, Computer Science, University College London, GB Another UFN might be: Christian Huitema, INRIA, FR or James Hacker, Basingstoke, Widget Inc, GB The final example shows quoting of a comma in an Organisation name: L. Eagle, "Sue, Grabbit and Runn", GB A purported name is what a user supplies to an interface for resolution into one or more distinguished names. A system should almost always store a name as a distinguished name. This will be more efficient, and avoid problems with purported names which become ambiguous when a new name appears. A user interface may display a distinguished name, using the distinguished name notation. However, it may display a purported name in cases where this will be more pleasing to the user. Examples of this might be: o Omission of the higher components of the distinguished name are not displayed (abbreviation). o Omission of attribute types, where the type is unlikely to be needed to resolve ambiguity. The ways in which a purported name may vary from a distinguished name are now described: Hardcastle-Kille [Page 4]
RFC 1484 User Friendly Naming July 1993 Type Omission There are two cases of this. o 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 o 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 interpet 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. Hardcastle-Kille [Page 5]
RFC 1484 User Friendly Naming July 1993 2. If the last attribute type is not specified, it is Country. 3. If there is no organisation explicitly specified, the 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. 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. Hardcastle-Kille [Page 6]
RFC 1484 User Friendly Naming July 1993 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. Thus 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 Hardcastle-Kille [Page 7]
RFC 1484 User Friendly Naming July 1993 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 is 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. Thus it is reasonable to omit types, or to use alternate values which will unambiguously identify the entry in question (e.g., by use of an alternate value of the RDN attribute type). It is not reasonable to use keys which are (or are likely to become) ambiguous. The approach used should be implicit from the context, rather than wired into the syntax. The terms "Directory Name" and "X.500 Name" should be used to refer to a name which might be either a DN or UFN. An example of appropriate usage of both forms is given in the Section which defines the Author's location in section 12. Hardcastle-Kille [Page 8]
RFC 1484 User Friendly Naming July 1993 Advantages of communicating the DN are: o The Distinguished Name is an unambiguous and stable reference to the user. o The DN will be used efficiently by the directory to obtain information. Advantages of communicating the UFN are: o Redundant type information can be omitted (e.g., "California", rather than "State=California", where there is known to be no ambiguity. o Alternate values can be used to identify a component. This might be used to select a value which is meaningful to the recipient, or to use a shorter form of the name. Often the uniqueness requirements of registration will lead to long names, which users will wish to avoid. o Levels of the hierarchy may be omitted. For example in a very small organisation, where a level of hierarchy has been used to represent company structure, and the person has a unique name within the organisation. Where UFN form is used, it is important to specify an unambiguous form. In some ways, this is analogous to writing a postal address. There are many legal ways to write it. Care needs to be taken to make the address unambiguous. 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. Hardcastle-Kille [Page 9]
RFC 1484 User Friendly Naming July 1993 The major utility of the purported name is to provide the important "user friendly" characteristic of guessability. A user will supply a purported name to a user interface, and this will be resolved onto a distinguished name. When a user supplies a purported name there is a need to derive the DN. In most cases, it should be possible to derive a single name from the purported name. In some cases, ambiguities will arise and the user will be prompted to select from a multiple matches. This should also be the case where a component of the name did not "match very well". There is an assumption that the user will simply enter the name correctly. The purported name variants are designed to make this happen! There is no need for fancy window based interfaces or form filling for many applications of the directory. Note that the fancy interfaces still have a role for browsing, and for more complex matching. This type of naming is to deal with cases where information on a known user is desired and keyed on the user's name. 4.1 Environment All matches occur in the context of a local environment. The local environment defines a sequence of name of a non-leaf objects in the DIT. This environment effectively defines a list of acceptable name abbreviations where the DUA is employed. The environment should be controllable by the individual user. It also defines an order in which to operate. This list is defined in the context of the number of name components supplied. This allows varying heuristics, depending on the environment, to make the approach have the "right" behaviour. In most cases, the environment will start at a local point in the DIT, and move upwards. Examples are given in Tables 1 and 2. Table 1 shows an example for a typical local DUA, which has the following characteristics: One component Assumed first to be a user in the department, then a user or department within the university, the 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. Hardcastle-Kille [Page 10]
RFC 1484 User Friendly Naming July 1993 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 +--------------------------------------+ | Number of | Environment | | Components | | +--------------------------------------+ | 1,2 | US | | | CA | | | __ | +--------------------------------------+ | 3+ | __ | | | US | | | CA | +--------------------------------------+ Table 2: Local environment for US Public DUA Hardcastle-Kille [Page 11]
RFC 1484 User Friendly Naming July 1993 4.2 Matching A purported name will be supplied, usually with a small number of components. This will be matched in the context of an environment. Where there are multiple components to be matched, these should be matched sequentially. If an unambiguous DN is determined, the match continues as if the full DN had been supplied. For example if Stephen Hardcastle-Kille, UCL is being matched in the context of environment GB, first UCL is resolved to the distinguished name: University College London, GB Then the next component of the purported name is taken to determine the final name. If there is an ambiguity (e.g., if UCL had made two matches, both paths are explored to see if the ambiguity can be resolved. Eventually a set of names will be passed back to the user. Each component of the environment is taken in turn. If the purported name has more components than the maximum depth, the environment element is skipped. The advantage of this will be seen in the example given later. A match of a name is considered to have three levels: Exact A DN is specified exactly Good Initially, a match should be considered good if it is unambiguous, and exactly matches an attribute value in the entry. For human names, a looser metric is probably desirable (e.g., S 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 prompted. If there are multiple matches, more than one path may be followed. There is also a shift/reduce type of choice: should any partial matches be followed or should the next element of the Hardcastle-Kille [Page 12]
RFC 1484 User Friendly Naming July 1993 environment be tried. The following heuristics are suggested, which may be modified in the light of experience. The overall aim is to resolve cleanly specified names with a minimum of fuss, but give sufficient user control to prevent undue searching and delay. 1. Always follow an exact match. 2. Follow all good matches if there are no exact matches. 3. If there are only poor matches, prompt the user. If the user accepts one or more match, they can be considered as good. If all are rejected, this can be treated as no matches. 4. Automatically move to the next element of the environment if no matches are found. When the final component is matched, a set of names will be identified. If none are identified, proceed to the next environment element. If the user rejects all of the names, processing of the next environment element should be confirmed. The exact approach to matching will depend on the level of the tree at which matching is being done. We can now consider how attributes are matched at various levels of the DIT. There is an issue of approximate matching. Sometimes it helps, and sometimes just returns many spurious matches. When a search is requested, all relevant attributes should be returned, so that distinguished and non-distinguished values can be looked at. This will allow a distinction to be made between good and poor matches. It is important that where, for example, an acronym exactly matches an organisation, that the user is not prompted about other organisations where it matches as a substring. 4.3 Top Level In this case, a match is being done at the root of the DIT. Three approaches are suggested, dependent on the length of supplied name. All lead to a single level search of the top level of the DIT. Exactly 2 This is assumed to be a 3166 two letter country code, or an exact match on a friendly country or organisation (e.g., UK or UN). Do exact match on country and friendly country. Hardcastle-Kille [Page 13]
RFC 1484 User Friendly Naming July 1993 Greater than 2 Make an approximate and substring match on friendly country and organisation. 4.4 Intermediate Level Once the root level has been dealt with, intermediate levels will be looking for organisational components (Organisation, Locality, Org Unit). In some cases, private schema control will allow the system to determine which is at the next level. In general this will not be possible. In each case, make a substring and approximate match search of one level. The choice depends on the base object used in the search. 1. If DN has no Organisation or Locality, filter on Organisation and Locality. 2. If DN has Org Unit, filter on Org Unit. 3. If DN has Organisation, filter on Locality and Org Unit. 4. If DN has Locality, filter on Organisation. These allow some optimisation, based on legal choices of schema. Keeping filters short is usually desirable to improve performance. A few examples of this, where a base object has been determined (either by being the environment or by partial resolution of a purported name), and the next element of a purported name is being considered. This will generate a single level search. What varies is the types being filtered against. If the DN is: University College London, GB The search should be for Org Unit or Locality. If the DN is: Organisation=UN the search should be for Org Unit or Locality. There may be some improvements with respect to very short keys. Not making approximate or substring matches in these cases seems sensible. (It might be desirable to allow "*" as a part of the purported name notation). Hardcastle-Kille [Page 14]
RFC 1484 User Friendly Naming July 1993
RFC 1484 User Friendly Naming July 1993 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 Hardcastle-Kille [Page 22]
RFC 1484 User Friendly Naming July 1993 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 90 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 100 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}, 110 {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}); Hardcastle-Kille [Page 23]
RFC 1484 User Friendly Naming July 1993 ELSE return(search(base, one-level, s, {OrganisationName,120 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); 130 } SearchScope := ENUMERATED (base-object, one-level, subtree) leafSearch(base: DN; s: String; search-scope: SearchScope) { return(search(base, search-scope, s, {CommonName, Surname, UserId}, {substring, approx})); } 140 search(base: DN; search-scope: SearchScope; s: string; alist SET OF AttributeType; matchtypes SET OF 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); } 150 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): 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; 170 Hardcastle-Kille [Page 24]
RFC 1484 User Friendly Naming July 1993 IF exact != NULL THEN return(exact); IF good != NULL THEN return(good); return(userQuery(dlist)); } userQuery(dlist SET OF DN): SET OF DN { -- pass back up for manual checking 180 -- 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 ______________________________________________________________________



Back to RFC index

 

 



Sponsered-Sites:

Register domain name and transfer | Cheap webhosting service | Domain name registration

 

 

""