File: rfc1617.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 (1571 lines) | stat: -rw-r--r-- 56,739 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
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571






Network Working Group                                          P. Barker
Request for Comments: 1617                     University College London
RARE Technical Report: 11                                       S. Kille
Obsoletes: 1384                                         ISODE Consortium
Category: Informational                                  T. Lenggenhager
                                                                  SWITCH
                                                                May 1994


      Naming and Structuring Guidelines for X.500 Directory Pilots

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   Deployment of a Directory will benefit from following certain
   guidelines. This document defines a number of naming and structuring
   guidelines focused on White Pages usage. Alignment to these
   guidelines is recommended for directory pilots. The final version of
   this document will replace RFC 1384.

Table of Contents

    1. Introduction                                                2
    2. DIT Structure                                               3
    2.1. Structure Rules                                           3
    2.2. The Top Level of the DIT                                  3
    2.3. Countries                                                 4
    2.4. Organisations                                             5
    2.4.1. Directory Manager, Postmaster & Secretary               5
    2.4.2. Depth of tree                                           6
    2.4.3. Real World Organisational Structure                     7
    2.5. Multi-National Organisations                              7
    2.5.1. The Multi-National as a Single Entity                   7
    2.5.2. The Multi-National as a Loose Confederation             8
    2.5.3. Loosely Linked DIT Sub-Trees                            9
    2.5.4. Summary of Advantages and Disadvantages of the
           Above Approaches                                        9
    3. Naming Style                                               10
    3.1. Multi-Component Relative Distinguished Names             11
    3.2. National Guidelines for Naming                           11
    3.3. Naming Organisation and Organisational Unit Names        11
    3.4. Naming Human Users                                       12
    3.5. Application Entities                                     13



RARE Working Group on Network Applications Support (WG-NAP)     [Page 1]

RFC 1617      Naming and Structuring Guidelines for X.500       May 1994


    4. Attribute Values                                           13
    4.1. Basic Attribute Syntaxes                                 13
    4.1.1. Printable String                                       14
    4.1.2. IA5 String - T.50                                      14
    4.1.3. Teletex String - T.61                                  14
    4.1.4. Case Ignore String                                     14
    4.1.5. Distinguished Name                                     14
    4.2. Languages & Transliteration                              14
    4.2.1. Languages other than English                           15
    4.2.2. Transliteration                                        15
    4.3. Access control                                           15
    4.4. Selected Attributes                                      16
    4.4.1. Personal Attributes                                    16
    4.4.2. Organisational Attributes                              18
    4.4.3. Local Attributes                                       19
    4.4.4. Miscellaneous Attributes                               20
    4.4.5. MHS Attributes                                         21
    4.4.6. Postal Attributes                                      21
    4.4.7. Telecom Attributes                                     22
    5. Miscellany                                                 22
    5.1. Schema consistency of aliases                            22
    5.2. Organisational Units                                     23
    6. References                                                 23
    7. Security Considerations                                    23
    8. Authors' Addresses                                         24
    9. Appendix - Example Entries                                 25

1. Introduction

   The intended audience for this document are mainly data managers
   using X.500 Directory Services. With the help of these guidelines it
   should be easier for them to define the structure for the part of the
   Directory Information Tree they want to model, e.g., the
   representation of their organisation in the Directory. In addition,
   decisions like which data elements to store for each kind of entry
   shall be supported.

   These guidelines concentrate mainly on the White Pages use of the
   Directory, the X.500 application with most operational experience
   today, nonetheless many recommendations are also valid for other
   applications of the Directory.

   As a pre-requisite to this document, it is assumed that the COSINE
   and Internet X.500 Schema is followed [1].







RARE Working Group on Network Applications Support (WG-NAP)     [Page 2]

RFC 1617      Naming and Structuring Guidelines for X.500       May 1994


2. DIT Structure

   The majority of this document is concerned with DIT structure, naming
   and the usage of attributes for organisations, organisational units
   and personal entries.

   This section briefly notes five other key issues.

2.1 Structure Rules

   A DIT structure is suggested in Annex B of X.521 [2], and it is
   recommended that Directory Pilots for White Pages services should
   follow these guidelines. Some simple restrictions should be applied,
   as described below. For further usage of the Directory like e-mail
   routing with the Directory or storage of network information in the
   Directory it will be necessary to follow the guidelines specified in
   the respective documents.

   One of the few exceptions to the basic DIT structure is, that
   international organisations will be stored immediately under the root
   of the tree. Multi-national organisations will be stored within the
   framework outlined, but with some use of aliases and attributes such
   as seeAlso to help bind together the constituent parts of these
   organisations. This is discussed in more detail in section 2.5.

   A general rule for the depth of a subtree is as follows: When a
   subtree is mainly accessed via searching, it should be as flat as
   possible to improve the performance, when the access will be mainly
   through read operations, the depth of the subtree is not a
   significant parameter for performance.

2.2 The Top Level of the DIT

   The following information will be present at the top level of the
   DIT:

   Participating Countries

      According to the standard the RDN is the ISO 3166 country code. In
      addition, the entries should contain suitable values of the
      friendlyCountryName attribute specified in RFC 1274. Use of this
      attribute is described in more detail in section 4.4.4.

   International Organisations

      An international organisation is an organisation, such as the
      United Nations, which inherently has a brief and scope covering
      many nations.  Such organisations might be considered to be



RARE Working Group on Network Applications Support (WG-NAP)     [Page 3]

