File: rfc1218.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 (1291 lines) | stat: -rw-r--r-- 41,408 bytes parent folder | download | duplicates (5)
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






Network Working Group                 The North American Directory Forum
Request for Comments: 1218                                    April 1991


                        A Naming Scheme for c=US

Status of this Memo

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

Summary

   This RFC is a near-verbatim copy of a document, known as NADF-123,
   which has been produced by the North American Directory Forum (NADF).
   The NADF is a collection of organizations which offer, or plan to
   offer, public Directory services in North America, based on the CCITT
   X.500 Recommendations.  As a part of its charter, the NADF must reach
   agreement as to how entries are named in the public portions of the
   North American Directory.  NADF-123 is a scheme proposed for this
   purpose.  The NADF is circulating NADF-123 widely, expressly for the
   purpose of gathering comments.  The next meeting of the NADF is in
   mid-July, and it is important for comments to be received prior to
   the meeting, so that the scheme may receive adequate review.


                         A Naming Scheme for c=US
                    The North American Directory Forum
                                 NADF-123
                       Supercedes: NADF-103, NADF-71
                              March 21, 1991

ABSTRACT

   This is one of a series of documents produced for discussion within
   the North American Directory Forum.  Distribution, with attribution,
   is unlimited.  This document is being circulated for comment.  The
   deadline for comments is July 1, 1991.  Comments should be directed
   to the contact given on page 16.

1.  Introduction

   Computer networks form the infrastructure between the users they
   interconnect.  For example, the electronic mail service offered by
   computer networks provides a means for users to collaborate towards
   some common goal.  In the simplest cases, this collaboration may be
   solely for the dissemination of information.  In other cases, two



NADF                                                            [Page 1]

RFC 1218                A Naming Scheme for c=US              April 1991


   users may work on a joint research project, using electronic mail as
   their primary means of communication.

   However, networks themselves are built on an underlying naming and
   numbering infrastructure, usually in the form of names and addresses.
   For example, some authority must exist to assign network addresses to
   ensure that numbering collisions do not occur.  This is of paramount
   importance for an environment which consists of multiple service
   providers.

2.  Approach

   It should be observed that there are several different naming
   universes that can be realized in the Directory Information Tree
   (DIT).  For example, geographical naming, community naming, political
   naming, organizational naming, and so on.  The choice of naming
   universe largely determines the difficulty in mapping a user's query
   into a series of Directory operations.  Although it is possible to
   simultaneously support multiple naming universes with the DIT, this
   is likely to be unnatural.  As such, this proposal focuses on a
   single naming universe.

   The naming universe in this proposal is based on civil authority.
   That is, it uses the existing civil naming infrastructure and
   suggests a (nearly) straight-forward mapping on the DIT.  There are
   four components to the naming architecture:

   (1)  civil naming and optimized civil naming, which reflects
        names assigned by civil authority;

   (2)  organizational naming, which reflects names assigned
        within organizations;

   (3)  ADDMD naming, which reflects names assigned to public
        providers within the Directory service; and,

   (4)  application naming, which reflects names assigned to OSI
        entities.

   An important characteristic is that entries should be listed wherever
   searches for them are likely to occur.  This implies that a single
   object may be listed under several entries.

2.1.  Names and User-Friendliness

   It must be emphasized that there are three distinct concepts which
   are often confused when discussing a naming scheme:




NADF                                                            [Page 2]

RFC 1218                A Naming Scheme for c=US              April 1991


   (1)  user-friendly naming: a property of a Directory which
        allows users to easily identity objects;

   (2)  user-friendly name: a technique for naming an object
        which exhibits "friendliness" according to an arbitrary
        set of user-criteria; and,

   (3)  Distinguished Name: the administratively assigned name
        for an entry in the OSI Directory.

   It must be emphasized that Distinguished Names are not necessarily
   user-friendly names, and further, that user-friendly naming in the
   Directory is a property of the Directory Service, not of
   Distinguished Names.

