Network Working Group S.E. Kille INTERNET--DRAFT University College London January 1991 Using the OSI Directory to achieve User Friendly Naming Status of this Memo The OSI Directory has user friendly naming as a goal. A simple minded usage of the directory does not achieve this. Two aspects not achieved are: o A user oriented notation o Guessability This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. This then leads to a specification of a standard format for representing names, and to procedures to resolve them. This draft document will be submitted to the RFC editor as a protocol standard. Distribution of this memo is unlimited. Please send comments to the author or to the discussion group . INTERNET--DRAFT User Friendly Naming January 1991 Contents 1 Why a notation is needed 3 2 A notation for Distinguished Name 3 2.1 Goals : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :* * : : : 3 2.2 Informal definition : : : : : : : : : : : : : : : : : : : : : : : : :* * : 3 2.3 Formal definition : : : : : : : : : : : : : : : : : : : : : : : : : :* * : 4 3 Purported names 7 4 Matching a purported name 8 4.1 Environment : : : : : : : : : : : : : : : : : : : : : : : : : : : : :* * : : 8 4.2 Matching : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : * *: : : 9 4.3 Top Level : : : : : : : : : : : : : : : : : : : : : : : : : : : : : * *: : : 12 4.4 Intermediate Level : : : : : : : : : : : : : : : : : : : : : : : : :* * : 12 4.5 Bottom level : : : : : : : : : : : : : : : : : : : : : : : : : : : :* * : : 13 5 Examples 14 6 Support required from the standard 15 7 Support of OSI Services 15 8 Experience 16 9 Relationship to other work 16 10 Conclusions 18 11 Security Considerations 19 12 Author's Address 19 Kille Page 1 INTERNET--DRAFT User Friendly Naming January 1991 A Pseudo-code for the matching algorithm 20 List of Figures 1 BNF Grammar for Distinguished and Purported Name : : : : : : 5 2 Example usage of User Friendly Naming : : : : : : : : : : : : : : 17 3 Matching Algorithm : : : : : : : : : : : : : : : : : : : : : : : : :* * : 24 List of Tables 1 Standardised Keywords : : : : : : : : : : : : : : : : : : : : : : : * *: 6 2 Local environment for private DUA : : : : : : : : : : : : : : : : 10 3 Local environment for US Public DUA : : : : : : : : : : : : : : : 10 Kille Page 2 INTERNET--DRAFT User Friendly Naming January 1991 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. 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. A secondary goal, is to have a common format to be able to unambiguously refer to names. This notation should not be needed to write on business cards or in the minutes of meetings. If this is the case, the directory has failed to a large extent. 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. In practice, it will often be useful to explicitly write down directory names, even though it is not strictly needed. 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. 2 A notation for Distinguished Name 2.1 Goals The following goals are laid out: o It should be intuitive for the majority of names encountered o It should be fully general o It should be possible to lay it out in a number of ways 2.2 Informal definition This notation is designed to be convenient for common forms of name. Some examples are given. The author's directory (distinguished) name would be written: Kille Page 3 INTERNET--DRAFT User Friendly Naming January 1991 Steve Kille, Computer Science, University College London, GB This may be folded, perhaps to display in multi-column format. For example: Steve Kille, Computer Science, University College London, GB or Steve Kille Computer Science University College London, GB Another name might be: Christian Huitema, INRIA, FR Another example, shows how different attribute types are handled: James Hacker locality=Basingstoke Widget Inc GB The final example shows quoting of a comma in an Organisation name: L. Eagle, "Sue, Grabbit and Runn", GB 2.3 Formal definition A formal definition can now be given. The structure is specified in a BNF grammar in Figure 1. The quoting mechanism is used for the following cases: o Strings containing ``,'', ``+'', ``=''or ``"'' or o Strings with leading or trailing spaces o Strings containing consecutive spaces Kille Page 4 INTERNET--DRAFT User Friendly Naming January 1991 ::= | ::= ::= "," ( ) | ::= *( " " ) ::= | "+" ( ) ::= | "=" ::= 1*( ) | "OID." ::= letters, numbers, and space ::= | "." ::= 1* ::= digits 0-9 ::= *( | ) | '"' *( | "," | "+" | "=" | ) '"' | "#" ::= "," | "=" | '"' | | "\" | "+" ::= "\" ::= any char except ::= 2* ::= 0-9, a-f, A-F Figure 1: BNF Grammar for Distinguished and Purported Name Kille Page 5 | | | | | | | | | | | | | | | | | | | | | | | | || | INTERNET--DRAFT | User Friendly Naming January 1991 | | | | |Key| Attribute (X.520 keys) Locality LocalityName Area LocalityName Organisation OrganizationName Organization OrganizationName Table 1: Standardised Keywords There is an escape mechanism, so that this syntax may be used to print any valid distinguished name. This is ugly. It is expected to be used only in pathological cases. There are two parts: 1. Attributes types are represended in a (big-endian) dotted notation. (e.g., OID.2.6.53). 2. Attribute values are represented in hexadecimal (e.g. #0A56CF). A list of valid keywords for well known attribute types used in naming is given in Table 1. This is a list of keywords which must be supported. These are chosen because they appear in common forms of name, and can do so in a place which does not correspond to the default schema used. If other attributes are used for naming, this can always be extended locally. Only string type attributes are considered, but other attribute syntaxes could be supported locally. It is assumed that the interface will translate from the supplied string into PrintableString or T.61. The "+" notation is used to specify multi-component RDNs. In this case, the types for attributes in the RDN must be explicit. The name is presented/input in a little-endian order. If no type are given, a type hierarchy (schema) is assumed as: Common Name, (((Organisational Unit)*, Organisation,) Country) Explicitly typed RDNs may be inserted into this hierarchy. Two types of object are named. They are distinguished by context in the application: Common Name Object Typically a leaf object and a person. In this case, the LHS RDN is assumed to be common name, and other RDNs follow the hierarchy. Kille Page 6 INTERNET--DRAFT User Friendly Naming January 1991 Other Object Typically a non-leaf object. 3 Purported names A purported name is what a user supplies to an interface for resolution into one or more distinguished names. The same notation is used as for distinguished name. A purported name may differ from a distinguished name in a number of ways which are itemised below. 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. Typically, an interface will 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. The most common example of this is where the higher components of the distinguished name are not displayed (abbreviation). The user interface should take care to ensure that such a name will be resolved unambiguously. The ways in which a purported name may vary from a distinguished name are now described: 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 Kille Component Omission An intermediate component of the name may be omitted. Typically this will be an organisational unit. For example: Steve Kille, University College London, GB In some cases, this can be combined with abbreviation. For example: Steve Kille, University College London Approximation Approximate renditions or alternate values of one or more of the components will be supplied. For example: Stephen Kille, CS, UCL, GB or Kille Page 7 INTERNET--DRAFT User Friendly Naming January 1991 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. Type Changing A type may be omitted, even where it does not follow the hierarchy. Type variants can be explored. The previous distinguished name: James Hacker locality=Basingstoke Widget Inc GB Could be represented by the purported name: James Hacker Basingstoke Widget Inc GB 4 Matching a purported name 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 Kille Page 8 INTERNET--DRAFT User Friendly Naming January 1991 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 2 and 3. Table 2 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. 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. 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 Kille, UCL is being matched in the context of environment GB, first UCL is resolved to the distinguished name: University College London, GB Kille Page 9 | | | | | | | || || || || || ||| ||| ||| ||| ||| ||| ||| ||| ||| ||| ||| ||| ||| ||| ||| ||| ||| ||||| | INTERNET--DRAFT|||||| User Friendly Naming January 1991 ||| ||| ||| ||| ||| ||| ||| ||| ||| ||| |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 2: |Local|environment for private DUA || || || || || || || || || || || || || || |Number|of Environment |Components||| |1,2| US || CA | -- 3+ -- US CA Table 3: Local environment for US Public DUA Kille Page 10 INTERNET--DRAFT User Friendly Naming January 1991 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 Kille should be a good match of S. Kille, S.E. Kille or Steve 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 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 Kille Page 11 INTERNET--DRAFT User Friendly Naming January 1991 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. 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. Kille Page 12 INTERNET--DRAFT User Friendly Naming January 1991 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(1). 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 either reference a leaf or 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 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 | (1)It might be desirable to allow ``*'' as a part of the purported name notation Kille Page 13 INTERNET--DRAFT User Friendly Naming January 1991 name University College London, GB and have a single component Bloggs, this will generate a subtree search. 5 Examples This is all somewhat confusing, and a few examples are given. These are all in the context of the environment shown in Table 2 on Page 10. If ``Joe Bloggs'' is supplied, a subtree search of Physics, University College London, GB will be made, and the user 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. Kille Page 14 INTERNET--DRAFT User Friendly Naming January 1991 If ``Andrew Findlay, Brunel'' is supplied, the first element of the environment will be skipped, single level search of ``Brunel'' under ``GB' will find: Brunel University, GB and a subtree search for ``A Findlay'' initiated. This will yield 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 The major focus of this work has been to provide a mechanism for identifying Organisations and Users. A related function is to identify applications. Where the Application is identified by an AET (Application Entity Title) with an RDN of Common Name, this specification leads to a natural usage. For example, if a filestore in named ``gannet'', then this could easily be identified by the name: Gannet, Computer Laboratory, Cambridge University, GB In normal usage, this might lead to access (using a purported name) of: FTAM gannet,cambridge A second type of access is where the user identifies an Organisation (Organisational Unit), and expects to obtain a default service. The service is implied by the application, and should not require any additional naming as far as the user is concerned. It is proposed that this is supported by User Friendly Naming in the following way. Kille Page 15 INTERNET--DRAFT User Friendly Naming January 1991 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 An experimental implementation of this has been written by Colin Robbins. The example in Figure 2 shows that it can be very effective at locating known individuals with a minimum of effort. This code has been deployed within the ``FRED'' interface of the PSI Pilot [Ros90 ], and within an prototype interface for managing distribution lists. The user reaction has been favourable: Some issues have arisen from this experience: o Where there is more than one level of Organisational Unit, 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. o 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. Implementor's 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 [KRRT90 ]. Kille Page 16 INTERNET--DRAFT User Friendly Naming January 1991 -> 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 2: Example usage of User Friendly Naming Kille Page 17 INTERNET--DRAFT User Friendly Naming January 1991 Some of the ideas used here originally came from a UK Proposal to the ISO/CCITT Directory Group on ``New Name Forms'' [Kil89 ]. 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. 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 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 born out by operational experience with OSI Directories [Kil88 ]. Untyped and Unordered Surprisingly this form of name can be supported quite easily. However, a considerably 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 Conclusions 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. References [CCI88] The directory - overview of concepts, models and services, December 1988. CCITT X.500 Series Recommendations. [Kil88] S.E. Kille. The THORN large scale pilot exercise. Computer Networks and ISDN Systems, 16(1):143--145, September 1988. [Kil89] S.E. Kille. New name forms, May 1989. ISO/IEC/JTC 21/ WG4/N797 UK National Body Contribution to the Oslo Directory Meeting. Kille Page 18 INTERNET--DRAFT User Friendly Naming January 1991 [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. 11 Security Considerations Security considerations are not discussed in this INTERNET--DRAFT . 12 Author's Address Steve Kille Department of Computer Science University College London Gower Street WC1E 6BT England Phone: +44-71-380-7294 EMail: S.Kille@CS.UCL.AC.UK Kille Page 19 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | INTERNET--DRAFT|| User Friendly Naming January 1991 | | | 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 f * *10 type OBJECT IDENTIFIER, value ANY g RDN ::= Attribute simplification, as can be multivalue DN ::= SEQUENCE OF RDN Environment ::= SEQUENCE OF DN * *20 EnvironmentList ::= SEQUENCE OF SEQUENCE f lowerbound INTEGER, upperbound INTEGER, environment Environment g friendlyMatch(p: PurportedName; el: EnvironmentList): SET OF DN f Find correct environment * *30 IF length(el) == 0 THEN return(NULL); IF length(p) <= head(el).upperbound && length(p) >= head(el).lowerbound THEN return envMatch (p, head(el).environment); ELSE return(friendlyMatch(p, tail(el)); Kille Page 20 INTERNET--DRAFT User Friendly Naming January 1991 g * *40 envMatch(p: PurportedName; e: Environment): SET OF DN f Check elements of environment in the defined order matches: SET OF DN; IF length(e) == 0 THEN return(NULL); matches = purportedMatch(head(el).DN, p) * *50 IF matches != NULL THEN return(matches); ELSE return(envMatch(p, tail(e)); g purportedMatch(base: DN; p: PurportedName): SET OF DN f 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, FALSE); ELSE IF length(base) == 1 THEN IF (matches = intSearch(base, s)) != NULL THEN return(matches); * *70 ELSE return(leafSearch(base, s, FALSE); ELSE IF (matches = leafSearch(base, s, TRUE)) != NULL TH* *EN return(matches); ELSE return(intsearch(base, s); IF length(base) == 0 THEN FOR x IN rootSearch(s) DO matches += (purportedMatch(x, tail(p)); * *80 Kille Page 21 INTERNET--DRAFT User Friendly Naming January 1991 ELSE FOR x IN intSearch(base, s) DO matches += (purportedMatch(x, tail(p)); return(matches); g 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 f IF length == 2 THEN return(search(NULL, onelevel, s, fCountryName, FriendlyCountryName, OrganizationNameg, fexactg, fCountry, Organisationg)); ELSE return(search(NULL, onelevel, s, fOrganizationName, FriendlyCountryNameg, fsubstring, approxg, 1* *00 fCountry, Organisationg)); g intSearch( base: DN; s: String) f IF present(base, OrgUnitName) THEN return(search(base, onelevel, s, fOrgUnitNameg, fsubstring, approxg, fOrgUnitg)); ELSE IF present(base, OrganisationName) THEN 1* *10 return(search(base, onelevel, fOrgUnitName, LocalityNameg, fsubstring, approxg, fOrganization, OrgUnit, Localityg)); ELSE IF present(base, LocalityName) THEN return(search(base, onelevel, s, fOrganisationNameg, fsubstring, approxg, fLocalityg); ELSE return(search(base, onelevel, s, fOrganisationName, LocalityNameg, fsubstring, approxg, fOrganisation, Localityg)); 1* *20 g Kille Page 22 INTERNET--DRAFT User Friendly Naming January 1991 present(d: DN; t: AttributeType): BOOLEAN f FOR x IN d DO IF x.type == t THEN return(TRUE); return(FALSE); g 1* *30 SearchScope := ENUMERATED (baseobject, onelevel, subtree) leafSearch(base: DN; s: String; searchscope: SearchScope) f return(search(base, searchscope, s, fCommonName, Surname, UserIdg, fsubstring, approxg)); g search(base: DN; searchscope: SearchScope; s: string; 1* *40 alist SET OF AttributeType; matchtypes SET OF MatchType objectClasses SET OF ObjectClass OPTIONAL): SET OF DN f mapped onto Directory Search, with OR conjunction of filter items return dNSelect (s, searchresults, alist); g read(base: DN; alist SET OF AttributeType): SET OF Attribute; 1* *50 f mapped onto Directory Read Types repeated to deal with multiple values This would be implemented by returning selected info with the search operation g dNSelect(s: String; dlist SET OF DN; alist: SET OF AttributeType): SET OF* * DN f exact, good: SET OF DN; 1* *60 FOR x IN dlist DO IF last(DN).Value == s THEN Kille Page 23 | | | | | | | | | | | | | | || | INTERNET--DRAFT|| User Friendly Naming January 1991 | | | | exact += x; || ELSE IF FOR y IN read(x, alist) DO || IF y.value == s THEN | good += x; | | | || IF exact != NULL THEN return(exact); 1* *70 | IF good != NULL THEN return(good); || return(userQuery(dlist)); g|| | | | userQuery(dlist|SET|OF DN): SET OF DN f| || pass back up for manual checking || user can strip all matches to force progres.... g| 1* *80 | | | 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 3: Matching Algorithm Kille Page 24