File: rfc1781.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1459 lines) | stat: -rw-r--r-- 47,129 bytes parent folder | download | duplicates (8)
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
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459






Network Working Group                                           S. Kille
Request for Comments: 1781                              ISODE Consortium
Obsoletes: 1484                                               March 1995
Category: Standards Track


        Using the OSI Directory to Achieve User Friendly Naming

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) 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 standard
   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 [5], and it is intended that these
   specifications are compatible.

Table of Contents

   1.   Why a notation is needed ...................................   2
   2.   The Notation ...............................................   3
   3.   Communicating Directory Names ..............................   7
   4.   Matching a purported name ..................................   9
       4.1    Environment ..........................................   9
       4.2    Matching .............................................  10
       4.3    Top Level ............................................  12
       4.4    Intermediate Level ...................................  13
       4.5    Bottom Level .........................................  14
   5.   Examples ...................................................  14
   6.   Support required from the standard .........................  15



Kille                                                           [Page 1]

RFC 1781                  User Friendly Naming                March 1995


   7.   Support of OSI Services ....................................  15
   8.   Experience .................................................  16
   9.   Relationship to other work .................................  17
   10.  Issues .....................................................  19
   11.  References .................................................  20
   12.  Security Considerations ....................................  21
   13.  Author's Address ...........................................  21
   A.   Pseudo-code for the matching algorithm .....................  22
   List of Figures
       1.     Example usage of User Friendly Naming ................  18
       2.     Matching Algorithm ...................................  22
   List of Tables
       1.     Local environment for private DUA ....................  10
       2.     Local environment for US Public DUA ..................  11

1.  Why a notation is needed

   Many OSI Applications make use of Distinguished Names (DN) as defined
   in the OSI Directory [1].  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.

   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 [5] for representing
   distinguished names.  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.



Kille                                                           [Page 2]

RFC 1781                  User Friendly Naming                March 1995


   (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 [5].  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 [4].  Some examples of the specification are given
   here.  The author's User Friendly Name (UFN) might be written:

   Steve Kille, Computer Science, University College London, GB

   or

   S. Kille, Computer Science, University College London, GB

   This may be folded, perhaps to display in multi-column format.  For
   example:

   Steve Kille,
   Computer Science,
   University College London,
   GB

   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



Kille                                                           [Page 3]

RFC 1781                  User Friendly Naming                March 1995


   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:

   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:







Kille                                                           [Page 4]

RFC 1781                  User Friendly Naming                March 1995


   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.

    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.





Kille                                                           [Page 5]

RFC 1781                  User Friendly Naming                March 1995


   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.

   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,
   C=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 Kille



Kille                                                           [Page 6]

RFC 1781                  User Friendly Naming                March 1995


   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 [5].  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 Kille, University College London, GB

   In some cases, this can be combined with abbreviation.  For example:

   Steve Kille, University College London

   Approximation

   Approximate renditions or alternate values of one or
   more of the components will be supplied.  For example:

   Stephen Kille, CS, UCL, GB

   or

   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 [5], 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.






Kille                                                           [Page 7]

RFC 1781                  User Friendly Naming                March 1995


   1.  Distinguished Name or DN. A representation of the distinguished
       name, according to the specification of [5].

   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.  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.





Kille                                                           [Page 8]

RFC 1781                  User Friendly Naming                March 1995


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.

   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 names 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



Kille                                                           [Page 9]

RFC 1781                  User Friendly Naming                March 1995


   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, then a national organisation, and
   finally a country.

   Two components

   Most significant component is first assumed to be a national
   organisation, then a department (this might be reversed in some
   organisations), and finally a country.

   Three or more components

   The most significant component is first assumed to be a country, then
   a national organisation, and finally a department.

4.2  Matching

   A purported name will be supplied, usually with a small number of
   components.  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

         +-----------+--------------------------------------+
         |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



Kille                                                          [Page 10]

RFC 1781                  User Friendly Naming                March 1995


                     +------------+-----------+
                     | Number of  |Environment|
                     | Components |           |
                     +------------+-----------+
                     |  1,2       | US        |
                     |            | CA        |
                     |            | --        |
                     +------------+-----------+
                     |  3+        | --        |
                     |            | US        |
                     |            | CA        |
                     +------------+-----------+

            Table 2:  Local environment for US Public DUA

   Stephen 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 Kille should be a good match of S. Kille, S.E. Kille or Steve
       Kille even if these are not explicit alternate values).

   Poor Any other substring or approximate match

   Following a match, the reference can be followed, or the user
   prompted.  If there are multiple matches, more than one path may be
   followed.  There is also a shift/reduce type of choice:  should any
   partial matches be followed or should the next element of the