RFC 1617      Naming and Structuring Guidelines for X.500       May 1994


      supra-national and this, indeed, is the raison-d'etre of such
      organisations. Such organisations will almost all be governmental
      or quasi-governmental. A multi-national organisation is an
      organisation which operates in more than one country, but is not
      supra-national. This classification includes the large commercial
      organisations whose production and sales are spread throughout a
      large number of countries.

      International organisations may be registered at the top level.
      This will not be done for multi-national organisations. Currently
      three organisations are registered so far: Inmarsat, Internet and
      North Atlantic Treaty Organization.

   Localities

      A few localities will be registered under the root. The chief
      purpose of these locality entries is to provide a "natural" parent
      node for organisations which are supra-national, and yet which do
      not have global authority in their particular field. Such
      organisations will usually be governmental or quasi-governmental.
      Example localities might include: Europe, Africa, West Indies.
      Example organisations within Europe might include: European Court
      of Justice, European Space Agency, European Commission.

   DSA Information

      Some information on DSAs may be needed at the top level.  This
      should be kept to a minimum.

   The only directory information for which there is a recognised top
   level registration authority is countries. Registration of other
   information at the top level may potentially cause problems. At this
   stage, it is argued that the benefit of limiting additional top level
   registrations outweighs these problems. However, this potential
   problem should be noted by anyone making use of such a registration.

2.3 Countries

   The national standardisation bodies will define national guidelines
   for the structure of the national part of the DIT. In the interim,
   the following simple structure should suffice. The country entry will
   appear immediately beneath the root of the tree. Organisations which
   have national significance should have entries immediately beneath
   their respective country entries. Smaller organisations which are
   only known in a particular locality should be placed underneath
   locality entries representing states or similar geographical
   divisions. Entry for private persons will be listed under the
   locality entries. An example plan evolving for the US is the work of



RARE Working Group on Network Applications Support (WG-NAP)     [Page 4]

RFC 1617      Naming and Structuring Guidelines for X.500       May 1994


   the North American Directory Forum [3]. Another example is the
   organisation of the X.500 namespace as standardized in Australia [4].

2.4 Organisations

   Large organisations will probably need to be sub-divided by
   organisational units to help in the disambiguation of entries for
   people with common names. Entries for people and roles will be stored
   beneath organisations or organisational units.

   The organisation entry itself shall contain the information necessary
   to contact the organisation: for example, postal address, telephone
   and fax numbers.

   Although the structure of organisations often changes considerably
   over time, the aim should be to minimise the number of changes to the
   DIT. Note that renaming a superior, department entry has the effect
   of changing the DN of all subordinate entries. This has an
   undesirable impact on the service for several reasons. Alias entries
   and certain attributes or ordinary entries such as seeAlso, secretary
   and roleOccupant use DNs to maintain links with other entries. These
   references are one-way only and the Directory standard offers no
   support to automatically update all references to an entry once its
   DN changes.

2.4.1 Directory Manager, Postmaster & Secretary

   Similar to messaging, where every domain has its postmaster address
   it is highly recommended that each organisation in the X.500
   Directory has two entries: Postmaster and Directory Manager. In
   addition, Secretary entries for an organisation and its units should
   be listed. If this guidance is followed, users will benefit because
   it will be straightforward to find the right contacts for questions
   or problems with the service.

   These entries should use the object class organizationalRole with the
   roleOccupant attributes containing the distinguished names of the
   persons in charge of this role. The values

      CN=Directory Manager

      CN=Postmaster

      CN=Secretary

   should be added as additional values whenever another language than
   English is used for the name of the entries.




RARE Working Group on Network Applications Support (WG-NAP)     [Page 5]

RFC 1617      Naming and Structuring Guidelines for X.500       May 1994


2.4.2 Depth of tree

   The broad recommendation for White Pages is that the DIT should be as
   flat as possible. A flat tree means that Directory names will be
   relatively short, and probably somewhat similar in length and
   component structure to paper mail addresses. A deep DIT would imply
   long Directory names, with somewhat arbitrary component parts, with a
   result which it is argued seems less natural. Any artificiality in
   the choice of names militates against successful querying.

   A presumption behind this style of naming is that most querying will
   be supported by the user specifying convenient strings of characters
   which will be mapped onto powerful search operations.  The
   alternative approach of the user browsing their way down the tree and
   selecting names from large numbers of possibilities may be more
   appropriate in some cases, and a deeper tree facilitates this.
   However, these guidelines recommend a shallow tree, and implicitly a
   search oriented approach.

   It may be considered that there are two determinants of DIT depth:
   first, how far down the DIT an organisation is placed; second, the
   structure of the DIT within organisations.

   The structure of the upper levels of the tree will be determined in
   due course by various registration authorities, and the pilot will
   have to work within the given structure. However, it is important
   that the various pilots are cognisant of what the structures are
   likely to be, and move early to adopt these structures.

   The other principal determinant of DIT depth is whether an
   organisation splits its entries over a number of organisational
   units, and if so, the number of levels. The recommendation here is
   that this sub-division of organisations is kept to a minimum. A
   maximum of two levels of organisational unit should suffice even for
   large organisations. Organisations with only a few tens or hundreds
   of employees should strongly consider not using organisational units
   at all. It is noted that there may be some problems with choice of
   unique RDNs when using a flat DIT structure. Multi-component RDNs can
   alleviate this problem: see section 3.1. The standard X.521
   recommends that an organizationalUnitName attribute can also be used
   as a naming attribute to disambiguate entries [2]. Further
   disambiguation may be achieved by the use of a personalTitle or
   userId attribute in the RDN.








RARE Working Group on Network Applications Support (WG-NAP)     [Page 6]

RFC 1617      Naming and Structuring Guidelines for X.500       May 1994


2.4.3 Real World Organisational Structure

   Another aspect on designing the DIT structure for an organisation is
   the administrative structure within a company. Using the same
   structure in the DIT might help in distributing maintenance authority
   to the different units. Please note comments on the stability of the
   DIT structure in section 2.4.

