idnits 2.17.1 draft-ietf-osids-friendlynaming-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-16) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([HK92]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (October 1992) is 11506 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'CCI88' -- Possible downref: Non-RFC (?) normative reference: ref. 'HK92' -- Possible downref: Non-RFC (?) normative reference: ref. 'Kil89a' -- Possible downref: Non-RFC (?) normative reference: ref. 'Kil89b' -- Possible downref: Non-RFC (?) normative reference: ref. 'Kil90' -- Possible downref: Non-RFC (?) normative reference: ref. 'KRRT90' -- Possible downref: Non-RFC (?) normative reference: ref. 'Neu89' -- Possible downref: Non-RFC (?) normative reference: ref. 'Pet88' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ros90' Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working S.E. Hardcastle-Kille 3 Group University College London 4 INTERNET-DRAFT October 1992 5 Expires: April 1993 7 Using the OSI Directory to achieve 9 User Friendly Naming 10 (OSI-DS 24 (v1.1)) 12 Status of this Memo 14 This document is an Internet Draft. Internet Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its Areas, 16 and its Working Groups. Note that other groups may also distribute 17 working documents as Internet Drafts. 19 Internet Drafts are draft documents valid for a maximum of six months. 20 Internet Drafts may be updated, replaced, or obsoleted by other 21 documents at any time. It is not appropriate to use Internet Drafts 22 as reference material or to cite them other than as a "working draft" 23 or "work in progress." 25 Please check the I-D abstract listing contained in each Internet Draft 26 directory to learn the current status of this or any other Internet 27 Draft. 29 Abstract 31 The OSI Directory has user friendly naming as a goal. A simple minded 32 usage of the directory does not achieve this. Two aspects not 33 achieved are: 35 o A user oriented notation 37 o Guessability 38 INTERNET--DRAFT User Friendly Naming October 1992 40 This proposal sets out some conventions for representing names in a 41 friendly manner, and shows how this can be used to achieve really 42 friendly naming. This then leads to a specification of a standard 43 format for representing names, and to procedures to resolve them. 44 This leads to a specification which allows directory names to be 45 communicated between humans. The format in this specification is 46 identical to that defined in [HK92], and it is intended that these 47 specifications are compatible. 49 This draft document will be submitted to the RFC editor as a protocol 50 standard. Distribution of this memo is unlimited. Please send 51 comments to the author or to the discussion group 52 . 54 INTERNET--DRAFT User Friendly Naming October 1992 56 Contents 58 1 Why a notation is needed 4 60 2 The Notation 5 62 3 Communicating Directory Names 9 64 4 Matching a purported name 11 66 4.1 Environment . . . . . . . . . . 12 67 4.2 Matching . . . . . . . . . . . 12 68 4.3 Top Level . . . . . . . . . . 15 70 4.4 Intermediate Level . . . . . . . . 15 71 4.5 Bottom level . . . . . . . . . . 17 73 5 Examples 17 75 6 Support required from the standard 19 77 7 Support of OSI Services 19 79 8 Experience 20 81 9 Relationship to other work 20 83 10 Issues 22 85 11 Security Considerations 24 87 12 Author's Address 24 89 A Pseudo-code for the matching algorithm 25 90 INTERNET--DRAFT User Friendly Naming October 1992 92 List of Figures 94 1 Example usage of User Friendly Naming . . . 21 95 2 Matching Algorithm . . . . . . . . 29 97 List of Tables 99 1 Local environment for private DUA . . . . 13 100 2 Local environment for US Public DUA . . . . 13 102 INTERNET--DRAFT User Friendly Naming October 1992 104 1 Why a notation is needed 106 Many OSI Applications make use of Distinguished Names (DN) as defined 107 in the OSI Directory [CCI88]. The main reason for having a notation 108 for name format is to interact with a user interface. This 109 specification is coming dangerously close to the sin of standardising 110 interfaces. However, there are aspects of presentation which it is 111 desirable to standardise. 112 It is important to have a common format to be able to conveniently 113 refer to names. This might be done to represent a directory name on a 114 business card or in an email message. There is a need for a format to 115 support human to human communication, which must be string based (not 116 ASN.1) and user oriented. 118 In very many cases, a user will be required to input a name. This 119 notation is designed to allow this to happen in a uniform manner 120 across many user interfaces. The intention is that the name can just 121 be typed in. There should not be any need to engage in form filling 122 or complex dialogue. 123 It should be possible to take the ``human'' description given at the 124 meeting, and use it directly. The means in which this happens will 125 become clear later. 126 This approach uses the syntax defined in XXX for representing 127 distinguished names [HK92]. By relaxing some of the constraints on 128 this specification, it is argued that a more user oriented 129 specification is produced. However, this syntax cannot be mapped 130 algorithmically onto a distinguished name without the use of a 131 directory. 133 This notation is targeted towards a general user oriented system, and 134 in particular to represent the names of humans. Other syntaxes may be 135 more appropriate for other uses of the directory. For example, the 136 OSF Syntax may be more appropriate for some system oriented uses. 137 This notation is targeted towards names which follow a particular DIT 138 structure: organisationally oriented. This may make it inappropriate 139 for some types of application. There may be a requirement to extend 140 this notation to deal more cleanly with fully geographical names. 142 This approach effectively defines a definition of descriptive names on 143 top of the primitive names defined by the OSI Directory. 145 INTERNET--DRAFT User Friendly Naming October 1992 147 2 The Notation 149 The notation used in this specification is defined in [HK92]. This 150 notation defines an unambiguous representation of distinguished name, 151 and this specification is designed to be used in conjunction with this 152 format. Both specification arise from the same piece of research work 153 [Kil90]. Some examples of the specification are given here. 154 The author's User Friendly Name (UFN) might be written: 156 Steve Hardcastle-Kille, Computer Science, University College London, GB 158 or 160 S. Hardcastle-Kille, Computer Science, University College London, GB 162 This may be folded, perhaps to display in multi-column format. For 163 example: 165 Steve Hardcastle-Kille, 166 Computer Science, 167 University College London, 168 GB 170 Another UFN might be: 172 Christian Huitema, INRIA, FR 174 or 176 James Hacker, 177 Basingstoke, 178 Widget Inc, 179 GB 181 The final example shows quoting of a comma in an Organisation name: 183 L. Eagle, "Sue, Grabbit and Runn", GB 184 INTERNET--DRAFT User Friendly Naming October 1992 186 A purported name is what a user supplies to an interface for 187 resolution into one or more distinguished names. A system should 188 almost always store a name as a distinguished name. This will be more 189 efficient, and avoid problems with purported names which become 190 ambiguous when a new name appears. A user interface may display a 191 distinguished name, using the distinguished name notation. However, 192 it may display a purported name in cases where this will be more 193 pleasing to the user. Examples of this might be: 195 o Omission the higher components of the distinguished name are not 196 displayed (abbreviation). 198 o Omission of attribute types, where the type is unlikely to be 199 needed to resolve ambiguity. 201 The ways in which a purported name may vary from a distinguished name 202 are now described: 204 Type Omission There are two cases of this. 206 o Schema defaulting. In this case, although the type is not 207 present, a schema defaulting is used to deduce the type. The 208 first two types of schema defaulting may be used to deduce a 209 distinguished name without the use of the directory. The use 210 of schema defaulting may be useful to improve the performance 211 of UFN resolution. The types of schema defaulting are: 213 -- Default Schema 215 -- Context Dependent Default Schema 217 -- Data Depended Default Schema 219 o Omission of the type to be resolved by searching.. 221 Default Schema The attribute type of an attribute may always be 222 present. This may be done to emphasise the type structure of a 223 name. In some cases, the typing may be omitted. This is done in 224 a way so that in many common cases, no attribute types are needed. 225 The following type hierarchy (schema) is assumed: 227 Common Name, (((Organisational Unit)*, Organisation,) Country) 229 INTERNET--DRAFT User Friendly Naming October 1992 231 Explicitly typed RDNs may be inserted into this hierarchy at any 232 point. The least significant component is always of type Common 233 Name. Other types follow the defined organisational hierarchy. 234 The following are equivalent: 236 Filestore Access, Bells, Computer Science, 237 University College London, GB 239 and 241 CN=Filestore Access, OU=Bells, OU=Computer Science, 242 OU=University College London, C=GB 244 To interpet a distinguished name presented in this format, with 245 some or all of the attribute with the type not specified, the 246 types are derived according to the type hierarchy by the following 247 algorithm: 249 1. If the first attribute type is not specified, it is 250 CommonName. 252 2. If the last attribute type is not specified, it is Country. 254 3. If there is no organisation explicitly specified, the last 255 attribute with type not specified is of type Organisation. 257 4. Any remaining attribute with type unspecified must be before 258 an Organisation or OrganisationalUnit attribute, and is of 259 type OrganisationalUnit. 261 To take a distinguished name, and generate a name of this format 262 with attribute types omitted, the following steps are followed. 264 1. If the first attribute is of type CommonName, the type may be 265 omitted. 267 2. If the last attribute is of type Country, the type may be 268 omitted. 270 3. If the last attribute is of type Country, the last 271 Organisation attribute may have the type omitted. 273 4. All attributes of type OrganisationalUnit may have the type 275 INTERNET--DRAFT User Friendly Naming October 1992 277 omitted, unless they are after an Organisation attribute or 278 the first attribute. 280 Context Dependent Default Schema The distinguished name notation 281 defines a fixed schema for type defaulting. It may be useful to 282 have different defaults in different contexts. For example, the 283 defaulting convention may be applied in a modified fashion to 284 objects which are known not to be common name objects. This will 285 always be followed if the least significant component is 286 explicitly typed. In this case, the following hierarchy is 287 followed: 289 ((Organisational Unit)*, Organisation,) Country 291 Data Dependent Defaulting There are cases where it would be optimal 292 to default according to the data. For example, in: 294 Einar Stefferud, Network Management Associates, CA, US 296 It would be useful to default ``CA'' to type State. This might be 297 done by defaulting all two letter attributes under C=US to type 298 State. 300 General Defaulting A type may be omitted in cases where it does not 301 follow a default schema hierarchy. Type variants can be explored 302 by searching. Could be represented by the purported name. For 303 example, 305 James Hacker, 306 Basingstoke, 307 Widget Inc, 308 GB 310 Would match the distinguished name: 312 CN=James Hacker, 313 L=Basingstoke, 314 O=Widget Inc, 315 CN=GB 317 Abbreviation Some of the more significant components of the DN will 318 be omitted, and then defaulted in some way (e.g., relative to a 320 INTERNET--DRAFT User Friendly Naming October 1992 322 local context). For example: 324 Steve Hardcastle-Kille 326 Local Type Keywords Local values can be used to identify types, in 327 addition to the keywords defined in [HK92]. For example, 328 ``Organisation'' may be recognised as an alternative to ``O''.sc 330 Component Omission An intermediate component of the name may be 331 omitted. Typically this will be an organisational unit. For 332 example: 334 Steve Hardcastle-Kille, University College London, GB 336 In some cases, this can be combined with abbreviation. For 337 example: 339 Steve Hardcastle-Kille, University College London 341 Approximation Approximate renditions or alternate values of one or 342 more of the components will be supplied. For example: 344 Stephen Hardcastle-Kille, CS, UCL, GB 346 or 348 Steve Keill, Comp Sci, Univarstiy College London, GB 350 Friendly Country A ``friendly country name'' can be used instead of 351 the ISO 3166 two letter code. For example: UK; USA; France; 352 Deutchland. 354 3 Communicating Directory Names 356 A goal of this standard is to provide a means of communicating 357 directory names. Two approaches are given, one defined in [HK92], and 358 the other here. A future version of these specifications may contain 359 only one of these approaches, or recommend use of one approach. The 360 approach can usually be distinguished implicitly, as types are 361 normally omitted in the UFN approach, and are always present in the 362 INTERNET--DRAFT User Friendly Naming October 1992 364 Distinguished Name approach. No recommendation is made here, but the 365 merits of each approach is given. 367 1. Distinguished Name or DN. A representation of the distinguished 368 name, according to the specification of [HK92]. 370 2. User Friendly Name or UFN. A purported name, which is expected to 371 unambiguously resolve onto the distinguished name. 373 When a UFN is communicated, a form which should efficiently and 374 unambiguously resolve onto a distinguished name should be chosen. 375 Thus it is reasonable to omit types, or to use alternate values which 376 will unambiguously identify the entry in question (e.g., by use of an 377 alternate value of the RDN attribute type). It is not reasonable to 378 use keys which are (or are likely to become) ambiguous. 379 The approach used should be implicit form the context, rather than 380 wired into the syntax. The terms ``Directory Name'' and ``X.500 381 Name'' should be used to refer to a name which might be either a DN or 382 UFN. An example of appropriate usage of both forms is given in the 383 Section which defines the Author's location on page 12. 384 Advantages of communicating the DN are: 386 o The Distinguished Name is an unambiguous and stable reference to 387 the user. 389 o The DN will be used efficiently by the directory to obtain 390 information. 392 Advantages of communicating the UFN are: 394 o Redundant type information can be omitted (e.g., ``California'', 395 rather than ``State=California'', where there is known to be no 396 ambiguity. 398 o Alternate values can be used to identify a component. This might 399 be used to select a value which is meaningful to the recipient, or 400 to use a shorter form of the name. Often the uniqueness 401 requirements of registration will lead to long names, which users 402 will wish to avoid. 404 INTERNET--DRAFT User Friendly Naming October 1992 406 o Levels of the hierarchy may be omitted. For example in a very 407 small organisation, where a level of hierarchy has been used to 408 represent company structure, and the person has a unique name 409 within the organisation. 411 Where UFN form is used, it is important to specify an unambiguous 412 form. In some ways, this is analogous to writing a postal address. 413 There are many legal ways to write it. Care needs to be taken to make 414 the address unambiguous. 416 4 Matching a purported name 418 The following approach specifies a default algorithm to be used with 419 the User Friendly Naming approach. It is appropriate to modify this 420 algorithm, and future specifications may propose alternative 421 algorithms. Two simple algorithms are noted in passing, which may be 422 useful in some contexts: 424 1. Use type omission only, but otherwise require the value of the RDN 425 attribute to be present. 427 2. Require each RDN to be identified as in 1), or by an exact match 428 on an alternate value of the RDN attribute. 430 These algorithms do not offer the flexibility of the default algorithm 431 proposed, but give many of the benefits of the approach in a very 432 simple manner. 434 The major utility of the purported name is to provide the important 435 ``user friendly'' characteristic of guessability. A user will supply 436 a purported name to a user interface, and this will be resolved onto a 437 distinguished name. When a user supplies a purported name there is a 438 need to derive the DN. In most cases, it should be possible to derive 439 a single name from the purported name. In some cases, ambiguities 440 will arise and the user will be prompted to select from a multiple 441 matches. This should also be the case where a component of the name 442 did not ``match very well''. 443 There is an assumption that the user will simply enter the name 444 correctly. The purported name variants are designed to make this 445 happen! There is no need for fancy window based interfaces or form 446 filling for many applications of the directory. Note that the fancy 447 INTERNET--DRAFT User Friendly Naming October 1992 449 interfaces still have a role for browsing, and for more complex 450 matching. This type of naming is to deal with cases where information 451 on a known user is desired and keyed on the user's name. 453 4.1 Environment 455 All matches occur in the context of a local environment. The local 456 environment defines a sequence of name of a non-leaf objects in the 457 DIT. This environment effectively defines a list of acceptable name 458 abbreviations where the DUA is employed. The environment should be 459 controllable by the individual user. It also defines an order in 460 which to operate. 461 This list is defined in the context of the number of name components 462 supplied. This allows varying heuristics, depending on the 463 environment, to make the approach have the ``right'' behaviour. 464 In most cases, the environment will start at a local point in the DIT, 465 and move upwards. Examples are given in Tables 1 and 2. Table 1 466 shows an example for a typical local DUA, which has the following 467 characteristics: 469 One component Assumed first to be a user in the department, then a 470 user or department within the university, the a national 471 organisation, and finally a country. 473 Two components Most significant component is first assumed to be a 474 national organisation, then a department (this might be reversed 475 in some organisations), and finally a country. 477 Three or more components The most significant component is first 478 assumed to be a country, then a national organisation, and finally 479 a department. 481 4.2 Matching 483 A purported name will be supplied, usually with a small number of 484 components. This will be matched in the context of an environment. 485 Where there are multiple components to be matched, these should be 486 matched sequentially. If an unambiguous DN is determined, the match 487 continues as if the full DN had been supplied. For example if 488 INTERNET--DRAFT User Friendly Naming October 1992 490 Number of Environment 491 _Components_________________________________________ 492 1 Physics, University College London, GB 493 University College London, GB 494 GB 495 _____________--_____________________________________ 496 2 GB 497 University College London, GB 498 _____________--_____________________________________ 499 3+ -- 500 GB 501 University College London, GB 503 Table 1: Local environment for private DUA 505 Number of Environment 506 _Components______________ 507 1,2 US 508 CA 509 _____________--__________ 510 3+ -- 511 US 512 CA 514 Table 2: Local environment for US Public DUA 516 INTERNET--DRAFT User Friendly Naming October 1992 518 Stephen Hardcastle-Kille, UCL 520 is being matched in the context of environment GB, first UCL is 521 resolved to the distinguished name: 523 University College London, GB 525 Then the next component of the purported name is taken to determine 526 the final name. If there is an ambiguity (e.g., if UCL had made two 527 matches, both paths are explored to see if the ambiguity can be 528 resolved. Eventually a set of names will be passed back to the user. 530 Each component of the environment is taken in turn. If the purported 531 name has more components than the maximum depth, the environment 532 element is skipped. The advantage of this will be seen in the example 533 given later. 534 A match of a name is considered to have three levels: 536 Exact A DN is specified exactly 538 Good Initially, a match should be considered good if it is 539 unambiguous, and exactly matches an attribute value in the entry. 540 For human names, a looser metric is probably desirable (e.g., 541 S Hardcastle-Kille should be a good match of S. Hardcastle-Kille, 542 S.E. Hardcastle-Kille or Steve Hardcastle-Kille even if these are 543 not explicit alternate values). 545 Poor Any other substring or approximate match 547 Following a match, the reference can be followed, or the user 548 prompted. If there are multiple matches, more than one path may be 549 followed. There is also a shift/reduce type of choice: should any 550 partial matches be followed or should the next element of the 551 environment be tried. The following heuristics are suggested, which 552 may be modified in the light of experience. The overall aim is to 553 resolve cleanly specified names with a minimum of fuss, but give 554 sufficient user control to prevent undue searching and delay. 556 1. Always follow an exact match. 558 2. Follow all good matches if there are no exact matches. 560 INTERNET--DRAFT User Friendly Naming October 1992 562 3. If there are only poor matches, prompt the user. If the user 563 accepts one or more match, they can be considered as good. If all 564 are rejected, this can be treated as no matches. 566 4. Automatically move to the next element of the environment if no 567 matches are found. 569 When the final component is matched, a set of names will be 570 identified. If none are identified, proceed to the next environment 571 element. If the user rejects all of the names, processing of the next 572 environment element should be confirmed. 574 The exact approach to matching will depend on the level of the tree at 575 which matching is being done. We can now consider how attributes are 576 matched at various levels of the DIT. 577 There is an issue of approximate matching. Sometimes it helps, and 578 sometimes just returns many spurious matches. When a search is 579 requested, all relevant attributes should be returned, so that 580 distinguished and non-distinguished values can be looked at. This 581 will allow a distinction to be made between good and poor matches. It 582 is important that where, for example, an acronym exactly matches an 583 organisation, that the user is not prompted about other organisations 584 where it matches as a substring. 586 4.3 Top Level 588 In this case, a match is being done at the root of the DIT. Three 589 approaches are suggested, dependent on the length of supplied name. 590 All lead to a single level search of the top level of the DIT. 592 Exactly 2 This is assumed to be a 3166 two letter country code, or an 593 exact match on a friendly country or organisation (e.g., UK or 594 UN). Do exact match on country and friendly country. 596 Greater than 2 Make an approximate and substring match on friendly 597 country and organisation. 599 4.4 Intermediate Level 601 Once the root level has been dealt with, intermediate levels will be 602 looking for organisational components (Organisation, Locality, Org 603 INTERNET--DRAFT User Friendly Naming October 1992 605 Unit). In some cases, private schema control will allow the system to 606 determine which is at the next level. In general this will not be 607 possible. In each case, make a substring and approximate match search 608 of one level. The choice depends on the base object used in the 609 search. 611 1. If DN has no Organisation or Locality, filter on Organisation and 612 Locality. 614 2. If DN has Org Unit, filter on Org Unit. 616 3. If DN has Organisation, filter on Locality and Org Unit. 618 4. If DN has Locality, filter on Organisation. 620 These allow some optimisation, based on legal choices of schema. 621 Keeping filters short is usually desirable to improve performance. 622 A few examples of this, where a base object has been determined 623 (either by being the environment or by partial resolution of a 624 purported name), and the next element of a purported name is being 625 considered. This will generate a single level search. What varies is 626 the types being filtered against. If the DN is: 628 University College London, GB 630 The search should be for Org Unit or Locality. If the DN is: 632 Organisation=UN 634 the search should be for Org Unit or Locality. 636 There may be some improvements with respect to very short keys. Not 637 making approximate or substring matches in these cases seems 638 sensible1. 639 ---------------------------- 640 1. It might be desirable to allow ``*'' as a part of the purported 641 name notation 642 INTERNET--DRAFT User Friendly Naming October 1992 644 4.5 Bottom level 646 The ``Bottom Level'' is to deal with leaf entries in the DIT. This 647 will often be a person, but may also be a role, an application entity 648 or something else. 649 The last component of a purported name may either reference a leaf or 650 non-leaf. For this reason, both should be tested for. As a 651 heuristic, if the base object for the search has two or more 652 components it should be tested first as a bottom level name and then 653 intermediate. Reverse this for shorter names. This optimises for the 654 (normal) case of non-leaves high up the tree and leaves low down the 655 tree. 657 For bottom level names, make an approximate and substring match 658 against Common Name, Surname, and User ID. Where common name is looked 659 for, A full subtree search will be used when at the second level of 660 the DIT or lower, otherwise a single level search. 661 For example, if I have resolved a purported name to the distinguished 662 name 664 University College London, GB 666 and have a single component Bloggs, this will generate a subtree 667 search. 669 5 Examples 671 This is all somewhat confusing, and a few examples are given. These 672 are all in the context of the environment shown in Table 1 on Page 13. 674 If ``Joe Bloggs'' is supplied, a subtree search of 676 Physics, University College London, GB 678 will be made, and the user prompted for ``Joseph Z. Bloggs'' as the 679 only possible match. 680 If ``Computer Science'' is supplied, first 682 Physics, University College London, GB 683 INTERNET--DRAFT User Friendly Naming October 1992 685 will be searched, and the user will reject the approximate match of 686 ``Colin Skin''. Then a subtree search of 688 University College London, GB 690 will be made, looking for a person. Then a single level search will 691 be made looking for Org Unit, and 693 Computer Science, University College London, GB 695 will be returned without prompting (exact match). 696 Supplying ``Steve Hardcastle-Kille'' will lead to a failed subtree 697 search of 699 Physics, University College London, GB 701 and lead straight to a subtree search of 703 University College London, GB 705 This will lead to an exact value match, and so a single entry returned 706 without prompting. 708 If ``Andrew Findlay, Brunel'' is supplied, the first element of the 709 environment will be skipped, single level search of ``Brunel'' under 710 ``GB' will find: 712 Brunel University, GB 714 and a subtree search for ``A Findlay'' initiated. This will yield 716 Andrew Findlay, Computing and Media Services, Brunel University, GB 718 Dr A J Findlay, Manufacturing and Engineering Systems, 719 Brunel University, GB 721 and the user will be prompted with a choice. 723 INTERNET--DRAFT User Friendly Naming October 1992 725 This approach shows how a simple format of this nature will ``do the 726 right thing'' in many cases. 728 6 Support required from the standard 730 Fortunately, all that is needed is there! It would be useful to have 731 ``friendly country name'' as a standard attribute. 733 7 Support of OSI Services 735 The major focus of this work has been to provide a mechanism for 736 identifying Organisations and Users. A related function is to 737 identify applications. Where the Application is identified by an AET 738 (Application Entity Title) with an RDN of Common Name, this 739 specification leads to a natural usage. For example, if a filestore 740 in named ``gannet'', then this could easily be identified by the name: 742 Gannet, Computer Laboratory, Cambridge University, GB 744 In normal usage, this might lead to access (using a purported name) 745 of: 747 FTAM gannet,cambridge 749 A second type of access is where the user identifies an Organisation 750 (Organisational Unit), and expects to obtain a default service. The 751 service is implied by the application, and should not require any 752 additional naming as far as the user is concerned. It is proposed 753 that this is supported by User Friendly Naming in the following way. 755 1. Determine that the purported name identifies a non-leaf object, 756 which is of object class Organisation or Organisational Unit or 757 Locality. 759 2. Perform a single level search for Application Entities which 760 support the required application contexts. This assumes that all 761 services which are supporting default access for the organisation 762 are registered at one level below (possibly by the use of 763 aliases), and that other services (specific machines or parts of 765 INTERNET--DRAFT User Friendly Naming October 1992 767 the organisation) are represented further down the tree. This 768 seems to be a reasonable layout, and its utility can be evaluated 769 by experiment. 771 8 Experience 773 An experimental implementation of this has been written by Colin 774 Robbins. The example in Figure 1 shows that it can be very effective 775 at locating known individuals with a minimum of effort. This code has 776 been deployed within the ``FRED'' interface of the PSI Pilot [Ros90], 777 and within an prototype interface for managing distribution lists. 778 The user reaction has been favourable: 779 Some issues have arisen from this experience: 781 o Where there is more than one level of Organisational Unit, and the 782 user guesses one which is not immediately below the organisation, 783 the algorithm works badly. There does not appear to be an easy 784 fix for this. It is not clear if this is a serious deficiency. 786 o Substring searching is currently done with leading and trailing 787 wildcards. As many implementations will not implement leading 788 wildcards efficiently, it may be preferable to only use trailing 789 wildcards. The effect of this on the algorithm needs to be 790 investigated. 792 Implementor's of this specification are encouraged to investigate 793 variants of the basic algorithm. A final specification should depend 794 on experience with such variants. 796 9 Relationship to other work 798 Colin Robbin's work on the interface ``Tom'' and implementation of a 799 distribution list interface strongly influenced this specification 800 [KRRT90]. 801 Some of the ideas used here originally came from a UK Proposal to the 802 ISO/CCITT Directory Group on ``New Name Forms'' [Kil89a]. This 803 defined, and showed how to implement, four different types of names: 805 Typed and Ordered The current Distinguished Name is a restricted 806 INTERNET--DRAFT User Friendly Naming October 1992 808 -> t hales, csiro, australia 809 Found good match(es) for 'australia' 810 Found exact match(es) for 'csiro' 811 Please select from the following: 812 Trevor Hales, OC, HPCC, DIT, IICT, CSIRO, AU [y/n] ? y 813 The following were matched... 814 Trevor Hales, OC, HPCC, DIT, IICT, CSIRO, AU 816 -> g michaelson, queensland, au 817 Found exact match(es) for 'au' 818 Please select from the following: 819 University of Queensland, AU [y/n] ? y 820 Axolotl, AU [y/n] ? n 821 Please select from the following: 822 George Michaelson, Prentice Computer Centre, University of Queensland, AU 823 [y/n] ? y 824 Manager, University of Queensland, AU [y/n] ? n 825 The following were matched... 826 George Michaelson, Prentice Computer Centre, University of Queensland, AU 828 -> r needham, cambridge 829 Found good match(es) for 'cambridge' 830 Please select from the following: 831 Roger Needham, Computer Lab, Cambridge University [y/n] ? y 832 The following were matched... 833 Roger Needham, Computer Lab, Cambridge University 835 -> kirstein 836 Found good match(es) for 'kirstein' 837 The following were matched... 838 Peter Kirstein 840 Figure 1: Example usage of User Friendly Naming 842 INTERNET--DRAFT User Friendly Naming October 1992 844 example of this type of name. 846 Untyped and Ordered This is the type of name proposed here (with some 847 extensions to allow optional typing). It is seen as meeting the 848 key user requirement of disliking typed names, and is efficient to 849 implement. 851 Typed and Unordered This sort of name is proposed by others as the 852 key basis for user friendly naming. Neufeld shows how X.500 can 853 be used to provide this [Neu89], and Peterson proposes the Profile 854 system to provide this [Pet88]. The author contends that whilst 855 typed naming is interesting for some types of searching (e.g., 856 yellow page searching), it is less desirable for naming objects. 857 This is born out by operational experience with OSI Directories 858 [Kil89b]. 860 Untyped and Unordered Surprisingly this form of name can be supported 861 quite easily. However, a considerably gain in efficiency can be 862 achieved by requiring ordering. In practice, users can supply 863 this easily. Therefore, this type of name is not proposed. 865 10 Issues 867 The following issues are noted, which would need to be resolved before 868 this document is progressed as an Internet Standard. 870 Potential Ambiguity Whilst the intention of the notation is to allow 871 for specification of alternate values, it inherently allows for 872 ambiguous names to be specified. It needs to be demonstrated that 873 problems of this characteristic are outweighed by other benefits 874 of the notation. 876 Utility Determine that the specification is being implemented and 877 used. 879 Performance Measurements on the performance implications of using 880 this approach should be made. 882 Alogrithm The utility of the algorithm, and possible variants, should 883 be investigated. 885 INTERNET--DRAFT User Friendly Naming October 1992 887 This format, and the procedures for resolving purported names, should 888 be evolved to an Internet Standard. The syntax can be expected to be 889 stable. In light of experience, the algorithm for resolving purported 890 names may be changed. 892 References 894 [CCI88] The Directory --- overview of concepts, models and services, 895 December 1988. CCITT X.500 Series Recommendations. 897 [HK92] S.E. Hardcastle-Kille. A string representation of 898 distinguished name. Request for Comments in preparation, 899 Department of Computer Science, University College London, 900 January 1992. 902 [Kil89a] S.E. Kille. New name forms, May 1989. ISO/IEC/JTC 21/ 903 WG4/N797 UK National Body Contribution to the Oslo Directory 904 Meeting. 906 [Kil89b] S.E. Kille. The THORN large scale pilot exercise. Computer 907 Networks and ISDN Systems, 16(1):143--145, January 1989. 909 [Kil90] S.E. Kille. Using the OSI directory to achieve user friendly 910 naming. Research Note RN/20/29, Department of Computer 911 Science, University College London, February 1990. 913 [KRRT90] S.E. Kille, C.J. Robbins, M. Roe, and A. Turland. The ISO 914 development environment: User's manual (version 6.0), 915 January 1990. Volume 5: QUIPU. 917 [Neu89] G.W. Neufeld. Descriptive names in X.500. In SIGCOMM 89 918 Symposiun Communications Architectures and Protocols, pages 919 64--71, September 1989. 921 [Pet88] L.L. Petersen. The profile naming service. ACM Transactions 922 on Computing Systems, 6(4):341--364, November 1988. 924 [Ros90] M.T. Rose. Realizing the White Pages using the OSI Directory 925 Service. Technical Report 90--05--10--1, Performance Systems 926 International, Inc., May 1990. 928 INTERNET--DRAFT User Friendly Naming October 1992 930 11 Security Considerations 932 Security considerations are not discussed in this INTERNET--DRAFT . 934 12 Author's Address 936 Steve Hardcastle-Kille 937 Department of Computer Science 938 University College London 939 Gower Street 940 WC1E 6BT 941 England 943 Phone: +44-71-380-7294 945 EMail: S.Kille@CS.UCL.AC.UK 947 DN: CN=Steve Hardcastle-Kille, OU=Computer Science, 948 O=University College London, C=GB 950 UFN: S. Hardcastle-Kille, Computer Science 951 University College London, GB 953 INTERNET--DRAFT User Friendly Naming October 1992 955 A Pseudo-code for the matching algorithm 957 The following pseudo-code is intended to clarify the matching 958 algorithm. The language uses ASN.1 data types, with flow control 959 `C'-like,_but_with_keywords_upper--cased.______________________________ 961 PurportedName ::= SEQUENCE OF String 962 -- simplication, as attribute types can optionally be 963 -- specified 965 -- Each element of the Purported Name is a string 966 -- which has been parsed from the BNF 968 Attribute ::= SEQUENCE { 10 969 type OBJECT IDENTIFIER, 970 value ANY } 972 RDN ::= Attribute -- simplification, as can be multi-value 974 DN ::= SEQUENCE OF RDN 976 Environment ::= SEQUENCE OF DN 978 20 979 EnvironmentList ::= SEQUENCE OF SEQUENCE { 980 lower-bound INTEGER, 981 upper-bound INTEGER, 982 environment Environment } 984 friendlyMatch(p: PurportedName; el: EnvironmentList): SET OF DN 985 { 986 -- Find correct environment 987 30 988 IF length(el) == 0 THEN return(NULL); 990 IF length(p) <= head(el).upper-bound 991 && length(p) >= head(el).lower-bound THEN 992 return envMatch (p, head(el).environment); 993 ELSE 994 return(friendlyMatch(p, tail(el)); 996 INTERNET--DRAFT User Friendly Naming October 1992 998 } 1000 40 1001 envMatch(p: PurportedName; e: Environment): SET OF DN 1002 { 1003 -- Check elements of environment 1004 -- in the defined order 1006 matches: SET OF DN; 1008 IF length(e) == 0 THEN return(NULL); 1010 matches = purportedMatch(head(e).DN, p) 50 1011 IF matches != NULL THEN 1012 return(matches); 1013 ELSE 1014 return(envMatch(p, tail(e)); 1015 } 1017 purportedMatch(base: DN; p: PurportedName): SET OF DN 1018 { 1019 s: String = head(p); 60 1020 matches: SET OF DN = NULL; 1022 IF length(p) == 1 THEN 1023 IF length(base) == 0 THEN 1024 IF (matches = rootSearch(s)) != NULL THEN 1025 return(matches); 1026 ELSE return(leafSearch(base, s, one-level); 1027 ELSE IF length(base) == 1 THEN 1028 IF (matches = intSearch(base, s)) != NULL THEN 1029 return(matches); 70 1030 ELSE return(leafSearch(base, s, one-level); 1031 ELSE 1032 IF (matches = leafSearch(base, s, subtree)) != NULL THEN 1033 return(matches); 1034 ELSE return(intsearch(base, s); 1036 IF length(base) == 0 THEN 1037 FOR x IN rootSearch(s) DO 1038 matches += (purportedMatch(x, tail(p)); 80 1039 ELSE 1041 INTERNET--DRAFT User Friendly Naming October 1992 1043 FOR x IN intSearch(base, s) DO 1044 matches += (purportedMatch(x, tail(p)); 1045 return(matches); 1046 } 1048 -- General. Might need to tighten the filter for short strings, 1049 -- in order to stop being flooded. Alternatively, this could be 1050 -- done if the loose search hists a size limit 90 1052 rootSearch(s: String): SET OF DN 1053 { 1054 IF length(s) == 2 THEN 1055 return(search(NULL, one-level, s, {CountryName, 1056 FriendlyCountryName, OrganizationName}, 1057 {exact}, {Country, Organisation})); 1058 -- test exact match only 1059 -- probably a country code 1060 ELSE 100 1061 return(search(NULL, one-level, s, {OrganizationName, 1062 FriendlyCountryName}, {substring, approx}, 1063 {Country, Organisation})); 1064 } 1066 intSearch( base: DN; s: String) 1067 { 1068 IF present(base, OrgUnitName) THEN 1069 return(search(base, one-level, s, {OrgUnitName}, 110 1070 {substring, approx}, {OrgUnit})); 1071 ELSE IF present(base, OrganisationName) THEN 1072 return(search(base, one-level, s, {OrgUnitName, 1073 LocalityName}, {substring, approx}, 1074 {Organization, OrgUnit, Locality})); 1075 ELSE IF present(base, LocalityName) THEN 1076 return(search(base, one-level, s, {OrganisationName}, 1077 {substring, approx}, {Locality}); 1078 ELSE 1079 return(search(base, one-level, s, {OrganisationName,120 1080 LocalityName}, {substring, approx}, 1081 {Organisation, Locality})); 1082 } 1083 INTERNET--DRAFT User Friendly Naming October 1992 1085 present(d: DN; t: AttributeType): BOOLEAN 1086 { 1087 FOR x IN d DO 1088 IF x.type == t THEN return(TRUE); 1089 return(FALSE); 130 1090 } 1092 SearchScope := ENUMERATED (base-object, one-level, subtree) 1094 leafSearch(base: DN; s: String; search-scope: SearchScope) 1095 { 1096 return(search(base, search-scope, s, {CommonName, Surname, 1097 UserId}, {substring, approx})); 1098 } 1099 140 1101 search(base: DN; search-scope: SearchScope; s: string; 1102 alist SET OF AttributeType; matchtypes SET OF MatchType 1103 objectClasses SET OF ObjectClass OPTIONAL): SET OF DN 1104 { 1105 -- mapped onto Directory Search, with OR conjunction 1106 -- of filter items 1108 return dNSelect (s, search-results, alist); 1109 } 150 1111 read(base: DN; alist SET OF AttributeType): SET OF Attribute; 1112 { 1113 -- mapped onto Directory Read 1114 -- Types repeated to deal with multiple values 1115 -- This would be implemented by returning selected info 1116 -- with the search operation 1117 } 1119 dNSelect(s: String; dlist SET OF DN; alist: SET OF AttributeType):16SET0OF DN 1120 { 1121 exact, good: SET OF DN; 1123 FOR x IN dlist DO 1124 IF last(DN).Value == s THEN 1125 exact += x; 1126 ELSE IF FOR y IN read(x, alist) DO 1127 IF y.value == s THEN 1128 good += x; 1130 INTERNET--DRAFT User Friendly Naming October 1992 1132 170 1134 IF exact != NULL THEN return(exact); 1135 IF good != NULL THEN return(good); 1136 return(userQuery(dlist)); 1137 } 1139 userQuery(dlist SET OF DN): SET OF DN 1140 { 1141 -- pass back up for manual checking 180 1142 -- user can strip all matches to force progres.... 1143 } 1145 head() -- return first element of list 1146 tail() -- return list with first element removed 1147 length() -- return size of list 1148 last() -- return last element of list 1150 ____________________Figure_2:__Matching_Algorithm______________________