2.2.  Choice of RDN Names

   The key aspect to appreciate for choice of RDNs is that they should
   provide a large name space to avoid collisions: the naming strategy
   must provide enough "real estate" to accommodate a large demand for
   entries.  This is the primary requirement for RDNs.  A secondary
   requirement is that RDNs should be meaningful (friendly to people)
   and should not impede searching.

   However, it is important to understand that this second requirement
   can be achieved by using additional (non-distinguished) attribute
   values.  For example, if the RDN of an entry is

                organizationName is Performance Systems International

   then it is perfectly acceptable (and indeed desirable) to have other
   values for the organizationName attribute, e.g.,

                organizationName is PSI

   The use of these abbreviated names greatly aids searching whilst
   avoiding unnecessary Distinguished Name conflicts.

   In order to appreciate the naming scheme which follows, it is
   important to understand that it leverages, wherever possible,
   existing naming infrastructure.  That is, it relies heavily on non-
   OSI naming authorities which already exist.  Note that inasmuch as it
   relies on existing naming authorities, there is little chance that
   any "final" national decision could obsolete it.  [Footnote: Any
   naming scheme may be subject to the jurisdiction of certain national
   agencies.  For example, the US State Department is concerned with any
   impact on US telecommunications treaty obligations.] (To do so would
   require a national decision that disregards existing national and



NADF                                                            [Page 3]

RFC 1218                A Naming Scheme for c=US              April 1991


   regional infrastructure, and establishes some entirely new and
   different national naming infrastructure.)

3.  Civil Naming

   Civil naming occurs at three levels:

   (1)  the national level, which contains objects that are
        recognized throughout a country;

   (2)  the regional level, which contains objects that are
        recognized throughout a state or state-equivalent; and,

   (3)  the local level, which contains objects that are
        recognized within a populated place.

3.1.  Naming at the National Level

   At the national-level (at least) three kinds of names may be listed:

   (1)  The States and State-Equivalents

   (2)  Organizations with National Standing

   (3)  ADDMD Operators

3.1.1.  The States and State-Equivalents

   For each state or state-equivalent (the District of Columbia and the
   eight outlying areas [Footnote: i.e., American Samoa, Federated
   States of Micronesia, Guam, Marshall Islands, Northern Mariana
   Islands, Palau, Puerto Rico, and Virgin Islands of the US.]), an
   instance of an

               usStateOrEquivalent

          object is used.  The RDN is formed as

               localityName is <FIPS 5 name>

          e.g.,

               localityName is California

   provides the RDN for the State of California.  In addition, this
   entry would contain attributes identifying both the FIPS 5 alpha and
   numeric code for the State, e.g.,




NADF                                                            [Page 4]

RFC 1218                A Naming Scheme for c=US              April 1991


                fipsStateNumericCode is 06
                fipsStateAlphaCode is CA

   Of course, this entry could contain many other attributes such as

                stateOrProvinceName is State of California

3.1.2.  Organizations with National Standing

   There is no authority in the United States which unambiguously
   registers the alphanumeric names of organizations with national
   standing.  It is proposed that ANSI provide this registry and that
   the ANSI alphanumeric name form be used as the basis for RDNs.

   For each organization with national standing, an instance of an

               usOrganization

          object is used.  The RDN is formed as

               organizationName is <ANSI alphanumeric name form>

          e.g.,

               organizationName is Performance Systems International

   In addition, this entry would contain attributes identifying the ANSI
   Alphanumeric name form, e.g.,

                ansiOrgNumericCode is 177777

   Of course, this entry would contain many other attributes such as

                organizationName is PSI

   For the National Government, an instance of an

                organization

   object is also used, and the RDN is taken from the ANSI alphanumeric
   name form registry.

3.1.3.  ADDMD Operators

   There is no authority in the United States which unambiguously
   registers the names of ADDMD operators.  It is expected that the
   North American Directory Forum will coordinate with the US CCITT
   National Committee Study Group D to provide this registry.  (At



NADF                                                            [Page 5]

RFC 1218                A Naming Scheme for c=US              April 1991


   worst, the ADDMDs can use ANSI alphanumeric name forms for their RDN
   attribute values.)

          For each ADDMD operator, an instance of a

               nadfADDMD

          object is used.  The RDN is formed as

               addmdName is <NADF registered name>

          e.g.,

               addmdName is PSINet

