1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403
|
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))
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard. Discussion and
suggestions for improvement are requested. Please refer to the
current edition of the "IAB Official Protocol Standards" for the
standardization state and status of this protocol. Distribution of
this memo is unlimited.
Abstract
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 format for
representing names, and to procedures to resolve them. This leads to
a specification which allows directory names to be communicated
between humans. The format in this specification is identical to
that defined in [HK93], and it is intended that these specifications
are compatible. Please send comments to the author or to the
discussion group: <osi-ds@CS.UCL.AC.UK>.
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
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
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 1 in section
4.1.
If "Joe Bloggs" is supplied, a subtree search of
Physics, University College London, GB
will be made, and the user 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
Hardcastle-Kille [Page 15]
RFC 1484 User Friendly Naming July 1993
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
Hardcastle-Kille" will lead to a failed subtree search of
Physics, University College London, GB
and lead straight to a subtree search of
University College London, GB
This will lead to an exact value match, and so a single entry
returned without prompting.
If "Andrew Findlay, Brunel" is supplied, the first element of the
environment will be skipped, single level search of "Brunel" under
"GB" will find:
Brunel University, GB
and a subtree search for "Andrew 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
Hardcastle-Kille [Page 16]
RFC 1484 User Friendly Naming July 1993
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.
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 1 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
Hardcastle-Kille [Page 17]
RFC 1484 User Friendly Naming July 1993
wildcards efficiently, it may be preferable to only use trailing
wildcards. The effect of this on the algorithm needs to be
investigated.
Implementors of this specification are encouraged to investigate
variants of the basic algorithm. A final specification should depend
on experience with such variants.
-> t hales, csiro, australia
Found good match(es) for 'australia'
Found exact match(es) for 'csiro'
Please select from the following:
Trevor Hales, OC, HPCC, DIT, IICT, CSIRO, AU [y/n] ? y
The following were matched...
Trevor Hales, OC, HPCC, DIT, IICT, CSIRO, AU
-> g michaelson, queensland, au
Found exact match(es) for 'au'
Please select from the following:
University of Queensland, AU [y/n] ? y
Axolotl, AU [y/n] ? n
Please select from the following:
George Michaelson, Prentice Computer Centre, University of
Queensland, AU [y/n] ? y
Manager, University of Queensland, AU [y/n] ? n
The following were matched...
George Michaelson, Prentice Computer Centre, University of
Queensland, AU
-> r needham, cambridge
Found good match(es) for 'cambridge'
Please select from the following:
Roger Needham, Computer Lab, Cambridge University [y/n] ? y
The following were matched...
Roger Needham, Computer Lab, Cambridge University
-> kirstein
Found good match(es) for 'kirstein'
The following were matched...
Peter Kirstein
Figure 1: Example usage of User Friendly Naming
9. Relationship to other work
Colin Robbin's work on the interface "Tom" and implementation of a
distribution list interface strongly influenced this specification
[KRRT90].
Hardcastle-Kille [Page 18]
RFC 1484 User Friendly Naming July 1993
Some of the ideas used here originally came from a UK Proposal to the
ISO/CCITT Directory Group on "New Name Forms" [Kil89a]. This
defined, and showed how to implement, four different types of names:
Typed and Ordered
The current Distinguished Name is a restricted example of this type
of name.
Untyped and Ordered
This is the type of name proposed here (with some extensions to allow
optional typing). It is seen as meeting the key user requirement of
disliking typed names, and is efficient to implement.
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 [Kil89b].
Untyped and Unordered
Surprisingly this form of name can be supported quite easily.
However, a considerable gain in efficiency can be achieved by
requiring ordering. In practice, users can supply this easily.
Therefore, this type of name is not proposed.
10. Issues
The following issues are noted, which would need to be resolved
before this document is progressed as an Internet Standard.
Potential Ambiguity
Whilst the intention of the notation is to allow for specification of
alternate values, it inherently allows for ambiguous names to be
specified. It needs to be demonstrated that problems of this
characteristic are outweighed by other benefits of the notation.
Utility
Determine that the specification is being implemented and used.
Hardcastle-Kille [Page 19]
RFC 1484 User Friendly Naming July 1993
Performance
Measurements on the performance implications of using this approach
should be made.
Alogrithm
The utility of the algorithm, and possible variants, should be
investigated.
This format, and the procedures for resolving purported names, should
be evolved. The syntax can be expected to be stable. In light of
experience, the algorithm for resolving purported names may be
changed.
11. References
[CCI88] The Directory --- overview of concepts, models and services,
December 1988. CCITT X.500 Series Recommendations.
[HK93] S.E. Hardcastle-Kille. A string representation of
distinguished names. RFC 1485, Department of Computer
Science, University College London, July 1993.
[Kil89a] S.E. Kille. New name forms, May 1989. ISO/IEC/JTC 21/
WG4/N797 UK National Body Contribution to the Oslo Directory
Meeting.
[Kil89b] S.E. Kille. The THORN large scale pilot exercise. Computer
Networks and ISDN Systems, 16(1):143--145, January 1989.
[Kil90] S.E. Kille. Using the OSI directory to achieve user friendly
naming. Research Note RN/20/29, Department of Computer
Science, University College London, February 1990.
[KRRT90] S.E. Kille, C.J. Robbins, M. Roe, and A. Turland. The ISO
development environment: User's manual (version 6.0),
January 1990. Volume 5: QUIPU.
[Neu89] G.W. Neufeld. Descriptive names in X.500. In SIGCOMM 89
Symposiun Communications Architectures and Protocols, pages
64--71, September 1989.
[Pet88] L.L. Petersen. The profile naming service. ACM Transactions
on Computing Systems, 6(4):341--364, November 1988.
Hardcastle-Kille [Page 20]
RFC 1484 User Friendly Naming July 1993
[Ros90] M.T. Rose. Realizing the White Pages using the OSI Directory
Service. Technical Report 90--05--10--1, Performance Systems
International, Inc., May 1990.
12. Security Considerations
Security issues are not discussed in this memo.
13. Author's Address
Steve Hardcastle-Kille
ISODE Consortium
P.O. Box 505
London
SW11 1DX
England
Phone:+44-71-223-4062
EMail: S.Kille@ISODE.COM
DN: CN=Steve Hardcastle-Kille,
O=ISODE Consortium, C=GB
UFN: S. Hardcastle-Kille,
ISODE Consortium, GB
A. Pseudo-code for the matching algorithm
The following pseudo-code is intended to clarify the matching
algorithm. The language uses ASN.1 data types, with flow control
"C"-like,but with keywords upper--cased.
____________________________________________________________________
PurportedName ::= SEQUENCE OF String
-- simplication, as attribute types can optionally be
-- specified
-- Each element of the Purported Name is a string
-- which has been parsed from the BNF
Attribute ::= SEQUENCE { 10
type OBJECT IDENTIFIER,
value ANY }
RDN ::= Attribute -- simplification, as can be multi-value
DN ::= SEQUENCE OF RDN
Hardcastle-Kille [Page 21]
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
______________________________________________________________________
Hardcastle-Kille [Page 25]
|