Kille                                                          [Page 11]

RFC 1781                  User Friendly Naming                March 1995


   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 matches, 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.






Kille                                                          [Page 12]

RFC 1781                  User Friendly Naming                March 1995


   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.)







Kille                                                          [Page 13]

RFC 1781                  User Friendly Naming                March 1995


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 on Page
   13.

   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



Kille                                                          [Page 14]

RFC 1781                  User Friendly Naming                March 1995


   will be made, looking for a person.  Then a single level search will
   be made looking for Org Unit, and

   Computer Science, University College London, GB

   will be returned without prompting (exact match).  Supplying "Steve
   Kille" will lead to a failed subtree search of

   Physics, University College London, GB

   and lead straight to a subtree search of

   University College London, GB

   This will lead to an exact value match, and so a single entry
   returned without prompting.

   If "Andrew Findlay, Brunel" is supplied, the first element of the
   environment will be skipped, 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
   is named "gannet", then this could easily be identified by the name:



Kille                                                          [Page 15]

RFC 1781                  User Friendly Naming                March 1995


   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 [9], and
   within an prototype interface for managing distribution lists.  The
   user reaction has been favourable:

   Some issues have arisen from this experience:

    o  Where there is more than one level of Organisational Unit, and the
       user guesses one which is not immediately below the organisation,
       the algorithm works badly.  There does not appear to be an easy
       fix for this.  It is not clear if this is a serious deficiency.

    o  Substring searching is currently done with leading and trailing
       wildcards.  As many implementations will not implement leading
       wildcards efficiently, it may be preferable to only use trailing
       wildcards.  The effect of this on the algorithm needs to be
       investigated.




Kille                                                          [Page 16]

RFC 1781                  User Friendly Naming                March 1995


   Implementors of this specification are encouraged to investigate
   variants of the basic algorithm.  A final specification should depend
   on experience with such variants.

9.  Relationship to other work

   Colin Robbin's work on the interface "Tom" and implementation of a
   distribution list interface strongly influenced this specification
   [6].

   Some of the ideas used here originally came from a UK Proposal to the
   ISO/CCITT Directory Group on "New Name Forms" [2].  This defined, and
   showed how to implement, four different types of names:

   Typed and Ordered The current Distinguished Name is a restricted
   example of this type of name.



































Kille                                                          [Page 17]

RFC 1781                  User Friendly Naming                March 1995


   -> 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

   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
   [7], and Peterson proposes the Profile system to provide this [8].



Kille                                                          [Page 18]

RFC 1781                  User Friendly Naming                March 1995


   The author contends that whilst typed naming is interesting for some
   types of searching (e.g., yellow page searching), it is less
   desirable for naming objects.  This is borne out by operational
   experience with OSI Directories [3].

   Untyped and Unordered

   Surprisingly this form of name can be supported quite easily.
   However, a considerable gain in efficiency can be achieved by
   requiring ordering.  In practice, users can supply this easily.
   Therefore, this type of name is not proposed.

10.  Issues

   The following issues are noted, which would need to be resolved
   before this document is progressed as an Internet Standard.

   Potential Ambiguity

   Whilst the intention of the notation is to allow for specification of
   alternate values, it inherently allows for ambiguous names to be
   specified.  It needs to be demonstrated that problems of this
   characteristic are outweighed by other benefits of the notation.

   Utility

   Determine that the specification is being implemented and used.

   Performance

   Measurements on the performance implications of using this approach
   should be made.

   Alogrithm

   The utility of the algorithm, and possible variants, should be
   investigated.

   This format, and the procedures for resolving purported names, should
   be evolved to an Internet Standard.  The syntax can be expected to be
   stable.  In light of experience, the algorithm for resolving
   purported names may be changed.