3.2.  Naming within a State or State-Equivalent

   At the regional level (at least) two kinds of names may be listed:

   (1)  Populated Places

   (2)  Organizations with Regional Standing

3.2.1.  Populated Places

   For each populated place within a state or state-equivalent,
   an instance of an

               usPlace

          object is used.  The RDN is formed as

               localityName is <FIPS 55 name>

          e.g.,

               localityName is Hartford

   provides the RDN for the Hartford entry immediately subordinate to
   the usStateOrEquivalent entry for the State of Connecticut.  In
   addition, this entry would contain attributes identifying the FIPS 55
   place code, e.g.,

                usPlaceCode is 37000







NADF                                                            [Page 6]

RFC 1218                A Naming Scheme for c=US              April 1991


3.2.2.  Organizations with Regional Standing

   An organization is said to have regional standing if it is registered
   with the "Secretary of State" or similar entity within that region,
   as an entity doing business in the region.

   For each organization with regional standing, an instance of an

               organization

          object is used.  The RDN is formed as

               organizationName is <registered name of organization>

          e.g.,

               organizationName is Network Management Associates

   might provide the RDN for a business entity registered with the State
   of California.  In this case, the entry thus named would be
   immediately subordinate to the usStateOrEquivalent entry for the
   State of California.

   Note that other non-distinguished attributes, such as an ANSI numeric
   name form value, may be included in such an entry --- the
   organization object might actually be a usOrganization object.

   For the Regional Government, an instance of an

               organization

          object is also used.  The RDN is formed as:

               organizationName is Government

3.3.  Naming within a Populated Place

   At the local level (at least) three kinds of names may be listed:

   (1)  Persons

   (2)  Organizations with Local Standing

   (3)  MHS Distribution Lists







NADF                                                            [Page 7]

RFC 1218                A Naming Scheme for c=US              April 1991


3.3.1.  Naming of Persons

   Within a populated place, there is no centralized naming entity which
   registers residential persons.  It is proposed that entries for
   persons be immediately subordinate to the usPlace object which most
   accurately reflects their place of residence.

   For each person (wishing to have an entry in the Directory), an
   instance of a residentialperson

               residentialPerson

          object is used.  The RDN is usually multi-valued, formed with

               commonName is <person's full name>

   and some other attribute, such as postalCode, streetAddress, etc.
   However, because streetAddress is often considered private
   information, based on agreement with the entity managing the DMD and
   the listed person, some other, distinguishing attribute may be used,
   including a "serial number" (having no other purpose).  It should be
   noted however that this is non-helpful in regards to searching,
   unless other attribute values containing meaningful information are
   added to the entry and made available for public access.

3.3.2.  Organizations with Local Standing

   An organization is said to have local standing if it is registered
   with the County or City Clerk or similar entity within that locality
   as an entity "doing business" in that place.

   For each organization with local standing, an instance of an

               organization

          object is used.  The RDN is formed as

               organizationName is <registered name of organization>

          e.g.,

               organizationName is The Tied House

   might provide the RDN for a business entity registered with the City
   of Mountain View.  In this case, the entry thus named would be
   immediately subordinate to the usPlace entry for the City of Mountain
   View.




NADF                                                            [Page 8]

RFC 1218                A Naming Scheme for c=US              April 1991


   Note that other non-distinguished attributes, such as an ANSI numeric
   name form value, may be included in an entry.  (That is, the
   organization object might actually be a usOrganization object.)

          For the Local Government, if any, an instance of an

               organization

          object is also used.  The RDN is formed as:

               organizationName is Government

3.4.  Naming of MHS Distribution Lists

   Naming of MHS distribution lists remains with the scoping DMD.

4.  Optimized Civil Naming

   The structure of the civil component of the architecture can be
   concisely described as:

----------------------------------------------------------------------
Level   Element   objectClass             Superior    RDN
----------------------------------------------------------------------
root    0
----------------------------------------------------------------------
intl.   1         country                 0           countryName
----------------------------------------------------------------------
natl.   2         usStateOrEquivalent     1           localityName
        3         usOganization           1           organizationName
        4         nadfADDMD               1           addmdName
----------------------------------------------------------------------
reg.    5         usPlace                 2           localityName
        6         organization            2           organizationName
----------------------------------------------------------------------
local   7         residentialPerson       5           commonName,
                                                      other
        8         organization            5           organizationName
        9         mhsDistributionList     5           commonName
----------------------------------------------------------------------

   Consider how an interrogation algorithm might locate a residential
   person, given:

   (1)  a string denoting the person's real-world name;

   (2)  a string denoting the real-world name of the populated
        place in which the person lives; and,



NADF                                                            [Page 9]

RFC 1218                A Naming Scheme for c=US              April 1991


   (3)  the Distinguished Name of the state or state-equivalent.

   A straight-forward approach is to initiate a single-level search to
   locate the desired populated place.  The search results in zero or
   more Distinguished Names being returned which correspond to the
   string provided by the user.  Then, for each populated place, a
   subtree search might be initiated to locate the desired residential
   person.  If the number of populated places returned by the first
   search is large, then this strategy is inefficient.

   A better approach would be to initiate a single search, with a filter
   combining the strings for both the person's real-world name and the
   place's real-world name.  Unfortunately, such a search would have to
   involve the whole-subtree anchored at the Distinguished Name for the
   state or state-equivalent, which would be inefficient.

   As such, it may be desirable to optimize the civil naming component
   by listing some entries at a higher level.  This is accomplished by
   using a multi-valued RDN formed by combining the RDNs of the entry
   and its superior.

   There are three cases in civil naming:

   (1)  listing an organization with regional standing at the
        national level;

   (2)  listing an organization with local standing at the
        regional level; and,

   (3)  listing a person with local standing at the regional
        level.

   Hence, under the optimized civil naming component, a single-level
   search, anchored at the Distinguished Name for the state or state-
   equivalent, could be used.  Further, the implementation of a DSA
   supporting this optimization would highly-index the attributes used
   for searching, in order to achieve high-performance.

   In order to clearly indicate that optimized civil naming is in
   effect, a new attribute type, nadfSearchGuide, is introduced.  An
   attribute value of this type is placed in an entry to indicate which
   optimizations are in effect.  Using the residential example above,
   the entry for the state or state-equivalent would contain an
   nadfSearchGuide value indicating that when searching for entries of
   type residentialPerson, a single-level search should be performed
   with a filter containing the logical-and of two terms, one involving
   the commonName attribute, and the other involving the localityName
   attribute.  The nadfSearchGuide is a refinement of the X.500



NADF                                                           [Page 10]

RFC 1218                A Naming Scheme for c=US              April 1991


   searchGuide in that it indicates the depth of the search which should
   be performed, and always contains an indication of the object class
   for which the optimization exists.

   Finally, note that for naming within organizations, this technique
   might also be used.

4.1.  Naming at the National Level

4.1.1.  Organizations with Regional Standing

   An organization with standing within a state or state-equivalent may
   be listed directly under c=US.

   For an organization with regional standing, an instance of an

               organization

          object is used.  The RDN is multi-valued, formed as

               organizationName is <registered name of organization>
               localityName is <FIPS 5 name>

          e.g.,

               organizationName is Network Management Associates
               localityName is California

   It must be emphasized that uniqueness within the RDN comes from using
   the a regional localityName (state or state-Equivalent) in
   association with the correspondent organizationName in that region.

4.2.  Naming within a State or State-Equivalent

4.2.1.  Organizations with Local Standing

   An organization with standing within a populated place may be listed
   directly under its state or state-equivalent.

   For an organization with local standing, an instance of an

               organization

          object is used.  The RDN is multi-valued, formed as

               organizationName is <registered name of organization>
               localityName is <FIPS 55 name>




NADF                                                           [Page 11]