2.5 Multi-National Organisations

   The standard says that only international organisations may be placed
   under the root of the DIT. This implies that multi-national
   organisations must be represented as a number of separate entries
   underneath country or locality entries. This structure makes it more
   awkward to use X.500 within a multi-national to provide an internal
   organisational directory, as the data is now spread widely throughout
   the DIT, rather than all being grouped within a single sub-tree.

   Many people have expressed the view that this restriction is a severe
   limitation of X.500, and argue that the intentions of the standard
   should be ignored in this respect. This note argues, though, that the
   standard should be followed.

   No attempt to precisely define multinational organisation is essayed
   here. Instead, the observation is made that the term is applied to a
   variety of organisational structures, where an organisation operates
   in more than one country. This suggests that a variety of DIT
   structures may be appropriate to accommodate these different
   organisational structures. This document suggests three approaches,
   and notes some of the characteristics associated with each of these
   approaches.

   Before considering the approaches, it is worth bearing in mind again
   that a major aim in the choice of a DIT structure is to facilitate
   querying, and that approaches which militate against this should be
   avoided wherever possible.

2.5.1 The Multi-National as a Single Entity

   In many cases, a multi-national organisation will operate with a
   highly centralised structure. While the organisation may have large
   operations in a number of countries, the organisation is strongly
   controlled from the centre and the disparate parts of the
   organisation exist only as limbs of the main organisation. In such a
   situation, the model shown in figure 1 may be the best choice.






RARE Working Group on Network Applications Support (WG-NAP)     [Page 7]

RFC 1617      Naming and Structuring Guidelines for X.500       May 1994


                            ROOT

                           / | \
                          /  |  \

                      C=GB  C=FR  C=US

                     /       |       \
                    /        |        \

          O=MultiNat---->O=MultiNat<----O=MultiNat

                         /    |    \
                        /     |     \
                       /      |      \

                 l=abc      ou=def     l=fgi

                     ---> means "alias to"

      Figure 1: The multi-national as a single entity

   The organisation's entries all exist under a single sub-tree. The
   organisational structure beneath the organisation entry should
   reflect the perceived structure of the organisation, and so no
   recommendations on this matter can be made here. To assist the person
   querying the directory, alias entries should be created under all
   countries where the organisation operates.

2.5.2 The Multi-National as a Loose Confederation

   Another common model of organisational structure is that where a
   multi-national consists of a number of national entities, which are
   in large part independent of both sibling national entities, and of
   any central entity. In such cases, the model shown in Figure 2 may be
   a better choice. Organisational entries exist within each country,
   and only that country's localities and organisational units appear
   directly beneath the appropriate organisational entry.













RARE Working Group on Network Applications Support (WG-NAP)     [Page 8]

RFC 1617      Naming and Structuring Guidelines for X.500       May 1994


                              ROOT

                             / | \
                            /  |  \
                        C=GB C=FR C=US

                        /      |     \
                       /       |      \
              O=MultiNat   O=MultiNat   O=MultiNat

             /    |        /    |   \        |    \
            /     |       /     |    \       |     \

        L=FR    L=GB<---L=GB     |   L=US--->L=US   L=FR
          \                      |                 /
           ------------------->L=FR<----------------

                      ---> means "alias to"

      Figure 2: The multi-national as a loose confederation

   Some binding together of the various parts of the organisation can be
   achieved by the use of aliases for localities and organisational
   units, and this can be done in a highly flexible fashion. In some
   cases, the national view might not contain all branches of the
   company, as illustrated in Figure 2.

2.5.3 Loosely Linked DIT Sub-Trees

   A third approach is to avoid aliasing altogether, and to use the
   looser binding provided by an attribute such as seeAlso. This
   approach treats all parts of an organisation as essentially separate.

   A unified view of the organisation can only be achieved by user
   interfaces choosing to follow the seeAlso links. This is a key
   difference with aliasing, where decisions to follow links may be
   specified within the protocol. (Note that it may be better to specify
   another attribute for this purpose, as seeAlso is likely to be used
   for a wide variety of purposes.)

2.5.4 Summary of Advantages and Disadvantages of the Above Approaches

   Providing an internal directory

      All the above methods can be used to provide an internal
      directory. In the first two cases, the linkage to other parts of
      the organisation can be followed by the protocol and thus
      organisation-wide searches can be achieved by single X.500



RARE Working Group on Network Applications Support (WG-NAP)     [Page 9]

RFC 1617      Naming and Structuring Guidelines for X.500       May 1994


      operations. In the last case, interfaces would have to "know" to
      follow the soft links indicated by the seeAlso attribute.

   Impact on naming

      In the single-entity model, all DNs within the organisation will
      be under one country. It could be argued that this will often
      result in rather "unnatural" naming. In the loose- confederation
      model, DNs are more natural, although the need to disambiguate
      between organisational units and localities on an international,
      rather than just a national, basis may have some impact on the
      choice of names. For example, it may be necessary to add in an
      extra level of organisational unit or locality information. In the
      loosely-linked model, there is no impact on naming at all.

   Views of the organisation

      The first method provides a unique view of the organisation.  The
      loose confederacy allows for a variety of views of the
      organisation. The view from the centre of the organisation may
      well be that all constituent organisations should be seen as part
      of the main organisation, whereas other parts of the organisation
      may only be interested in the organisation's centre and a few of
      its sibling organisations. The third model gives an equally
      flexible view of organisational structures.

   Lookup performance

      All methods should perform reasonably well, providing information
      is either held within a single DSA or it is replicated to the
      other DSAs.

3. Naming Style

   The first goal of naming is to provide unique identifiers for
   entries. Once this is achieved, the next major goal in naming entries
   should be to facilitate querying of the Directory. In particular,
   support for a naming structure which facilitates use of user friendly
   naming [5] is desirable. Other considerations, such as accurately
   reflecting the organisational structure of an organisation, should be
   disregarded if this has an adverse effect on normal querying. Early
   experience in the pilot has shown that a consistent approach to
   structure and naming is an aid to querying using a wide range of user
   interfaces, as interfaces are often optimised for DIT structures
   which appear prevalent. In addition, the X.501 standard notes that
   "RDNs are intended to be long-lived so that the users of the
   Directory can store the distinguished names of objects..." and "It is
   preferable that distinguished names of objects which humans have to