Kille                                                          [Page 19]

RFC 1781                  User Friendly Naming                March 1995


11.  References

   [1] The Directory --- overview of concepts, models and services,
       1993. CCITT X.500 Series Recommendations.

   [2] S.E. Kille. New name forms, May 1989.  ISO/IEC/JTC 21/ WG4/N797
       UK National Body Contribution to the Oslo Directory Meeting.

   [3] S.E. Kille. The THORN large scale pilot exercise.  Computer
       Networks and ISDN Systems, 16(1):143--145, January 1989.

   [4] S.E. Kille. Using the OSI directory to achieve user friendly
       naming. Research Note RN/20/29, Department of Computer Science,
       University College London, February 1990.

   [5] Kille, S., "A String Representation of Distinguished Names", RFC
       1779, ISODE Consortium, March 1995.

   [6] S.E. Kille and C.J. Robbins. The ISO development environment:
       User's manual (version 7.0), July 1991. Volume 5:  QUIPU.

   [7] G.W. Neufeld. Descriptive names in X.500.  In SIGCOMM 89
       Symposiun Communications Architectures and Protocols, pages 64--
       71, September 1989.

   [8] L.L. Petersen. The profile naming service.  ACM Transactions on
       Computing Systems, 6(4):341--364, November 1988.

   [9] M.T. Rose. Realizing the White Pages using the OSI Directory
       Service. Technical Report 90--05--10--1, Performance Systems
       International, Inc., May 1990.




















Kille                                                          [Page 20]

RFC 1781                  User Friendly Naming                March 1995


12.  Security Considerations

   Security issues are not discussed in this memo.

13.  Author's Address

   Steve Kille
   ISODE Consortium
   The Dome
   The Square
   Richmond, Surrey
   TW9 1DT
   England

   Phone:+44-181-332-9091
   EMail:  S.Kille@ISODE.COM

   DN: CN=Steve Kille,
   O=ISODE Consortium, C=GB

   UFN: S. Kille,
   ISODE Consortium, GB





























Kille                                                          [Page 21]

RFC 1781                  User Friendly Naming                March 1995


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 {
        type OBJECT IDENTIFIER,
        value ANY }

RDN ::= Attribute -- simplification, as can be multi-value

DN ::= SEQUENCE OF RDN

Environment ::= SEQUENCE OF DN

EnvironmentList ::= SEQUENCE OF SEQUENCE {
                        lower-bound INTEGER,
                        upper-bound INTEGER,
                        environment Environment }