RFC 1218                A Naming Scheme for c=US              April 1991


          e.g.,

               organizationName is The Tied House
               localityName is City of Mountain View

   It must be emphasized that uniqueness within the RDN comes from using
   the a local localityName (populated place) in association with the
   correspondent organizationName in that place.

4.2.2.  Persons

   An person may be listed directly under its state or state-equivalent.

   For such a person, an instance of a

                residentialPerson

   object is used.  The RDN is multi-valued, formed by taking the RDN of
   the person and adding the RDN of the populated place containing the
   person.

                commonName is the Marshall T. Rose
                postalCode is 94043-2112
                localityName is City of Mountain View

   Note that for optimization to occur, the RDN of the person must not
   contain a localityName attribute value.

5.  Organizational Naming

   The internal structure of each usOrganization or organization object
   is a matter for that organization to establish.

   It is strongly recommended that organizationalUnit objects be used
   for structuring.  (If an organization uses a locality-based
   organizational hierarchy, this information can still be represented
   using the

               organizationalUnit

          object.)

6.  ADDMD Naming

   The internal structure of each nadfADDMD object is a matter for that
   service-provider to establish.





NADF                                                           [Page 12]

RFC 1218                A Naming Scheme for c=US              April 1991


7.  Application Naming

   There are (at least) four kinds of OSI entities which may be listed:

   (1)  Application Processes and Entities

   (2)  MHS Distribution Lists

   (3)  EDI Users

   (4)  Devices

7.1.  Naming of Application Processes and Entities

   Naming of OSI application processes and entities remains with the
   scoping DMD.  However, in order to foster interoperability, two
   requirements are made: first, application entity objects must be
   immediately subordinate to application process objects; and, second,
   application entities are represented by the nadfApplicationEntity
   object, which is identical to the applicationEntity object except
   that the presence of an attribute value of
   supportedApplicationContext is mandatory.

7.2.  Naming of MHS Distribution Lists

   Naming of MHS distribution lists remains with the scoping DMD.

7.3.  Naming of EDI Users

   Naming of EDI users remains with the scoping DMD.

7.4.  Naming of Devices

   Naming of OSI devices remains with the scoping DMD.

8.  Usage Examples

   Consider the following examples, expressed in a concise format (read
   left-to-right):

          Federal Government:

               { c=US, o=Government }


          The State of California:

               { c=US, l=California }



NADF                                                           [Page 13]

RFC 1218                A Naming Scheme for c=US              April 1991


          The District of Columbia:

               { c=US, l=District of Columbia }


          An organization with national standing:

               { c=US, o=Performance Systems International }


          An ADDMD:

               { c=US, addmdName=PSINet }


          The Government of the State of California:

               { c=US, l=California, o=Government }


          The Government of the District of Columbia:

               { c=US, l=District of Columbia, o=Government }


          A city within the State of California:

               { c=US, l=California, l=City of Mountain View }


          An organization licensed to operate within the State of
          California:

               { c=US,
                 l=California,
                 o=Network Management Associates, Inc. }


          An optimized listing for a organization with regional
          standing:

               { c=US,
                 { l=California,
                   o=Network Management Associates }}







NADF                                                           [Page 14]

RFC 1218                A Naming Scheme for c=US              April 1991


          A city government:

               { c=US,
                 l=California,
                 l=City of Mountain View,
                 o=Government }


          A residential person:

               { c=US,
                 l=California,
                 l=City of Mountain View,
                 { cn=Marshall T. Rose, postalCode=94043-2112 }}


          An organization licensed to operate within a city:

               { c=US,
                 l=California,
                 l=City of Mountain View,
                 o=The Tied House }


          An entity within the Federal Government:

               { c=US, o=Government, ou=Department of the Air Force }


          An entity within an organization with national standing:

               { c=US,
                 o=Performance Systems International,
                 ou=Marketing }

9.  Acknowledgements

   This document is based on many sources, including, but not limited
   to:

   - Listing Services Database Generic Requirements, Bellcore
     TA-TSY-000985;

   - Common Directory Use ED 013 (Q/511) (EWOS/EGDIR/90/156);
     and,

   - The THORN X.500 Naming Architecture (UCL-45 revision 6.1).