RARE Working Group on Network Applications Support (WG-NAP)    [Page 10]

RFC 1617      Naming and Structuring Guidelines for X.500       May 1994


   deal with be user-friendly." [2]

   Naming is dependent on a number of factors and these are now
   considered in turn.

3.1 Multi-Component Relative Distinguished Names

   According to the standard, relative distinguished names may have more
   than one component selected from the set of the attributes of the
   entry to be named. This is useful when there are, for example, two
   "John Smiths" in one department. The use of multi-component relative
   distinguished names allows one to avoid artificial naming values such
   as "John Smith 1" or "John Smith-2". Attributes which could be used
   as the additional naming attribute include: personalTitle,
   roomNumber, telephoneNumber, and userId.

3.2 National Guidelines for Naming

   Where naming is being done in a country which has established
   guidelines for naming, these guidelines should in general be
   followed. These guidelines might be based on an established
   registration authority, or may make use of an existing registration
   mechanism (e.g., company name registration).

   Where an organisation has a name which is nationally registered in an
   existing registry, this name is likely to be appropriate for use in
   the Directory, even in cases where there are no national guidelines.

3.3 Naming Organisation and Organisational Unit Names

   The naming of organisations in the Directory will ultimately come
   under the jurisdiction of official naming authorities. In the
   interim, it is recommended that pilots and organisations follow these
   guidelines. An organisation's RDN should usually be the full name of
   the organisation, rather than just a set of initials. This means that
   University College London should be preferred over UCL.  An example
   of the problems which a short name might cause is given by the
   proposed registration of AA for the Automobile Association.  This
   seems reasonable at first glance, as the Automobile Association is
   well known by this acronym. However, it seems less reasonable in a
   broader perspective when you consider that organisations such as
   Alcoholics Anonymous and American Airlines use the same acronym.

   Just as initials should usually be avoided for organisational RDNs,
   so should formal names which, for example, exist only on official
   charters and are not generally well known. There are two reasons for
   this approach:




RARE Working Group on Network Applications Support (WG-NAP)    [Page 11]

RFC 1617      Naming and Structuring Guidelines for X.500       May 1994


      1.   The names should be meaningful.

      2.   The names should uniquely identify the organisation, and be
           a name which is unlikely to be challenged in an open
           registration process. For example, UCL might well be
           challenged by United Carriers Ltd.

   The same arguments on naming style can be applied with even greater
   force to the choice of RDNs for organisational units. While
   abbreviated names will be in common parlance within an organisation,
   they will almost always be meaningless outside of that organisation.
   While many people in academic computing habitually refer to CS when
   thinking of Computer Science, CS may be given several different
   interpretations. It could equally be interpreted as Computing
   Services, Cognitive Science, Clinical Science or even Counselling
   Services.

   For both organisations and organisational units, extra naming
   information should be stored in the directory as alternative values
   of the naming attribute. Thus, for University College London, UCL
   should be stored as an alternative organizationName attribute value.
   Similarly CS could be stored as an alternative organizationalUnitName
   value for Computer Science and any of the other departments cited
   earlier. In general, entries will be located by searching, and so it
   is not essential to have RDNs which are either the most memorable or
   guessable, although names should be recognisable. The need for users
   not to type long names may be achieved by use of carefully selected
   alternative values.

3.4 Naming Human Users

   A reasonably consistent approach to naming people is particularly
   critical as a large percentage of directory usage will be looking up
   information about people. User interfaces will be better able to
   assist users if entries have names conforming to a common format, or
   small group of formats. It is suggested that the RDN should follow
   such a format. Alternative values of the common name attribute should
   be used to store extra naming information. It seems sensible to try
   to ensure that the RDN commonName value is genuinely the most common
   name for a person as it is likely that user interfaces may choose to
   place greater weight on matches on the RDN than on matches on one of
   the alternative names.

   The choice of RDN for humans will be influenced by cultural
   considerations. In many countries the best choice will be of the form
   familiar-first-name surname. Thus, Steve Kille is preferred as the
   RDN choice for one of this document's co-authors, while Stephen E.
   Kille is stored as an alternative commonName value. Pragmatic choices



RARE Working Group on Network Applications Support (WG-NAP)    [Page 12]

RFC 1617      Naming and Structuring Guidelines for X.500       May 1994


   will have to be made for other cultures. The common name attribute
   should not be used to hold other attribute information such as
   telephone numbers, room numbers, or local codes. Such information
   should be stored within the appropriate attributes as defined in the
   COSINE and Internet X.500 Schema. Section 3.1 on multi-component RDNs
   shows how clashing names can be made unique.

   The choice of a naming strategy should not be made on the basis of
   the possibilities of the currently available user interface
   implementations. For example, it is inappropriate to use common names
   of the form 'surname firstname' merely because a user interface
   presents results in a more satisfactory order by so doing. Use the
   best structure for human names, and fix the user interface!

   More details on the use of commonName in section 4.4.1.