friendlyMatch(p:  PurportedName; el:  EnvironmentList):    SET OF DN
{
                                -- Find correct environment

        IF length(el) == 0 THEN return(NULL);

        IF length(p) <= head(el).upper-bound
                        && length(p) >= head(el).lower-bound THEN
                return envMatch (p, head(el).environment);
        ELSE
                return(friendlyMatch(p, tail(el));
}

envMatch(p:  PurportedName; e:  Environment):    SET OF DN
{
                                -- Check elements of environment
                                -- in the defined order

        matches:  SET OF DN;



Kille                                                          [Page 22]

RFC 1781                  User Friendly Naming                March 1995


        IF length(e) == 0 THEN return(NULL);

        matches = purportedMatch(head(e).DN, p)
        IF matches != NULL THEN
                return(matches);
        ELSE
                return(envMatch(p, tail(e));
}


purportedMatch(base:  DN; p:  PurportedName):  SET OF DN
{
        s:  String = head(p);
        matches:  SET OF DN = NULL;

        IF length(p) == 1 THEN
                IF length(base) == 0 THEN
                        IF (matches = rootSearch(s)) != NULL THEN
                                return(matches);
                        ELSE return(leafSearch(base, s, one-level);
                ELSE IF length(base) == 1 THEN
                        IF (matches = intSearch(base, s)) != NULL THEN
                                return(matches);
                        ELSE return(leafSearch(base, s, one-level);
                ELSE
                        IF (matches = leafSearch(base, s, subtree)) !=
                                NULL THEN return(matches);
                        ELSE return(intsearch(base, s);


        IF length(base) == 0 THEN
                FOR x IN rootSearch(s) DO
                        matches += (purportedMatch(x, tail(p));
        ELSE
                FOR x IN intSearch(base, s) DO
                        matches += (purportedMatch(x, tail(p));
        return(matches);
}













Kille                                                          [Page 23]

RFC 1781                  User Friendly Naming                March 1995


-- General.    Might need to tighten the filter for short strings,
-- in order to stop being flooded.    Alternatively, this could be
-- done if the loose search hits a size limit

rootSearch(s:  String):  SET OF DN
{
        IF length(s) == 2 THEN
                return(search(NULL, one-level, s, {CountryName,
                        FriendlyCountryName, OrganizationName},
                        {exact}, {Country, Organisation}));
                        -- test exact match only
                        -- probably a country code
        ELSE
                return(search(NULL, one-level, s, {OrganizationName,
                        FriendlyCountryName}, {substring, approx},
                        {Country, Organisation}));
}


intSearch( base:  DN; s:  String)
{
        IF present(base, OrgUnitName) THEN
                return(search(base, one-level, s, {OrgUnitName},
                        {substring, approx}, {OrgUnit}));
        ELSE IF present(base, OrganisationName) THEN
                return(search(base, one-level, s, {OrgUnitName,
                        LocalityName}, {substring, approx},
                        {Organization, OrgUnit, Locality}));
        ELSE IF present(base, LocalityName) THEN
                return(search(base, one-level, s, {OrganisationName},
                        {substring, approx}, {Locality});
        ELSE
                return(search(base, one-level, s, {OrganisationName,
                        LocalityName}, {substring, approx},
                        {Organisation, Locality}));
}


present(d:  DN; t:  AttributeType):  BOOLEAN
{
        FOR x IN d DO
                IF x.type == t THEN return(TRUE);
        return(FALSE);
}

SearchScope := ENUMERATED (base-object, one-level, subtree)

leafSearch(base:  DN; s:  String; search-scope:  SearchScope)



Kille                                                          [Page 24]

RFC 1781                  User Friendly Naming                March 1995


{
        return(search(base, search-scope, s, {CommonName, Surname,
                UserId}, {substring, approx}));
}

search(base:  DN; search-scope:  SearchScope; s:  string;
        alist SET OF AttributeType; matchtypes SET OF MatchType
        objectClasses SET OF ObjectClass OPTIONAL): SET OF DN
{
        -- mapped onto Directory Search, with OR conjunction
        -- of filter items

        return dNSelect (s, search-results, alist);
}

read(base:  DN; alist SET OF AttributeType):  SET OF Attribute;
{
        -- mapped onto Directory Read
        -- Types repeated to deal with multiple values
        -- This would be implemented by returning selected info
        -- with the search operation
}

dNSelect(s:  String; dlist SET OF DN;
                     alist:  SET OF AttributeType):16SET0OF DN
{
        exact, good:  SET OF DN;

        FOR x IN dlist DO
                IF last(DN).Value == s THEN
                        exact += x;
                ELSE IF FOR y IN read(x, alist) DO
                        IF y.value == s THEN
                                good += x;

        IF exact != NULL THEN return(exact);
        IF good != NULL THEN return(good);
        return(userQuery(dlist));
}

userQuery(dlist SET OF DN): SET OF DN
{
        -- pass back up for manual checking
        -- user can strip all matches to force progres....
}

head()    -- return first element of list
tail()    -- return list with first element removed



Kille                                                          [Page 25]

RFC 1781                  User Friendly Naming                March 1995


length()  -- return size of list
last()    -- return last element of list

                    Figure 2: Matching Algorithm















































Kille                                                          [Page 26]