NADF                                                           [Page 15]

RFC 1218                A Naming Scheme for c=US              April 1991


10.  Bibliography

   X.500: The Directory --- Overview of Concepts, Models, and
        Service, CCITT Recommendation X.500, December, 1988.

   US FIPS 5: Codes for the Identification of the States, The
        District of Columbia and Outlying Areas of the United
        States, and Associated Areas, US Department of Commerce
        FIPS 5--2, May 28, 1987.

   US FIPS 6: Counties and Equivalent Entities of the United
        States, its Possessions, and Associated Areas, US
        Department of Commerce FIPS 6--4, August 31, 1990.

   US FIPS 55: Guideline: Codes for Named Populated Places,
        Primary County Divisions, and other Locational Entities
        of the United States and Outlying Areas, US Department of
        Commerce FIPS 55--2, February 3, 1987.

   The NADF is soliticting comments on this naming scheme.  Comments
   should be directed to:

               Postal:         Dr. Marshall T. Rose
                               Performance Systems International
                               5201 Great American Parkway
                               Suite 3106
                               Santa Clara, CA  95054
                               US
               Telephone:      +1 408 562 6222
               Fax:            +1 408 562 6223
               Internet:       mrose@psi.com
               X.500:          rose, psi, us

   Comments should be received prior to July 1, 1991.

Appendix A:  Naming Architecture

   There are two aspects to the naming architecture: a DIT structure and
   a set of related Schema definitions.  These are shown on pages 17 and
   18, respectively.











NADF                                                           [Page 16]

RFC 1218                A Naming Scheme for c=US              April 1991


DIT Structure

----------------------------------------------------------------------
Level   Element   objectClass             Superior    RDN
----------------------------------------------------------------------
root    0
----------------------------------------------------------------------
intl.   1         country                 0           countryName
----------------------------------------------------------------------
natl.   2         usStateOrEquivalent     1           localityName
        3         usOganization           1           organizationName
        4         nadfADDMD               1           addmdName
----------------------------------------------------------------------
reg.    5         usPlace                 2           localityName
        6         organization            2           organizationName
----------------------------------------------------------------------
local   7         residentialPerson       5           commonName,
                                                      other
        8         organization            5           organizationName
        9         mhsDistributionList     5           commonName
----------------------------------------------------------------------
----------------------------------------------------------------------
opt.    6*        organization            1          organizationName,
                                                     localityName
        7*        residentialPerson       2          commonName,
                                                     other,
                                                     localityName
        8*        organization            2          organizationName,
                                                     localityName
----------------------------------------------------------------------
----------------------------------------------------------------------
org.    10**      organizationalUnit      3,6,8,10,11 orgUnitName
        11**      locality                3,6,8,10,11 localityName
        12**      organizationalRole      3,6,8,10,11 commonName
        13**      organizationalPerson    3,6,8,10,11 commonName
----------------------------------------------------------------------
----------------------------------------------------------------------
appl.   14        applicationProcess      3,6,8,10,11 commonName
        15        nadfApplicationEntity   14          commonName
        16        mhsDistributionList     3,6,8,10,11 commonName
        17        ediUser                 3,6,8,10,11 ediName
        18        device                  3,6,8,10,11 commonName
----------------------------------------------------------------------

   * = These are the optimized form of the corresponding element in the
   civil component.

   ** = This scheme makes no requirements on the DIT structure within an



NADF                                                           [Page 17]

RFC 1218                A Naming Scheme for c=US              April 1991


   organization.  The organizational structure shown here is only for
   exposition.  For example, MHS objects are not listed beneath the
   organizational level, though they are likely to occur within an
   organization.