3.5 Application Entities

   The guidelines of X.521 should be followed, in that the application
   entity should always be named relative to an Organisation or
   Organisational Unit. The application process will often correspond to
   a system or host. In this case, the application entities should be
   named by Common Names which identify the service (e.g., "FTAM
   Service"). In cases where there is no useful distinction between
   application process and application entity, the application process
   may be omitted (This is often done for DSAs in the current pilot).

4. Attribute Values

   In general the attribute values should be used as documented in the
   standards. Sometimes the standard is not very precise about which
   attribute to use and how to represent a value.

   The following sections give recommendations how to use them in X.500
   pilot projects.

4.1 Basic Attribute Syntaxes

   Every attribute type has a definition of the attribute syntaxes its
   values may be use. Most attribute types make use the basic attribute
   syntaxes only.










RARE Working Group on Network Applications Support (WG-NAP)    [Page 13]

RFC 1617      Naming and Structuring Guidelines for X.500       May 1994


4.1.1 Printable String

   This most simple syntax uses a subset of characters from ISO 646 IRV.

    A-Z   a-z   0-9   '     (     )     +

    ,     -     .     /     :     ?     space

    Tab 1: Characters in PrintableString

4.1.2 IA5 String - T.50

   The International Alphabet No. 5 (IA5) is known from the X.400
   message handling service. It covers a wider range of characters than
   the printable string. The international reference version of IA5
   offers the same set of characters as ISO 646 IRV.

4.1.3 Teletex String - T.61

   The Teletex character set is a very unusual one in the computing
   environment because it uses mixed one and two octet character codes
   which are more difficult to handle than single octet codes. Most of
   the characters can be mapped to the more often supported 8-bit
   character set standard ISO 8859-1 (ISO Latin-1).

4.1.4 Case Ignore String

   Many attributes use this case insensitive syntax. It allows attribute
   values to be represented using a mixture of upper and lower case
   letters, as appropriate. Matching of attribute values, however, is
   performed such that no significance is given to case.

4.1.5 Distinguished Name

   A Distinguished Name should currently never contain a value in T.61
   string syntax because most users would not be able to view or type it
   correctly by lack of appropriate hardware/software configuration.
   Therefore, only the characters defined in printable string syntax
   should be used as part of a RDN. The correct representation of the
   name should be added as additional attribute value to match for
   search operations.

4.2 Languages & Transliteration

   The standard as available has no support at all for the use of
   different languages in the Directory. It is e.g., not possible to add
   a language qualifier to a description attribute nor is it possible to
   use characters beyond the Teletex character set.



RARE Working Group on Network Applications Support (WG-NAP)    [Page 14]

RFC 1617      Naming and Structuring Guidelines for X.500       May 1994


4.2.1 Languages other than English

   Many countries have more than one national language and a world-wide
   Directory must be able to support non-English-speaking users.

   Until the standard provides a solution for this problem it is
   possible to make use of multi-valued attributes to specify a value
   not only in the local languages but also in English.

   In particular the friendlyCountryName, stateOrProvinceName and
   localityName attributes should use the most often used translations
   of its original value to increase the chance for successful searches
   also for users with a foreign language. Other attributes like
   description, organizationName and organizationalUnitName attributes
   should provide multi-lingual values where appropriate.

   The drawback of this solution is, that the user interfaces present
   much redundant information because they are not able to know the
   language of the values and make an automatic selection.

   Note:   The sequence of multi-valued attribute values in an entry
           cannot be defined. It is always up to the DSA to decide on
           which order to store them and return them as results, and
           to the DUA to decide on which order to display them.

4.2.2 Transliteration

   What measures can be taken to make sure all users are able to read an
   attribute, when a value uses one of the special characters from the
   T.61 character set? An interim solution is transliteration as used in
   earlier days with the typewriters, where e.g., the German 'a' with
   umlaut is written as 'ae'. Transliteration is not necessarily unique
   since it is dependent on the language, English speakers transliterate
   the 'a' with umlaut just to an 'a'. However, it is an improvement
   over just using the T.61 value since it may not be possible to
   display such a value at all. Whenever an attribute needs a character
   not in PrintableString and the attribute syntax allows the use of the
   T.61 character set, it is recommended that the attribute should be
   supplied as multi-valued attribute both in T.61 string and in a
   transliterated PrintableString notation.

4.3 Access control

   An entry's object class attribute, and any attribute(s) used for
   naming an entry are of special significance and may be considered to
   be "structural". Any inability to access these attributes will often
   militate against successful querying of the Directory. For example,
   user interfaces typically limit the scope of their searches by



RARE Working Group on Network Applications Support (WG-NAP)    [Page 15]

RFC 1617      Naming and Structuring Guidelines for X.500       May 1994


   searching for entries of a particular type, where the type of entry
   is indicated by its object class. Thus, unless the intention is to
   bar public access to an entry or set of entries, the object class and
   naming attributes should be publicly readable.

4.4 Selected Attributes

   The section lists attributes together with a short description what
   they should be used for and some examples. [6] The source of the
   attributes is given in brackets.

   Note that due to national legal restrictions on privacy issues it
   might be forbidden to use certain attributes or that the search on
   them is restricted. [7]

4.4.1 Personal Attributes

   commonName [X.520]

      It is proposed that pilots should ignore the standard's
      recommendations on storing personal titles, and letters indicating
      academic and professional qualifications within the commonName
      attribute, as this overloads the commonName attribute. A
      personalTitle attribute has already been specified in the COSINE
      and Internet Schema, and another attribute could be specified for
      information about qualifications.

      The choice of a name depends on the culture as discussed in
      section 3.4. When a commonName is selected as (part of) a RDN the
      most often used form of the name should be selected. A firstname
      should never be supplied only as an initial (unless, of course,
      the source data does not include forenames). It is very important
      to have its full value in order to be able to distinguish between
      two similar entries. Sets of initials should not be concatenated
      into a single "word", but be separated by spaces and/or "."
      characters.


         Format:    Firstname [Initials] Lastname

         Example:   Steve Kille

                    Stephen E. Kille

                    S.E. Kille






RARE Working Group on Network Applications Support (WG-NAP)    [Page 16]

RFC 1617      Naming and Structuring Guidelines for X.500       May 1994


      The use of 'Lastname Firstname' is deprecated as explained in
      section 3.4.

   favouriteDrink [RFC 1274]

      The intention of this attribute is that it provides at least one
      benign attribute which any user can create or modify, given a
      suitable user interface, without having the unfortunate impact on
      the directory service that follows from modifying an attribute
      such as an e-mail address or telephone number.

      Example: Pure Crystal Water

   organizationalStatus [RFC 1274]

      The Organisational Status attribute type specifies a category by
      which a person is often referred to in an organisation. Examples
      of usage in academia might include undergraduate student,
      researcher, lecturer, etc.

      A Directory administrator should consider carefully the
      distinctions between this and the title and description
      attributes.

      Example: undergraduate student

   personalTitle [RFC 1274]

      The usually used titles, especially academic ones. Excessive use
      should be avoided.

      Example: Prof. Dr.

   roomNumber [RFC 1274]

      The room where the person works, it will mostly be locally defined
      how to write the room number, e.g., Building Floor Room.

      Example: HLW B12

   secretary [RFC 1274]

      The secretary of the person. This is the Distinguished Name (DN)
      of the secretary.

      Example: CN=Beverly Pyke, O=ISODE Consortium, C=GB





RARE Working Group on Network Applications Support (WG-NAP)    [Page 17]

RFC 1617      Naming and Structuring Guidelines for X.500       May 1994


   surname [X.520]

      Like with commonName it is a matter of culture what to use for
      surname in case of a noble name, e.g., de Stefani, von Gunten.

      Example: Kille

   title [X.520]

      Title describing the position, job title or function of an
      organisational person.

      Example: Manager - International Sales

   userId [RFC 1274]

      When an organisation has centrally managed user ids, it might make
      sense to include it into the entry. It might also be used to form
      a unique RDN for the person.

      Example: skille

   userPassword [X.520]

      The password of the entry which allows the modification of the
      entry, provided that the access control permits it. The password
      should not be the same as any system password, unless it is sure
      that nobody can read it. With the current implementations this is
      mostly not guaranteed.

      Example: 8kiu8z7e

4.4.2 Organisational Attributes

   associatedDomain [RFC 1274]

      The Internet domain name for an organisation or one of its units.

      Example: isode.com

   businessCategory [X.520]

      Type of business an organisation, an organisational unit or
      organisational person is involved in. The values could be chosen
      from a thesaurus.

      Example: Software Development




RARE Working Group on Network Applications Support (WG-NAP)    [Page 18]

RFC 1617      Naming and Structuring Guidelines for X.500       May 1994


   organizationName [X.520]

      The name of the organisation. The value for the RDN should be
      chosen according to section 3.3. Additional names like
      abbreviations should be used for better search results.

      Example:    Uni Lausanne
                  Universite de Lausanne
                  Universit\c2e Lausanne (with a T.61 encoded umlaut)
                  University of Lausanne
                 unil

   organizationalUnitName [X.520]

      The name of a part of the organisation. The value for the RDN
      should be chosen according to section 3.3. Additional names like
      abbreviations should be provided for better search results.

      Example:    Institut fuer Angewandte Mathematik
                  Mathematik
                  iam

   roleOccupant [X.520]

      The person(s) in that role. This is the Distinguished Name of the
      entry of the person(s).

      Example: CN=Beverly Pyke, O=ISODE Consortium, C=GB

   searchGuide [X.520]

      The currently available DUAs make no use this attribute. It seems
      that it is not powerful enough for real usage. Experience is
      needed before being able to give recommendations on how to
      configure it.

4.4.3 Local Attributes

   localityName [X.520]

      Name of the place, village or town with values in local and other
      languages as useful.

      Example:    Bale
                  B\c3ale (with a T.61 encoded accented character) Basel
                  Basilea
                  Basle




RARE Working Group on Network Applications Support (WG-NAP)    [Page 19]

RFC 1617      Naming and Structuring Guidelines for X.500       May 1994


   stateOrProvinceName [X.520]

      Name of the canton, county, department, province or state with
      values in local and other languages as useful. If official and
      commonly used abbreviations exist for the states, they should be
      supplied as additional values

      Example:    Ticino
                  Tessin
                  TI

4.4.4 Miscellaneous Attributes

   audio [RFC 1274]

      The audio attribute uses a u-law encoded sound file as used by the
      "play" utility on a Sun 4. According to RFC 1274 it is an interim
      format. It may be useful to listen to the pronunciation of a name
      which is otherwise unknown.

   description [X.520]

      A short informal explanation of special interests of a person or
      organisation. Overlap with businessCategory, organizationalStatus
      and title should be avoided.

      Example: Networking, distributed systems, OSI, implementation.

   friendlyCountryName [RFC 1274]

      The friendlyCountryName attribute type specifies names of
      countries in human readable format. Especially the country name as
      used in the major languages should be included as additional
      values to help foreign users.

   jpegPhoto [RFC 1488] [8]

      A colour or grayscale picture encoded according to JPEG File
      Interchange Format (JFIF). Thanks to compression the size of the
      pictures is moderate. For persons it may show a portrait, for
      organisations the company logo or a map on how to get there.

   photo [RFC 1274]

      The photo attribute is a b/w G3 fax encoded picture of an object.
      The size of the photo should be in a sensible relation to the
      informational value of it. This attribute will be replaced by
      jpegPhoto.



RARE Working Group on Network Applications Support (WG-NAP)    [Page 20]

RFC 1617      Naming and Structuring Guidelines for X.500       May 1994


   seeAlso [X.520]

      Reference to another closely related entry in the DIT, e.g., from
      a room to the person using that room. It is the Distinguished Name
      of the entry.

      Example: CN=Beverly Pyke, O=ISODE Consortium, C=GB

4.4.5 MHS Attributes

   mhsORAddresses [X.411]

      The attribute uses internally an ASN.1 structure. The string
      notation used for display purposes is implementation dependent.
      This attribute is especially useful for an integrated X.400 user
      agent since it gets the address in a directly usable format.

   rfc822mailbox [RFC 1274]

      E-Mail address in RFC 822 notation

      Example: s.kille@isode.com

   textEncodedORAddress [RFC 1274]

      X.400 e-mail address in string notation. The F.401 notation should
      be used. This attribute shall disappear once the majority of the
      DUAs support the mhsORAddresses attribute. The advantage of the
      latter attribute is, that a configurable DUA could adjust the
      syntax to the one needed by the local mailer, where
      textencodedORAddress is just a string which will mostly have a
      different syntax than the mailer expects.

      Example:    G=thomas; S=lenggenhager; OU1=gate; O=switch; \
                  P=switch; A=arcom; C=ch;

4.4.6 Postal Attributes

   postalAddress [X.520]

      The full postal address (but not including the name) in
      international notation, with up to 6 lines with 30 characters
      each.

      Example:    SWITCH
                  Limmatquai 13
                  CH-8001 Zurich




RARE Working Group on Network Applications Support (WG-NAP)    [Page 21]

RFC 1617      Naming and Structuring Guidelines for X.500       May 1994


   postalCode [X.520]

      The postalCode will be the same as used in the postalAddress (in
      international notation).

      Example: CH-8001

   streetAddress [X.520]

      It shall be the street where the person has its office. Mostly, it
      will be the street part of the postalAddress.

      Example: Limmatquai 138

4.4.7 Telecom Attributes

   telephoneNumber, facsimileTelephoneNumber & iSDNAddress [X.520]

      The phone number in the international notation according to CCITT
      E.123. The separator '-' instead of space may be used according to
      the local habit, it should be used consistently within a country.

      Format: "+" <country code> <national number> ["x" <extension>]
      Example: +41 1 268 1540

   telexNumber [X.520]

      The telex number in the international notation

      Example: 817379, ch, ehhg

5. Miscellany

   This section draws attention to two areas which frequently provoke
   questions, and where it is felt that a consistent approach will be
   useful.

5.1 Schema consistency of aliases

   According to the letter of the standard, an alias may point at any
   entry. It is beneficial for aliases to be 'schema consistent'.

   The following two checks should be made:

      1.   The Relative Distinguished Name of the alias should use an
           attribute type normally used for naming entries of the
           object class of the main entry.




RARE Working Group on Network Applications Support (WG-NAP)    [Page 22]

RFC 1617      Naming and Structuring Guidelines for X.500       May 1994


      2.   If the entry (aliased object) were placed where the alias
           is, there should be no schema violation.

5.2 Organisational Units

   There is a problem that many organisations can be either
   organisations or organisational units, dependent on the location in
   the DIT (with aliases giving the alternate names). For example, an
   organisation may be an independent national organisation and also an
   organisational unit of a parent organisation. To achieve this, it is
   important to allow an entry to be of both object class organisation
   and of object class organisational unit.

6. References

   [1] Barker, P., and S. Hardcastle-Kille, "The COSINE and Internet
       X.500 schema", RFC 1274, Department of Computer Science,
       University College London, November 1991.

   [2] "The Directory --- Overview of concepts, models and services",
       CCITT X.500 Series Recommendations, December 1988.

   [3] The North American Directory Forum. "A Naming Scheme for C=US",
       RFC 1255, NADF-175, NADF, September 1991.

   [4] Michaelson, G., and M. Prior, "Naming Guidelines for the AARNet
       X.500 Directory Service", RFC 1562, AEN-001, The University of
       Queensland, The University of Adelaide, December 1993.

   [5] Hardcastle-Kille, S., "Using the OSI Directory to achieve user
       friendly naming", RFC 1484, Department of Computer Science,
       University College London, July 1993.

   [6] Barker, P., "Preparing data for inclusion in an X.500 Directory",
       Research Note RN/92/41, Department of Computer Science,
       University College London, May 1992.

   [7] Jeunink, E., and E. Huizer, "Directory Services and Privacy
       Issues", RARE WG-DATMAN, TF-LEGAL, Work in Progress, May 1993.

   [8] Howes, T., Kille, S., Yeong, W., and C. Robbins, "The X.500
       String Representation of Standard Attribute Syntaxes", RFC 1488,
       University of Michigan, ISODE Consortium, Performance Systems
       International, NeXor Ltd., July 1993.

7. Security Considerations

   Security issues are not substantially discussed in this memo.



RARE Working Group on Network Applications Support (WG-NAP)    [Page 23]

RFC 1617      Naming and Structuring Guidelines for X.500       May 1994


8. Authors' Addresses

   Paul Barker
   Department of Computer Science
   University College London
   Gower Street
   London WC1E 6BT
   England

   Phone: +44 71 380 7366
   EMail: p.barker@cs.ucl.ac.uk

   DN:  CN=Paul Barker, OU=Computer Science, O=University College
        London, C=GB

   UFN: Paul Barker, Computer Science, UCL, GB


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

   Phone: +44 81 332 9091
   EMail: s.kille@isode.com

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

   UFN: S. Kille, ISODE   Consortium, GB


   Thomas Lenggenhager
   SWITCH
   Limmatquai 138
   CH-8001 Zurich
   Switzerland

   Phone: +41 1 268 1540
   EMail: lenggenhager@switch.ch

   DN:  CN=Thomas Lenggenhager, O=SWITCH, C=CH

   UFN: Thomas Lenggenhager, SWITCH, CH






RARE Working Group on Network Applications Support (WG-NAP)    [Page 24]

RFC 1617      Naming and Structuring Guidelines for X.500       May 1994


9. Appendix - Example Entries

9.1 Country

    DN: C=CH

    objectClass=top & country & domainRelatedObject & friendlyCountry
    country=CH
    associatedDomain=ch
    friendlyCountryName=CH
    friendlyCountryName=Confoederatio Helvetica
    friendlyCountryName=Schweiz
    friendlyCountryName=Suisse
    friendlyCountryName=Svizzera
    friendlyCountryName=Switzerland

9.2 Organisation

    DN: O=SWITCH, C=CH

    objectClass=top & organization & mhsUser & domainRelatedObject
    description=Swiss Academic and Research Network
    organizationName=SWIss TeleCommunication system for Higher
    education\and research
    organizationName=Swiss Academic and Research Network
    organizationName=SWITCH
    localityName=Zuerich
    localityName=Zurich
    localityName={T.61}Z\c8urich
    stateOrProvinceName=ZH
    stateOrProvinceName=Zuerich
    stateOrProvinceName=Zurich
    stateOrProvinceName={T.61}Z\c8urich
    postalAddress=SWITCH
                  Limmatquai 138
                  CH-8001 Zurich
    postalCode=CH-8001
    streetAddress=Limmatquai 138
    telephoneNumber=+41 1 268 1515
    facsimileTelephoneNumber=+41 1 268 1568
    seeAlso=CN=Postmaster, O=SWITCH, C=CH
    mhsORAddresses=S=postmaster, O=switch; P=switch; A=arcom; C=ch;
    associatedDomain=switch.ch








RARE Working Group on Network Applications Support (WG-NAP)    [Page 25]

RFC 1617      Naming and Structuring Guidelines for X.500       May 1994


9.3 Organisation Unit

    DN: OU=SWITCHdirectory, O=SWITCH, C=CH

    objectClass=top & organizationalUnit
    description=The SWITCH X.500 pilot project
    organizationalUnitName=SWITCHdirectory
    localityName=Zurich
    localityName=Zuerich
    localityName={T.61}Z\c8urich
    stateOrProvinceName=Zurich
    stateOrProvinceName=Zuerich
    stateOrProvinceName=ZH
    stateOrProvinceName={T.61}Z\c8urich
    postalAddress=SWITCHdirectory
                  SWITCH
                  Limmatquai 138
                  CH-8001 Zurich
    postalCode=CH-8001
    streetAddress=Limmatquai 138
    telephoneNumber=+41 1 268 1540
    facsimileTelephoneNumber=+41 1 268 1568

9.4 Organizational Role

    DN: CN=Directory Manager, O=SWITCH, C=CH

    objectClass=top & organizationalRole & mhsUser
    commonName=Directory Manager
    description=SWITCH Directory Managers
    roleOccupant=CN=Martin Berli, O=SWITCH, C=CH
    roleOccupant=CN=Thomas Lenggenhager, O=SWITCH, C=CH
    localityName=Zuerich
    localityName=Zurich
    localityName={T.61}Z\c8urich
    stateOrProvinceName=Zurich
    stateOrProvinceName=Zuerich
    stateOrProvinceName=ZH
    stateOrProvinceName={T.61}Z\c8urich
    postalAddress=SWITCHdirectory
                  SWITCH
                  Limmatquai 138
                  CH-8001 Zurich
    postalCode=CH-8001
    streetAddress=Limmatquai 138
    telephoneNumber=+41 1 268 1540
    facsimileTelephoneNumber=+41 1 268 1568
    mhsORAddresses=S=switchinfo; O=switch; P=switch; A=arcom; C=ch;



RARE Working Group on Network Applications Support (WG-NAP)    [Page 26]

RFC 1617      Naming and Structuring Guidelines for X.500       May 1994


    DN: CN=Postmaster, O=SWITCH, C=CH

    objectClass=top & organizationalRole & mhsUser
    commonName=Postmaster
    commonName=Helpdesk
    roleOccupant=CN=Christoph Graf, O=SWITCH, C=CH
    roleOccupant=CN=Felix Kugler, O=SWITCH, C=CH
    roleOccupant=CN=Marcel Parodi, O=SWITCH, C=CH
    roleOccupant=CN=Marcel Schneider, O=SWITCH, C=CH
    telephoneNumber=+41 1 268 1520
    facsimileTelephoneNumber=+41 1 268 1568
    mhsORAddresses=S=postmaster; O=switch; P=switch; A=arcom; C=ch;

    DN: CN=Secretary, O=SWITCH, C=CH

    objectClass=top & organizationalRole & quipuObject
    commonName=Secretary
    roleOccupant=CN=Franziska Remund, O=SWITCH, C=CH

































RARE Working Group on Network Applications Support (WG-NAP)    [Page 27]

RFC 1617      Naming and Structuring Guidelines for X.500       May 1994


9.5 Person

    DN: CN=Thomas Lenggenhager, O=SWITCH, C=CH

    objectClass=top & person & organizationalPerson & mhsUser &
    pilotObject & newPilotPerson
    commonName=Thomas Lenggenhager
    commonName=T. Lenggenhager
    surname=Lenggenhager
    description=SWITCHinfo, Project Leader
    localityName=Zuerich
    localityName=Zurich
    localityName={T.61}Z\c8urich
    stateOrProvinceName=ZH
    stateOrProvinceName=Zuerich
    stateOrProvinceName=Zurich
    stateOrProvinceName={T.61}Z\c8urich
    postalAddress=SWITCH
                  Limmatquai 138
                  CH-8001 Zurich
    postalCode=CH-8001
    streetAddress=Limmatquai 138
    telephoneNumber=+41 1 268 1540
    facsimileTelephoneNumber=+41 1 268 1568
    mhsORAddresses=S=lenggenhager; O=switch; P=switch; A=arcom; C=ch;
    userPassword=secret
    textEncodedORaddress={T.61}S=lenggenhager; O=switch; P=switch; \
                                  A=arcom; C=ch;
    rfc822mailbox=lenggenhager@switch.ch
    secretary=CN=Franziska Remund, O=SWITCH, C=CH





















RARE Working Group on Network Applications Support (WG-NAP)    [Page 28]