Schema Definitions

         NADF-SCHEMA { joint-iso-ccitt mhs(6) group(6) al-grimstad(5)
                       nadf(1) schema(1) }

         DEFINITIONS ::= BEGIN

         IMPORTS
             OBJECT-CLASS, ATTRIBUTE
                 FROM InformationFramework
                     { joint-iso-ccitt ds(5) module(1)
                           informationFramework(1) }
             caseIgnoreStringSyntax, Criteria
                 FROM SelectedAttributeTypes
                     { joint-iso-ccitt ds(5) module(1)
                           selectedAttributeTypes(5) }
             locality, organization, applicationEntity, top
                 FROM SelectedObjectClasses
                     { joint-iso-ccitt ds(5) module(1)
                           selectedObjectClasses(6) }
                 ;


         nadf OBJECT IDENTIFIER ::= { joint-iso-ccitt mhs(6) group (6)
                                      al-grimstad(5) 1 }

         nadfModule          OBJECT IDENTIFIER ::= { nadf 1 }
         nadfAttributeType   OBJECT IDENTIFIER ::= { nadf 4 }
         nadfObjectClass     OBJECT IDENTIFIER ::= { nadf 6 }


         -- object classes

         usStateOrEquivalent OBJECT-CLASS
             -- localityName is used for RDN
             -- values come from US FIPS PUB 5
             SUBCLASS OF locality
             MUST CONTAIN { fipsStateNumericCode,
                            fipsStateAlphaCode,
                            stateOrProvinceName }
             MAY CONTAIN  { nadfSearchGuide }
             ::= { nadfObjectClass 1 }




NADF                                                           [Page 18]

RFC 1218                A Naming Scheme for c=US              April 1991


         usPlace OBJECT-CLASS
             -- localityName is used for RDN
             -- values come from US FIPS PUB 55
             SUBCLASS OF locality
             MUST CONTAIN { fipsPlaceNumericCode,
                            localityName }
             MAY CONTAIN  { nadfSearchGuide }
             ::= { nadfObjectClass 2 }

          usCounty OBJECT-CLASS
             SUBCLASS OF usPlace
             MUST CONTAIN { fipsCountyNumericCode }
             ::= { nadfObjectClass 3 }

         usOrganization OBJECT-CLASS
             -- organizationName is used for RDN
             -- values come from ANSI Alphanumeric Registry
             SUBCLASS OF organization
             MUST CONTAIN { ansiOrgNumericCode }
             MAY CONTAIN  { nadfSearchGuide }
             ::= { nadfObjectClass 4 }

         nadfApplicationEntity OBJECT-CLASS
             SUBCLASS OF applicationEntity
             MUST CONTAIN { supportedApplicationContext }
             ::= { nadfObjectClass 5 }

         nadfADDMD OBJECT-CLASS
             -- addmdName is used for RDN
             -- values come from NADF Registry (tbd)
             SUBCLASS OF top
             MUST CONTAIN { addmdName }
             MAY CONTAIN  { nadfSearchGuide }
             ::= { nadfObjectClass 6 }


         -- auxiliary classes

         nadfObject OBJECT-CLASS
             SUBCLASS OF top
             MAY CONTAIN { supplementaryInformation }
             ::= { nadfObjectClass 7 }









NADF                                                           [Page 19]

RFC 1218                A Naming Scheme for c=US              April 1991


         -- attribute types

         fipsStateNumericCode ATTRIBUTE

                 -- semantics and values defined in US FIPS PUB 5
             WITH ATTRIBUTE-SYNTAX
                             -- leading zero is significant
                 NumericString (SIZE (2))
                 MATCHES FOR EQUALITY
             ::= { nadfAttributeType 1 }

         fipsStateAlphaCode ATTRIBUTE
                 -- semantics and values defined in US FIPS PUB 5
             WITH ATTRIBUTE-SYNTAX
                 PrintableString (SIZE (2))
                 MATCHES FOR EQUALITY      -- case-insensitive
             ::= { nadfAttributeType 2 }

         fipsCountyNumericCode ATTRIBUTE
                 -- semantics and values defined in US FIPS PUB 6
             WITH ATTRIBUTE-SYNTAX
                             -- leading zeros are significant
                 NumericString (SIZE (3))
                 MATCHES FOR EQUALITY
             ::= { nadfAttributeType 3 }

         fipsPlaceNumericCode ATTRIBUTE
                 -- semantics and values defined in US FIPS PUB 55
             WITH ATTRIBUTE-SYNTAX
                             -- leading zeros are significant
                 NumericString (SIZE (5))
                 MATCHES FOR EQUALITY
             ::= { nadfAttributeType 4 }

         ansiOrgNumericCode ATTRIBUTE
                 -- semantics and values defined in ANSI registry
             WITH ATTRIBUTE-SYNTAX
                 INTEGER
                 MATCHES FOR EQUALITY
             ::= { nadfAttributeType 5 }

         addmdName ATTRIBUTE
                 -- semantics and values defined in NADF registry
             WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
             ::= { nadfAttributeType 6 }






NADF                                                           [Page 20]

RFC 1218                A Naming Scheme for c=US              April 1991


         nadfSearchGuide ATTRIBUTE
             WITH ATTRIBUTE-SYNTAX NadfGuide
             ::= { nadfAttributeType 7 }

         NadfGuide ::=
             SET {
                 objectClass[0]
                     OBJECT-CLASS,
                 criteria[1]
                     Criteria,
                 subset[2]
                     INTEGER {
                         baseObject(0), oneLevel(1), wholeSubtree(2)
                     } DEFAULT oneLevel
             }

         supplementaryInformation ATTRIBUTE
             WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..76))
             ::= { nadfAttributeType 8 }

         END

Appendix B:  Revision History of this Scheme

   The first version of this scheme (NADF-71) was contributed to the
   North American Directory Forum at its November 27--30, 1990 meeting.
   The (mis)features were:

   (1)  Because of the lack of confidence in ANSI registration
        procedures, it was proposed that the US trademarks be
        used as the basis for RDNs of organizations with
        national-standing.

        This proved unworkable since the same trademark may be
        issued to different organizations in different
        industries.

   (2)  There was no pre-existing registry used for populated
        places.

        This proved unworkable since the effort to define a new
        registry is problematic.

   The second version of this scheme was contributed to the ANSI
   Registration Authority Committee at its January 30, 1991 meeting, and
   the IETF OSI Directory Services Working Group at its February 12--13,
   1991 meeting.  The (mis)features were:




NADF                                                           [Page 21]

RFC 1218                A Naming Scheme for c=US              April 1991


   (1)  The ANSI numeric name form registry was used as the basis
        for RDNs of organizations with national standings.

   (2)  The FIPS 5 state numeric code was used as the basis for
        RDNs of states and state-equivalents.

   (3)  The FIPS 55 place numeric code was used as the basis for
        RDNs of populated places.

   The choice of numeric rather than alphanumeric name forms was
   unpopular, but was motivated by the desire to avoid using the ANSI
   alphanumeric name form registry, which was perceived as unstable.

   The third version of this scheme was contributed to US State
   Department Study Group D's MHS-MD subcommittee at its March 7--8 1991
   meeting.  That version used alphanumeric name forms for all objects,
   under the perception that the ANSI alphanumeric name form registry
   will prove stable.  If the ANSI alphanumeric name form registry
   proves unstable, then two alternatives are possible:

   (1)  disallow organizations with national-standing in the US
        portion of the DIT; or,

   (2)  use the ANSI numeric name form registry instead.

   Hopefully neither of these two undesirable alternatives will prove
   necessary.

   The fourth version of this scheme (NADF-103) was contributed to the
   North American Directory Forum at its March 18--22, 1990 meeting.
   This version introduced the notion of organizations with regional
   standing being listed at the national level through the use of alias
   names and multi-valued RDNs.

   The current (fifth) version of this scheme (NADF-123) generalized the
   listing concept by introducing the notion of optimized civil naming.
   Further, the document was edited to clearly note the different naming
   components and the relation between them.













NADF                                                           [Page 22]

RFC 1218                A Naming Scheme for c=US              April 1991


Security Considerations

   Security issues are not discussed in this memo.

Author's Address

   North American Directory Forum
   c/o Theodore H. Myer
   Rapport Communication, Inc.
   3055 Q Street NW
   Washington, DC  20007

   Tel: +1 202-342-2727






































NADF                                                           [Page 23]