File: rfc1330.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 (4875 lines) | stat: -rw-r--r-- 192,925 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
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
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
2548
2549
2550
2551
2552
2553
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582
2583
2584
2585
2586
2587
2588
2589
2590
2591
2592
2593
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2620
2621
2622
2623
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661
2662
2663
2664
2665
2666
2667
2668
2669
2670
2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686
2687
2688
2689
2690
2691
2692
2693
2694
2695
2696
2697
2698
2699
2700
2701
2702
2703
2704
2705
2706
2707
2708
2709
2710
2711
2712
2713
2714
2715
2716
2717
2718
2719
2720
2721
2722
2723
2724
2725
2726
2727
2728
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
2745
2746
2747
2748
2749
2750
2751
2752
2753
2754
2755
2756
2757
2758
2759
2760
2761
2762
2763
2764
2765
2766
2767
2768
2769
2770
2771
2772
2773
2774
2775
2776
2777
2778
2779
2780
2781
2782
2783
2784
2785
2786
2787
2788
2789
2790
2791
2792
2793
2794
2795
2796
2797
2798
2799
2800
2801
2802
2803
2804
2805
2806
2807
2808
2809
2810
2811
2812
2813
2814
2815
2816
2817
2818
2819
2820
2821
2822
2823
2824
2825
2826
2827
2828
2829
2830
2831
2832
2833
2834
2835
2836
2837
2838
2839
2840
2841
2842
2843
2844
2845
2846
2847
2848
2849
2850
2851
2852
2853
2854
2855
2856
2857
2858
2859
2860
2861
2862
2863
2864
2865
2866
2867
2868
2869
2870
2871
2872
2873
2874
2875
2876
2877
2878
2879
2880
2881
2882
2883
2884
2885
2886
2887
2888
2889
2890
2891
2892
2893
2894
2895
2896
2897
2898
2899
2900
2901
2902
2903
2904
2905
2906
2907
2908
2909
2910
2911
2912
2913
2914
2915
2916
2917
2918
2919
2920
2921
2922
2923
2924
2925
2926
2927
2928
2929
2930
2931
2932
2933
2934
2935
2936
2937
2938
2939
2940
2941
2942
2943
2944
2945
2946
2947
2948
2949
2950
2951
2952
2953
2954
2955
2956
2957
2958
2959
2960
2961
2962
2963
2964
2965
2966
2967
2968
2969
2970
2971
2972
2973
2974
2975
2976
2977
2978
2979
2980
2981
2982
2983
2984
2985
2986
2987
2988
2989
2990
2991
2992
2993
2994
2995
2996
2997
2998
2999
3000
3001
3002
3003
3004
3005
3006
3007
3008
3009
3010
3011
3012
3013
3014
3015
3016
3017
3018
3019
3020
3021
3022
3023
3024
3025
3026
3027
3028
3029
3030
3031
3032
3033
3034
3035
3036
3037
3038
3039
3040
3041
3042
3043
3044
3045
3046
3047
3048
3049
3050
3051
3052
3053
3054
3055
3056
3057
3058
3059
3060
3061
3062
3063
3064
3065
3066
3067
3068
3069
3070
3071
3072
3073
3074
3075
3076
3077
3078
3079
3080
3081
3082
3083
3084
3085
3086
3087
3088
3089
3090
3091
3092
3093
3094
3095
3096
3097
3098
3099
3100
3101
3102
3103
3104
3105
3106
3107
3108
3109
3110
3111
3112
3113
3114
3115
3116
3117
3118
3119
3120
3121
3122
3123
3124
3125
3126
3127
3128
3129
3130
3131
3132
3133
3134
3135
3136
3137
3138
3139
3140
3141
3142
3143
3144
3145
3146
3147
3148
3149
3150
3151
3152
3153
3154
3155
3156
3157
3158
3159
3160
3161
3162
3163
3164
3165
3166
3167
3168
3169
3170
3171
3172
3173
3174
3175
3176
3177
3178
3179
3180
3181
3182
3183
3184
3185
3186
3187
3188
3189
3190
3191
3192
3193
3194
3195
3196
3197
3198
3199
3200
3201
3202
3203
3204
3205
3206
3207
3208
3209
3210
3211
3212
3213
3214
3215
3216
3217
3218
3219
3220
3221
3222
3223
3224
3225
3226
3227
3228
3229
3230
3231
3232
3233
3234
3235
3236
3237
3238
3239
3240
3241
3242
3243
3244
3245
3246
3247
3248
3249
3250
3251
3252
3253
3254
3255
3256
3257
3258
3259
3260
3261
3262
3263
3264
3265
3266
3267
3268
3269
3270
3271
3272
3273
3274
3275
3276
3277
3278
3279
3280
3281
3282
3283
3284
3285
3286
3287
3288
3289
3290
3291
3292
3293
3294
3295
3296
3297
3298
3299
3300
3301
3302
3303
3304
3305
3306
3307
3308
3309
3310
3311
3312
3313
3314
3315
3316
3317
3318
3319
3320
3321
3322
3323
3324
3325
3326
3327
3328
3329
3330
3331
3332
3333
3334
3335
3336
3337
3338
3339
3340
3341
3342
3343
3344
3345
3346
3347
3348
3349
3350
3351
3352
3353
3354
3355
3356
3357
3358
3359
3360
3361
3362
3363
3364
3365
3366
3367
3368
3369
3370
3371
3372
3373
3374
3375
3376
3377
3378
3379
3380
3381
3382
3383
3384
3385
3386
3387
3388
3389
3390
3391
3392
3393
3394
3395
3396
3397
3398
3399
3400
3401
3402
3403
3404
3405
3406
3407
3408
3409
3410
3411
3412
3413
3414
3415
3416
3417
3418
3419
3420
3421
3422
3423
3424
3425
3426
3427
3428
3429
3430
3431
3432
3433
3434
3435
3436
3437
3438
3439
3440
3441
3442
3443
3444
3445
3446
3447
3448
3449
3450
3451
3452
3453
3454
3455
3456
3457
3458
3459
3460
3461
3462
3463
3464
3465
3466
3467
3468
3469
3470
3471
3472
3473
3474
3475
3476
3477
3478
3479
3480
3481
3482
3483
3484
3485
3486
3487
3488
3489
3490
3491
3492
3493
3494
3495
3496
3497
3498
3499
3500
3501
3502
3503
3504
3505
3506
3507
3508
3509
3510
3511
3512
3513
3514
3515
3516
3517
3518
3519
3520
3521
3522
3523
3524
3525
3526
3527
3528
3529
3530
3531
3532
3533
3534
3535
3536
3537
3538
3539
3540
3541
3542
3543
3544
3545
3546
3547
3548
3549
3550
3551
3552
3553
3554
3555
3556
3557
3558
3559
3560
3561
3562
3563
3564
3565
3566
3567
3568
3569
3570
3571
3572
3573
3574
3575
3576
3577
3578
3579
3580
3581
3582
3583
3584
3585
3586
3587
3588
3589
3590
3591
3592
3593
3594
3595
3596
3597
3598
3599
3600
3601
3602
3603
3604
3605
3606
3607
3608
3609
3610
3611
3612
3613
3614
3615
3616
3617
3618
3619
3620
3621
3622
3623
3624
3625
3626
3627
3628
3629
3630
3631
3632
3633
3634
3635
3636
3637
3638
3639
3640
3641
3642
3643
3644
3645
3646
3647
3648
3649
3650
3651
3652
3653
3654
3655
3656
3657
3658
3659
3660
3661
3662
3663
3664
3665
3666
3667
3668
3669
3670
3671
3672
3673
3674
3675
3676
3677
3678
3679
3680
3681
3682
3683
3684
3685
3686
3687
3688
3689
3690
3691
3692
3693
3694
3695
3696
3697
3698
3699
3700
3701
3702
3703
3704
3705
3706
3707
3708
3709
3710
3711
3712
3713
3714
3715
3716
3717
3718
3719
3720
3721
3722
3723
3724
3725
3726
3727
3728
3729
3730
3731
3732
3733
3734
3735
3736
3737
3738
3739
3740
3741
3742
3743
3744
3745
3746
3747
3748
3749
3750
3751
3752
3753
3754
3755
3756
3757
3758
3759
3760
3761
3762
3763
3764
3765
3766
3767
3768
3769
3770
3771
3772
3773
3774
3775
3776
3777
3778
3779
3780
3781
3782
3783
3784
3785
3786
3787
3788
3789
3790
3791
3792
3793
3794
3795
3796
3797
3798
3799
3800
3801
3802
3803
3804
3805
3806
3807
3808
3809
3810
3811
3812
3813
3814
3815
3816
3817
3818
3819
3820
3821
3822
3823
3824
3825
3826
3827
3828
3829
3830
3831
3832
3833
3834
3835
3836
3837
3838
3839
3840
3841
3842
3843
3844
3845
3846
3847
3848
3849
3850
3851
3852
3853
3854
3855
3856
3857
3858
3859
3860
3861
3862
3863
3864
3865
3866
3867
3868
3869
3870
3871
3872
3873
3874
3875
3876
3877
3878
3879
3880
3881
3882
3883
3884
3885
3886
3887
3888
3889
3890
3891
3892
3893
3894
3895
3896
3897
3898
3899
3900
3901
3902
3903
3904
3905
3906
3907
3908
3909
3910
3911
3912
3913
3914
3915
3916
3917
3918
3919
3920
3921
3922
3923
3924
3925
3926
3927
3928
3929
3930
3931
3932
3933
3934
3935
3936
3937
3938
3939
3940
3941
3942
3943
3944
3945
3946
3947
3948
3949
3950
3951
3952
3953
3954
3955
3956
3957
3958
3959
3960
3961
3962
3963
3964
3965
3966
3967
3968
3969
3970
3971
3972
3973
3974
3975
3976
3977
3978
3979
3980
3981
3982
3983
3984
3985
3986
3987
3988
3989
3990
3991
3992
3993
3994
3995
3996
3997
3998
3999
4000
4001
4002
4003
4004
4005
4006
4007
4008
4009
4010
4011
4012
4013
4014
4015
4016
4017
4018
4019
4020
4021
4022
4023
4024
4025
4026
4027
4028
4029
4030
4031
4032
4033
4034
4035
4036
4037
4038
4039
4040
4041
4042
4043
4044
4045
4046
4047
4048
4049
4050
4051
4052
4053
4054
4055
4056
4057
4058
4059
4060
4061
4062
4063
4064
4065
4066
4067
4068
4069
4070
4071
4072
4073
4074
4075
4076
4077
4078
4079
4080
4081
4082
4083
4084
4085
4086
4087
4088
4089
4090
4091
4092
4093
4094
4095
4096
4097
4098
4099
4100
4101
4102
4103
4104
4105
4106
4107
4108
4109
4110
4111
4112
4113
4114
4115
4116
4117
4118
4119
4120
4121
4122
4123
4124
4125
4126
4127
4128
4129
4130
4131
4132
4133
4134
4135
4136
4137
4138
4139
4140
4141
4142
4143
4144
4145
4146
4147
4148
4149
4150
4151
4152
4153
4154
4155
4156
4157
4158
4159
4160
4161
4162
4163
4164
4165
4166
4167
4168
4169
4170
4171
4172
4173
4174
4175
4176
4177
4178
4179
4180
4181
4182
4183
4184
4185
4186
4187
4188
4189
4190
4191
4192
4193
4194
4195
4196
4197
4198
4199
4200
4201
4202
4203
4204
4205
4206
4207
4208
4209
4210
4211
4212
4213
4214
4215
4216
4217
4218
4219
4220
4221
4222
4223
4224
4225
4226
4227
4228
4229
4230
4231
4232
4233
4234
4235
4236
4237
4238
4239
4240
4241
4242
4243
4244
4245
4246
4247
4248
4249
4250
4251
4252
4253
4254
4255
4256
4257
4258
4259
4260
4261
4262
4263
4264
4265
4266
4267
4268
4269
4270
4271
4272
4273
4274
4275
4276
4277
4278
4279
4280
4281
4282
4283
4284
4285
4286
4287
4288
4289
4290
4291
4292
4293
4294
4295
4296
4297
4298
4299
4300
4301
4302
4303
4304
4305
4306
4307
4308
4309
4310
4311
4312
4313
4314
4315
4316
4317
4318
4319
4320
4321
4322
4323
4324
4325
4326
4327
4328
4329
4330
4331
4332
4333
4334
4335
4336
4337
4338
4339
4340
4341
4342
4343
4344
4345
4346
4347
4348
4349
4350
4351
4352
4353
4354
4355
4356
4357
4358
4359
4360
4361
4362
4363
4364
4365
4366
4367
4368
4369
4370
4371
4372
4373
4374
4375
4376
4377
4378
4379
4380
4381
4382
4383
4384
4385
4386
4387
4388
4389
4390
4391
4392
4393
4394
4395
4396
4397
4398
4399
4400
4401
4402
4403
4404
4405
4406
4407
4408
4409
4410
4411
4412
4413
4414
4415
4416
4417
4418
4419
4420
4421
4422
4423
4424
4425
4426
4427
4428
4429
4430
4431
4432
4433
4434
4435
4436
4437
4438
4439
4440
4441
4442
4443
4444
4445
4446
4447
4448
4449
4450
4451
4452
4453
4454
4455
4456
4457
4458
4459
4460
4461
4462
4463
4464
4465
4466
4467
4468
4469
4470
4471
4472
4473
4474
4475
4476
4477
4478
4479
4480
4481
4482
4483
4484
4485
4486
4487
4488
4489
4490
4491
4492
4493
4494
4495
4496
4497
4498
4499
4500
4501
4502
4503
4504
4505
4506
4507
4508
4509
4510
4511
4512
4513
4514
4515
4516
4517
4518
4519
4520
4521
4522
4523
4524
4525
4526
4527
4528
4529
4530
4531
4532
4533
4534
4535
4536
4537
4538
4539
4540
4541
4542
4543
4544
4545
4546
4547
4548
4549
4550
4551
4552
4553
4554
4555
4556
4557
4558
4559
4560
4561
4562
4563
4564
4565
4566
4567
4568
4569
4570
4571
4572
4573
4574
4575
4576
4577
4578
4579
4580
4581
4582
4583
4584
4585
4586
4587
4588
4589
4590
4591
4592
4593
4594
4595
4596
4597
4598
4599
4600
4601
4602
4603
4604
4605
4606
4607
4608
4609
4610
4611
4612
4613
4614
4615
4616
4617
4618
4619
4620
4621
4622
4623
4624
4625
4626
4627
4628
4629
4630
4631
4632
4633
4634
4635
4636
4637
4638
4639
4640
4641
4642
4643
4644
4645
4646
4647
4648
4649
4650
4651
4652
4653
4654
4655
4656
4657
4658
4659
4660
4661
4662
4663
4664
4665
4666
4667
4668
4669
4670
4671
4672
4673
4674
4675
4676
4677
4678
4679
4680
4681
4682
4683
4684
4685
4686
4687
4688
4689
4690
4691
4692
4693
4694
4695
4696
4697
4698
4699
4700
4701
4702
4703
4704
4705
4706
4707
4708
4709
4710
4711
4712
4713
4714
4715
4716
4717
4718
4719
4720
4721
4722
4723
4724
4725
4726
4727
4728
4729
4730
4731
4732
4733
4734
4735
4736
4737
4738
4739
4740
4741
4742
4743
4744
4745
4746
4747
4748
4749
4750
4751
4752
4753
4754
4755
4756
4757
4758
4759
4760
4761
4762
4763
4764
4765
4766
4767
4768
4769
4770
4771
4772
4773
4774
4775
4776
4777
4778
4779
4780
4781
4782
4783
4784
4785
4786
4787
4788
4789
4790
4791
4792
4793
4794
4795
4796
4797
4798
4799
4800
4801
4802
4803
4804
4805
4806
4807
4808
4809
4810
4811
4812
4813
4814
4815
4816
4817
4818
4819
4820
4821
4822
4823
4824
4825
4826
4827
4828
4829
4830
4831
4832
4833
4834
4835
4836
4837
4838
4839
4840
4841
4842
4843
4844
4845
4846
4847
4848
4849
4850
4851
4852
4853
4854
4855
4856
4857
4858
4859
4860
4861
4862
4863
4864
4865
4866
4867
4868
4869
4870
4871
4872
4873
4874
4875






Network Working Group                        ESCC X.500/X.400 Task Force
Request for Comments: 1330      ESnet Site Coordinating Committee (ESCC)
                                         Energy Sciences Network (ESnet)
                                                                May 1992


             Recommendations for the Phase I Deployment of
                   OSI Directory Services (X.500) and
                 OSI Message Handling Services (X.400)
                       within the ESnet Community


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.

Overview

   The Energy Sciences Network (ESnet) is a nation-wide computer data
   communications network managed and funded by the United States
   Department of Energy, Office of Energy Research (U.S. DOE/OER), for
   the purpose of supporting multiple program, open scientific research.
   ESnet is intended to facilitate remote access to major Energy
   Research (ER) scientific facilities, provide needed information
   dissemination among scientific collaborators throughout all ER
   programs, and provide widespread access to existing ER supercomputer
   facilities.

   Coordination of ER-wide network-related technical activities over the
   ESnet backbone is achieved through the ESnet Site Coordinating
   Committee (ESCC). This committee is comprised of one technical
   contact person from each backbone site, as well as some members of
   the ESnet management and networking staff.  As the need for new
   levels of ESnet services arise, the ESCC typically creates task
   forces to investigate and research issues relating to these new
   services.  Each task force usually results in a whitepaper which
   makes recommendations to the ESnet community on how these services
   should be deployed to meet the mission of DOE/OER.

   This RFC is a near verbatim copy of the whitepaper produced by the
   ESnet Site Coordinating Committee's X.500/X.400 Task Force.

Table of Contents

   Status of this Document  .......................................    4
   Acknowledgments  ...............................................    4



ESCC X.500/X.400 Task Force                                     [Page 1]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   1  Introduction  ...............................................    5
   1.1  Abstract and Introduction  ................................    5
   1.2  Structure of this Document  ...............................    5
   2  X.500 - OSI Directory Services  .............................    6
   2.1  Brief Tutorial  ...........................................    6
   2.2  Participation in the PSI White Pages Pilot Project  .......    7
   2.3  Recommended X.500 Implementation  .........................    7
   2.4  Naming Structure  .........................................    8
   2.4.1  Implications of the Adoption of RFC-1255 by PSI  ........    9
   2.4.2  Universities and Commercial Entities  ...................   10
   2.4.3  Naming Structure Below the o=<site> Level  ..............   10
   2.5  Information Stored in X.500  ..............................   13
   2.5.1  Information Security  ...................................   14
   2.6  Accessing the X.500 Directory Service  ....................   14
   2.6.1  Directory Service via WHOIS  ............................   15
   2.6.2  Directory Service via Electronic Mail  ..................   15
   2.6.3  Directory Service via FINGER  ...........................   15
   2.6.4  Directory Service via Specialized Applications  .........   15
   2.6.5  Directory Service from PCs and MACs  ....................   16
   2.7  Services Provided by ESnet  ...............................   16
   2.7.1  X.500 Operations Mailing List  ..........................   17
   2.7.2  Accessing the X.500 Directory  ..........................   17
   2.7.3  Backbone Site Aliases  ..................................   18
   2.7.4  Multiprotocol Stack Support  ............................   18
   2.7.5  Managing a Site's X.500 Information  ....................   19
   2.7.5.1  Open Availability of Site Information  ................   19
   2.7.5.2  Access Methods for Local Users  .......................   19
   2.7.5.3  Limitations of Using ESnet Services  ..................   20
   2.8  ESnet Running a Level-0 DSA for c=US  .....................   20
   2.9  X.500 Registration Requirements  ..........................   21
   2.10  Future X.500 Issues to be Considered  ....................   21
   2.10.1  ADDMDS Interoperating with PRDMDS  .....................   21
   2.10.2  X.400 Interaction with X.500  ..........................   21
   2.10.3  Use of X.500 for NIC Information  ......................   22
   2.10.4  Use of X.500 for Non-White Pages Information  ..........   22
   2.10.5  Introduction of New X.500 Implementations  .............   22
   2.10.6  Interaction of X.500 and DECdns  .......................   22
   3  X.400 - OSI Message Handling Services  ......................   23
   3.1  Brief Tutorial  ...........................................   23
   3.2  ESnet X.400 Logical Backbone  .............................   25
   3.3  Naming Structure  .........................................   25
   3.3.1  Participating in the ESnet Private Management Domain  ...   25
   3.3.2  Operating a Site Private Management Domain  .............   26
   3.3.3  Detailed Name Structure  ................................   26
   3.4  X.400 Routing  ............................................   26
   3.4.1  Responsibilities in Operating an X.400 PRMD MTA  ........   28
   3.4.2  Responsibilities in Operating an X.400 Organizational MTA   29
   3.5  Services Provided by ESnet  ...............................   29



ESCC X.500/X.400 Task Force                                     [Page 2]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   3.5.1  X.400 Operations Mailing List  ..........................   30
   3.5.2  MTA Routing Table on ESnet Information Server  ..........   30
   3.5.3  MTA Routing Table Format  ...............................   30
   3.5.4  Gateway Services and Multiprotocol Stack Support  .......   30
   3.5.5  Registering/Listing your PRMD or Organizational MTA with
          ESnet  ..................................................   31
   3.6  X.400 Message Routing Between ADMDS and PRMDS  ............   32
   3.7  X.400 Registration Requirements  ..........................   32
   3.8  Future X.400 Issues to be Considered  .....................   33
   3.8.1  X.400 Mail Routing to International DOE Researchers  ....   33
   3.8.2  X.400 (1984) and X.400 (1988)  ..........................   33
   3.8.3  X.400 Interaction with X.500  ...........................   33
   4  OSI Name Registration and Issues  ...........................   33
   4.1  Registration Authorities  .................................   34
   4.2  Registration Versus Notification  .........................   34
   4.3  Sources of Nationally Unique Name Registration  ...........   35
   4.4  How to Apply for ANSI Organization Names  .................   35
   4.5  How to Apply for GSA Organization Names  ..................   36
   4.5.1  GSA Designated Agency Representatives  ..................   36
   4.5.2  Forwarding of ANSI Registrations to GSA  ................   37
   4.6  How to Apply for U.S. DOE Organization Names  .............   37
   4.7  Why Apply for a Trademark with the PTO?  ..................   38
   4.8  How to Apply for a Trademark with the PTO  ................   38
   4.9  Future Name Registration Issues to be Considered  .........   39
   4.9.1  ANSI Registered ADMD and PRMD Names  ....................   39
   Glossary  ......................................................   40
   Appendix A:  Current Activities in X.500  ......................   49
   Appendix B:  Current Activities in X.400  ......................   55
   Appendix C:  How to Obtain QUIPU, PP and ISODE  ................   58
   Appendix D:  Sample X.500 Input File and Restricted Character
                List  .............................................   65
   Appendix E:  ESnet Backbone Sites  .............................   68
   Appendix F:  Local Site Contacts for DOE Naming Authorities  ...   70
   Appendix G:  Recommended Reading  ..............................   77
   Appendix H:  Task Force Member Information  ....................   83
   Security Considerations  .......................................   86
   Authors' Addresses  ............................................   86














ESCC X.500/X.400 Task Force                                     [Page 3]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


               Recommendations for the Phase I Deployment of
                    OSI Directory Services (X.500) and
                   OSI Message Handling Services (X.400)
                        within the ESnet Community

         ESnet Site Coordinating Committee X.500/X.400 Task Force

                                Version 1.1

                                March 1992

Status of this Document

   This document makes recommendations for the Phase I deployment of OSI
   Directory Services and OSI Message Handling Services within the ESnet
   Community.  This document is available via anonymous FTP on the ESnet
   Information Server (nic.es.net, 128.55.32.3) in the directory
   [ANONYMOUS.ESNET-DOC] in the file ESNET-X500-X400-VERSION-1-1.TXT.
   The distribution of this document is unlimited.

Acknowledgments

   The following individuals have participated in and contributed to the
   ESCC X.500/X.400 Task Force.  Several of these individuals have also
   authored portions of this document.  See Appendix H for additional
   information regarding task force members and contributing authors.

   Allen Sturtevant (Chair)  Lawrence Livermore National Laboratory
   Bob Aiken                 U.S. DOE/OER/SCS (now with NSF)
   Joe Carlson               Lawrence Livermore National Laboratory
   Les Cottrell              Stanford Linear Accelerator Center
   Tim Doody                 Fermi National Accelerator Laboratory
   Tony Genovese             Lawrence Livermore National Laboratory
   Arlene Getchell           Lawrence Livermore National Laboratory
   Charles Granieri          Stanford Linear Accelerator Center
   Kipp Kippenhan            Fermi National Accelerator Laboratory
   Connie Logg               Stanford Linear Accelerator Center
   Glenn Michel              Los Alamos National Laboratory
   Peter Mierswa             Digital Equipment Corporation
   Jean-Noel Moyne           Lawrence Berkeley Laboratory
   Kevin Oberman             Lawrence Livermore National Laboratory
   Dave Oran                 Digital Equipment Corporation
   Bob Segrest               Digital Equipment Corporation
   Tim Streater              Stanford Linear Accelerator Center
   Mike Sullenberger         Stanford Linear Accelerator Center
   Alan Turner               Pacific Northwest Laboratory
   Linda Winkler             Argonne National Laboratory
   Russ Wright               Lawrence Berkeley Laboratory



ESCC X.500/X.400 Task Force                                     [Page 4]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


1.  Introduction

1.1.  Abstract and Introduction

   This document recommends an initial approach for the Phase I
   deployment of OSI Directory Services (X.500) and OSI Message Handling
   Services (X.400) within the ESnet community.  It is anticipated that
   directly connected ESnet backbone sites will participate and follow
   the suggestions set forth in this document.

   Section 7 of the "ESnet Program Plan" (DOE/OER-0486T, dated March
   1991) cites the need for further research and investigation in the
   areas of electronic mail and directory services.  The ESCC
   X.500/X.400 Task Force was created to address this need.
   Additionally, the task force is addressing the issues of a
   coordinated, interoperable deployment of OSI Directory Services and
   OSI Message Handling within the entire ESnet community.  Since only a
   small subset of this community is actively pursuing these avenues,
   considerable effort must be made to establish the necessary "base" to
   build upon.  If directly connected ESnet sites participate in these
   services, a consistent transition path will be ensured and the
   services provided will be mutually valuable and useful.

   X.500 and X.400 are continuously evolving standards, and are
   typically updated every four years.  U.S. GOSIP (Government OSI
   Profile) Requirements are updated to define additional functionality
   as needed by the U.S. Federal Government, usually every two years.
   As the X.500 and X.400 standards evolve and U.S. GOSIP Requirements
   are extended, consideration must be given as to the effect this may
   have on these existing services in the ESnet community.  At these
   cross-roads, or when a sizeable increase in service functionality is
   desired, another "phase of deployment" may be in order.  In this
   sense, there isn't a specific "final phase" goal, but rather several
   new releases (updates) to the level of existing services.

1.2.  Structure of this Document

   X.500 is presented first.  The issues of DSA (Directory Service
   Agent) deployment, DSA registration, naming schema, involvement in
   the PSI White Pages Pilot Project, recommended object classes,
   recommended attribute types, information security, search
   optimization, user friendly naming and update frequency are
   addressed.

   In the area of X.400, issues relating to MTA (Message Transfer Agent)
   deployment, ESnet X.400 well-known entry points, ESnet backbone site
   X.400 well-known entry points, MTA registration, naming hierarchy,
   PRMD peering, bidirectional X.400-SMTP relaying and



ESCC X.500/X.400 Task Force                                     [Page 5]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   private/commercial X.400 routing are discussed.

   Finally, the issues in name registration with ANSI (American National
   Standards Institute), GSA (General Services Administration) and the
   U.S. Department of Commerce, Patent and Trademark Office (PTO) are
   discussed.

2.  X.500 - OSI Directory Services

2.1.  Brief Tutorial

   X.500 is a CCITT/ISO standard which defines a global solution for the
   distribution and retrieval of information (directory service).  The
   X.500 standard includes the following characteristics:  decentralized
   management, powerful searching capabilities, a single global
   namespace, and a structured framework for the storage of information.
   The 1988 version of the X.500 standard specifies four models to
   define the Directory Service: the Information Model, the Functional
   Model, the Organizational Model and the Security Model.  As is the
   nature of International standards, work continues on the 1992 X.500
   standard agreements.

   The Information Model specifies how information is defined in the
   directory.  The Directory holds information objects, which contain
   information about "interesting" objects in the real-world.  These
   objects are modeled as entries in an information base, the Directory
   Information Base (DIB).  Each entry contains information about one
   object:  ie, a person, a network, or an organization.  An entry is
   constructed from a set of attributes each of which holds a single
   piece of information about the object.  For example, to build an
   entry for a person the attributes might include "surname",
   "telephoneNumber", "postalAddress", "rfc822Mailbox" (SMTP mail
   address), "mhsORAddresses" (X.400 mail address) and
   "facsimileTelephoneNumber".  Each attribute has an attribute syntax
   which describes the data that the attribute contains, for example, an
   alphanumeric string or photo data.  The OSI Directory is extensible
   in that it defines several common types of objects and attributes and
   allows the definition of new ones as new applications are developed
   that make use of the Directory.  Directory entries are arranged in a
   hierarchical structure, the Directory Information Tree (DIT).  It is
   this structure which is used to uniquely name entries.  The name of
   an entry is its Distinguished Name (DN).  It is formed by taking the
   DN of the parent's entry, and adding the the Relative Distinguished
   Name (RDN) of the entry.  Along the path, the RDNs are collected,
   each naming an arc in the path.  Therefore, a DN for an entry is
   built by tracing the path from the root of the DIT to the entry.

   The Functional Model defines how the information is stored in the



ESCC X.500/X.400 Task Force                                     [Page 6]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   directory, and how users access the information.  There are two
   components of this model:  the Directory User Agent (DUA), an
   application-process which interacts with the Directory on behalf of
   the user, and the Directory System Agent (DSA), which holds a
   particular subset of the Directory Information Tree and provides an
   access point to the Directory for a DUA.

   The Organizational Model of the OSI Directory describes the service
   in terms of the policy defined between entities and the information
   they hold.  The model defines how portions of the DIT map onto DSAs.
   A Directory Management Domain (DMD) consists of one or more DSAs,
   which collectively hold and manage a portion of the DIT.

   The Security Model defines two types of security for Directory data:
   Simple Authentication (using passwords) and Strong Authentication
   (using cryptographic keys).  Authentication techniques are invoked
   when a user or process attempts a Directory operation through a DUA.

2.2.  Participation in the PSI White Pages Pilot Project

   The PSI White Pages Pilot Project is currently the most well-
   established X.500 pilot project within the United States.  For the
   country=US portion of the DIT, PSI currently has over 80 organization
   names registered.  Of these, several are ESnet-related.

   The PSI White Pages Pilot Project is also connected to the Pilot
   International Directory Service, PARADISE.  This pilot project
   interconnects X.500 Directory Services between Australia, Austria,
   Belgium, Canada, Denmark, Finland, France, Germany, Greece, Iceland,
   Ireland, Israel, Italy, Japan, Luxembourg, Netherlands, New Zealand,
   Norway, Portugal, Spain, Sweden, Switzerland, United Kingdom and
   Yugoslavia.  The combined totals for all of these countries
   (including the United States) as of December 1991 are:

                       DSAs:                     301
                       Organizations:          2,132
                       White Pages Entries:  581,104

   Considering the large degree of national, and international,
   connectivity within the PSI White Pages Pilot Project, it is
   recommended that directly connected ESnet backbone sites join this
   pilot project.

2.3.  Recommended X.500 Implementation

   Interoperability testing has not been performed on most X.500
   implementations.  Further, some X.500 functions are not mature
   standards and are often added by implementors as noninteroperable



ESCC X.500/X.400 Task Force                                     [Page 7]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   extensions.

   To ensure interoperability for the entire ESnet community, the
   University College London's publicly available X.500 implementation
   (QUIPU) is recommended.  This product is known to run on several
   UNIX-derivative platforms, operates over CLNS and RFC-1006 (with
   RFC-1006 being the currently recommended stack), and is currently in
   wide-spread use around the United States and Europe, including
   several ESnet backbone sites.

   Appendix C contains information on how to obtain QUIPU.

   A later phase deployment of X.500 services within the ESnet community
   will recommend products (either commercial or public domain) which
   pass conformance and interoperability tests.

2.4.  Naming Structure

   As participants in the PSI White Pages Pilot Project, ESnet backbone
   sites will align with the naming structure used by the Pilot.  This
   structure is based upon a naming scheme for the US portion of the DIT
   developed by the North American Directory Forum (NADF) and documented
   in RFC-1255.  Using this scheme, an organization with national
   standing would be listed directly under the US node in the global
   DIT.  Organizations chartered by the U.S. Congress as well as
   organizations who have alphanumeric nameforms registered with ANSI
   are said to have national standing.  Therefore, a backbone site which
   is a national laboratory would be listed under country=US:

              @c=US@o=Lawrence Livermore National Laboratory

   As would a site with an ANSI-registered organization name:

           @c=US@o=National Energy Research Supercomputer Center

   A university would be listed below the state in which it is located:

                @c=US@st=Florida@o=Florida State University

   And a commercial entity would be listed under the city or state in
   which it is doing business, or "Doing Business As", depending upon
   where its DBA is registered:

                   @c=US@st=California@o=General Atomics
                                   (or)
             @c=US@st=California@l=San Diego@o=General Atomics

   A list of the current ESnet backbone sites, and their locations, is



ESCC X.500/X.400 Task Force                                     [Page 8]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   provided in Appendix E.

   Directly connected ESnet backbone sites will be responsible for
   administering objects which reside below their respective portions of
   the DIT.  Essentially, they must provide their own "Name Registration
   Authority".  Although this may appear as an arduous task, it is
   nothing more than the establishment of a procedure for naming, which
   ensures that duplicate entries do not occur at the same level within
   a sub-tree of the DIT.  For example, the Name Registration Authority
   for MIT could create an Organizational Unit named "Computer Science".
   This would appear in the DIT as:

             @c=US@st=Massachusetts@o=MIT@ou=Computer Science

   Similarly, all other names created under the
   "@c=US@st=Massachusetts@o=MIT" portion of the DIT would be
   administered by the same MIT Name Registration Authority.  This
   ensures that every Organizational Unit under
   "@c=US@st=Massachusetts@o=MIT" is unique.  By default, each ESnet
   Site Coordinator is assumed to be the Name Registration Official for
   their respective site.  If an ESnet Site Coordinator does not wish to
   act in this capacity, they may designate another individual, at their
   site, as the Name Registration Official.

2.4.1.  Implications of the Adoption of RFC-1255 by PSI

   The North American Directory Forum (NADF) is comprised of commercial
   vendors positioning themselves to offer commercial X.500 Directory
   Services.  The NADF has produced several documents since its
   formation.  The ones of notable interest are those which define the
   structure and naming rules for the commercially operated DIT under
   country=US.  Specifically, for an Organization to exist directly
   under c=US, it must be an organization with national-standing.  From
   pages 12-13 of RFC-1255, national-standing is defined in the
   following way:

      "An organization is said to have national-standing if it is
      chartered (created and named) by the U.S. Congress.  An example
      of such an organization might be a national laboratory.  There
      is no other entity which is empowered by government to confer
      national-standing on organizations.  However, ANSI maintains an
      alphanumeric nameform registration of organizations, and this
      will be used as the public directory service basis for
      conferring national-standing on private organizations."

   Thus, it appears that National Laboratories (e.g. LBL, LLNL) are
   considered organizations with national-standing.  However, those
   ESnet backbone sites which are not National Laboratories may wish to



ESCC X.500/X.400 Task Force                                     [Page 9]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   register with ANSI to have their organization list directly under
   c=US, but only if this is what they desire.  It is important to note
   that NADF is not a registration authority, but a group of service
   providers defining a set of rules for information sharing and mutual
   interoperability in a commercial environment.

   For further information on registering with ANSI, GSA or the U.S.
   Patent and Trademark office, refer to Section 4 of this document.
   For more information on PSI, refer to Appendix A.

2.4.2.  Universities and Commercial Entities

   Several of the ESnet backbone sites are not National Laboratories
   (e.g. CIT, FSU, GA, ISU, MIT, NYU, UCLA and UTA).  Typically, at
   these sites, a small collection of researchers are involved in
   performing DOE/OER funded research.  Thus, this set of researchers at
   a given site may not adequately represent the total X.500 community
   at their facility. Additionally, ESnet Site Coordinators at these
   facilities may not be authorized to act as the Name Registration
   Official for their site.  So the question is, how do these sites
   participate in the recommended Phase I deployment of ESnet X.500
   services.  There are two possible solutions for this dilemma:

   1.  If the site is not currently operating an X.500 DSA, the ESnet
       Site Coordinator may be able to establish and administer a
       DSA to master the DOE/OER portion of the site's local DIT,
       e.g. "@c=US@st=<st>@o=<site>@ou=Physics".  Before attempting
       this action, it would be prudent for the Site Coordinator to
       notify or seek approval from some responsible entity.  At such
       time that the site wishes to manage its own organization
       within the X.500 DIT, the ESnet Site Coordinator would have to
       make arrangements to put option 2 into effect.

   2.  If the site is currently operating an X.500 DSA, the ESnet
       Site Coordinator may be able to work out an agreement with the
       current DSA administrator to administer a portion of the
       site's local DIT which would represent the DOE/OER community
       at that site.  For example, if the site were already
       administering the organization "@c=US@st=
       Massachusetts@o=Massachusetts Institute of Technology", the
       ESnet Site Coordinator might then be able to administer the
       organizational unit "@c=US@st=Massachusetts@o=Massachusetts
       Institute of Technology@ ou=Physics".

2.4.3.  Naming Structure Below the o=<site> Level

   The structure of the subtree below the organization's node in the DIT
   is a matter for the local organization to decide.  A site's DSA



ESCC X.500/X.400 Task Force                                    [Page 10]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   manager will probably want to enlist input from others within the
   organization before deciding how to structure the local DIT.

   Some organizations currently participating in the Pilot have
   established a simple structure, choosing to limit the number of
   organizational units and levels of hierarchy.  Often this is done in
   order to optimize search performance.  This approach has the added
   benefit of insulating the local DIT from administrative restructuring
   within the organization.  Others have chosen to closely model their
   organization's departmental structure.  Often this approach seems
   more natural and can enhance the information obtained from browsing
   the Directory.

   Below are experiences from current DSA managers, describing the way
   they structured their local DIT and the reasons for doing so.  A site
   may find this information helpful in determining how to structure
   their local DIT.  Ultimately this decision will depend upon the needs
   of the local organization and expectations of Directory usage.

   Valdis Kletnieks of the Virginia Polytechnic Institute:

      "For Virginia Tech, it turned out to be a reasonably
      straightforward process.  Basically, the University is
      organized on a College/Department basis.  We decided to model
      that "real" structure in the DIT for two major reasons:

      "(a) It duplicates the way we do business, so interfacing the
      X.500 directory with the "real world" is easier.

      "(b) With 600+ departmental units and 11,000+ people (to be
      30,000+ once we add students), a "zero" (everybody at top) or
      "one" deep (600 departments at top) arrangement just didn't
      hack it - it was deemed necessary that you be able to do a
      some 120 or 140 county office entries under the Extension
      service, it's a BIT unwieldy there).  However, with some 20
      college-level entries at the top, and the "average" college
      having 30 departments, and the "average" department being from
      10 to 40 people, it works out pretty well."

   Jeff Tannehill of Duke University:

      "Our DIT is flat.  We get the entire database of people at Duke
      from Tel-Com and just put everyone directly under "O=Duke
      University".

      "Actually, there is an exception, when the DSA was first set up
      and we had not received a database yet, I configured the DIT to
      include "OU=Computer Science", under which myself and one other



ESCC X.500/X.400 Task Force                                    [Page 11]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


      System Administrator have entries.  Upon getting the database
      for everyone else I decided not to attempt to separate the
      people in the database into multiple ou's."

   Joe Carlson of Lawrence Livermore National Laboratory:

      "We tried both flat (actually all under the same OU) and
      splitting based on internal department name and ended up with
      flat.  Our primary reason was load and search times, which were
      2-3 times faster for flat organization."

   Paul Mauvais of Portland State University:

      "We originally set up our DIT by simply loading our campus
      phone book into one level down from the top (e.g. OU=Faculty
      and Staff, OU=Students, OU=Computing Services).

      "I'd love to have an easy way to convert our flat faculty and
      staff area into departments and colleges, but the time to
      convert the data into the separate OU's is probably more than I
      have right now."

   Mohamed Ellozy of Dana-Farber Cancer Institute:

      "Here we have a phone database that includes department, so we
      got the ou's with no effort.  We thus never went the flat space
      way."

   Dan Moline of TRW:

      "Well - we're still in the process of defining our DIT.  TRW
      comes under the international companies DBA.  Our part under
      the PSI White Pages Pilot defines the DIT for our space and
      defense organization here in Redondo Beach (however, I
      organized the structure to adhere to TRW corporate).  We input
      from our manpower DB for our S&D personnel.  We're trying to
      get corporate's DB for possible input.

      "However, arranging your DIT by organizations (at least for
      corps) presents a problem; things are always being reorganized!
      We were DSO now we're SSO!!!  We still have some of our old
      domain name for DNS tied to organizations that have not existed
      for years!

      "So we are currently redesigning our DIT to try to fit NADF 175
      (something more geographically).  Our reasoning was that
      organizations may change but buildings and localities do not."




ESCC X.500/X.400 Task Force                                    [Page 12]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   Ruth Lang of SRI:

      "There has been no SRI-wide policy or decision to participate
      in the PSI White Pages Pilot.  @c=US@O=SRI International
      supports the information for one OU only (i.e., a local policy
      and decision).  In order to not give the false impression that
      all SRI information was contained under this O=SRI
      International, I used OU=Network Information Systems Center.
      If I were to structure the DIT for all of SRI, I'm sure that my
      thinking would yield a much different structure."

   Russ Wright of Lawrence Berkeley Laboratory:

      "Since we don't have much organizational information in current
      staff database, I have to stick to a fairly flat structure.  I
      have two OUs.  One is for permanent staff, the other is for
      guests (there is a flag in our database that is set for
      guests).

      "I may add an additional level of OUs to our current structure.
      The top level would contain different 'types' of information.
      For example, one OU may be 'Personnel', another may be called
      publications).  Staff and Guests would reside under the
      Personnel OU."

   Peter Yee of NASA Ames:

      "I broke up my DIT at the NASA Center level.  NASA is made of
      nearly 20 Centers and Facilities.  The decision to break up at
      this level was driven by several factors:

      "1.  Control of the local portion of the DIT should reside with
      the Center in question, particularly since the Center probably
      supplies the data in question and controls the matching DSA.

      "2.  Each Center ranges in size from 1,000 to 16,000 persons.
      This seems to be the range that works well on moderate sized
      UNIX servers.  Smaller would be a waste, larger would require
      too much memory.

      "3.  Representatives from several Centers have contacted me
      asking if they could run their own DSAs so that they can
      experiment with X.500.  Thus the relevant DSA needs to be under
      their control."

2.5.  Information Stored in X.500

   The Phase I deployment of X.500 should be limited to "white pages"-



ESCC X.500/X.400 Task Force                                    [Page 13]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   type information about people.  Other types of objects can be added
   in later Phases, or added dynamically as the need arises.

   To make X.500 truly useful to the ESnet community as a White Pages
   service, it is recommended that the following minimum information
   should be stored in the X.500 database:

   Information   ASN.1 Attribute Type      Example
   -----------   --------------------      -------
   Locator Info  commonName                Allen Sturtevant
                 surname                   Sturtevant
                 postalAddress             LLNL
                                           P.O. Box 5509, L-561
                                           Livermore, CA 94551
                 telephoneNumber           +1 510 422 8266
                 facsimileTelephoneNumber  +1 510 422 0435

   E-Mail Info   rfc822Mailbox             Sturtevant@es.net
                 mhsORAddresses            /PN=Allen Sturtevant/O=NERSC/
                                             /PRMD=ESnet/ADMD= /C=US/
                 otherMailbox              DECnet:  ESNIC::APS

   The above list of attributes comprises a minimum set which is
   recommended for a person's entry.  However, you may chose to omit
   some attributes for reasons of privacy or legality.  Note that the
   X.500 standard requires that the surname and commonName attributes be
   present.  If an individual's phone number and/or address cannot be
   provided, they should be replaced by the site's "Information Phone
   Number" and postal address to allow some means of contacting the
   person.

2.5.1.  Information Security

   It is understood that placing this type of information in X.500 is
   equivalent to putting the "Company Phone Book" on-line in the
   Internet.  Different sites may treat this information differently.
   Some may view it as confidential, while others may view this data as
   open to the public.  In any case, it was recommended that ESnet sites
   discuss the implications with their respective legal departments
   before actually making their information openly available. There
   currently exists minimal access control in several X.500
   implementations.

2.6.  Accessing the X.500 Directory Service

   The PSI White Pages Pilot Project software provides numerous
   interfaces to the information in the X.500 Directory.  Non-
   interactive access mechanisms (e.g. WHOIS, FINGER and Electronic



ESCC X.500/X.400 Task Force                                    [Page 14]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   Mail) make use of capabilities or services which already reside on
   many workstations and hosts.  Such hosts could immediately take
   advantage of the X.500 service with no additional software or
   reconfiguration needed.  However, since these methods are non-
   interactive, they only provide a way to search for and read
   information in the Directory but no way to modify information.

2.6.1.  Directory Service via WHOIS

   The Pilot Project software allows you to configure the X.500
   Directory service to be made available via a network port offering an
   emulation of the SRI-NIC WHOIS service.  UNIX-based hosts and VMS
   hosts running Multinet typically come configured with the WHOIS
   service.  Users at their workstations would then be able to issue a
   simple WHOIS command to a known host running a DSA to retrieve
   information about colleagues at their site or at other ESnet sites.
   For example, the command:

      whois -h wp.lbl.gov wright

   will return information about Russ Wright at Lawrence Berkeley Lab.
   It is recommended that all sites which bring up such a service,
   should provide an alias name for the host running their DSA of the
   form <wp.site.domain> for consistency within the ESnet community.

2.6.2.  Directory Service via Electronic Mail

   The Pilot Project software also allows the X.500 Directory service to
   be made available via electronic mail.  A user who sends an
   electronic mail message to a known host running a DSA containing a
   WHOIS-like command on the subject line, would then receive a return
   mail message containing the results of their query.

2.6.3.  Directory Service via FINGER

   The X.500 Directory service could also be made available via the
   FINGER service.  Although this access method does not come with the
   PSI Pilot Project software, several sites have already implemented a
   FINGER interface to the X.500 Directory.  For ease of use and
   consistency, a single FINGER interface should be selected, then
   individual implementations within the ESnet community should conform
   to this interface.

2.6.4.  Directory Service via Specialized Applications

   Many X.500 Directory User Agents (DUAs) are widely available.  Some
   of these come with the PSI Pilot Project software.  Other DUAs, which
   have been developed by third parties to fit into the pilot software,



ESCC X.500/X.400 Task Force                                    [Page 15]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   are publicly available.  These user agents support interactive access
   to the X.500 Directory allowing browsing, searching, listing and
   modifying data in the Directory.  However, in most cases, use of
   these DUAs requires the Pilot Project software be installed on the
   host system.  Only a few of these DUAs and their capabilities are
   described below.

   o  DISH - A User Agent which provides a textual interface to the
      X.500 Directory.  It gives full access to all elements of the
      Directory Access Protocol (DAP) and as such may be complex for
      novice users.  DISH is most useful to the DSA administrator.

   o  FRED - A User Agent which has been optimized for "white pages"
      types of queries.  The FRED program is meant to be similar to
      the WHOIS network service.  FRED supports reading, searching,
      and modifying information in the X.500 Directory.

   o  POD - An X-windows based User Agent intended for novice users.
      POD relies heavily on the concept of the user "navigating"
      around the DIT.  Pod supports reading and searching.  There are
      no facilities to add entries or to modify the RDNs of entries,
      though most other entry modifications are allowed.

2.6.5.  Directory Service from PCs and MACs

   Smaller workstations and personal computers lack the computing power
   or necessary software to implement a full OSI protocol stack.  As a
   consequence, several "light-weight" protocols have been developed
   whereby the DAP runs on a capable workstation and exports a simpler
   interface to other end-systems.  One such "light weight" protocol,
   the Directory Assistance Service (DAS), is incorporated in the PSI
   Pilot Project software.  Another "light weight" protocol, DIXIE, was
   developed at the University of Michigan.  Publicly available User
   Agents for both the MAC and PC have been developed using the DA-
   service and the DIXIE protocol.  So long as you have the Pilot
   Project software running on one host, you can provide these User
   Agents on many end-systems without having to install the Pilot
   software on all those end-systems.

   For further information about available Directory User Agents, see
   RFC-1292, "Catalog of Available X.500 Implementations".

2.7.  Services Provided by ESnet

   Currently, there are several ESnet backbone sites which are operating
   their own DSAs within the PSI White Pages Pilot Project.  It is
   anticipated that directly connected ESnet backbone sites will
   eventually install and operate their own X.500 DSAs.  In the interim,



ESCC X.500/X.400 Task Force                                    [Page 16]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   ESnet will provide complete support for ESnet backbone sites which
   presently do not have the time, expertise or equipment to establish
   X.500 services.  The mechanism for doing this is described in Section
   2.7.5 below.  Additionally, ESnet will provide a variety of services
   in support of the entire X.500 community.  These are also described
   in the following sections.

2.7.1.  X.500 Operations Mailing List

   ESnet maintains a mailing list for the discussion of relevant X.500
   topics. This mailing list provides a means for sharing information,
   experiences, and expertise about X.500 in the ESnet community.  New
   sites joining the ESnet X.500 community will be announced on the
   mailing list.  New DSA administrators will be able to solicit help
   from more experienced administrators.  When a site brings up a new
   X.500 DSA, the DSA manager should notify the ESnet DSA manager so as
   to ensure they are promptly added to the mailing list.

      General discussion:  x500-ops@es.net
      To subscribe:        x500-ops-request@es.net

2.7.2.  Accessing the X.500 Directory

   ESnet has made the X.500 service openly available to the entire ESnet
   community via each of the access methods described in Section 2.6
   above.  Host WP.ES.NET provides TELNET access, FINGER and WHOIS
   emulations, querying via electronic mail, as well as remote access
   via light-weight protocols.  By making these services widely
   available, we hope to acquaint more users with the features and
   capabilities of X.500.

   To try out some of the X.500 User Agents, simply TELNET to WP.ES.NET
   and login as user "fred"; no password is required.  You have the
   choice of running the Fred or Pod User Agents.  Fred provides a
   command line interface while Pod provides an X-windows based
   interface.  You can browse through the global X.500 DIT, search for
   persons in various organizations, and even modify your own entry if
   you have one.

   Host WP.ES.NET also provides access to the X.500 Directory via
   emulations of the FINGER and WHOIS utilities.  These interfaces
   support a user-friendly-naming (UFN) scheme that simplifies the
   syntax necessary to search for persons in other organizations.  The
   following WHOIS command lines illustrate searching for persons at
   various ESnet sites, utilizing the UFN syntax (similar FINGER command
   lines could also be constructed):





ESCC X.500/X.400 Task Force                                    [Page 17]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


      whois -h wp.es.net leighton,nersc
      whois -h wp.es.net servey,doe
      whois -h wp.es.net logg,slac
      whois -h wp.es.net "russ wright",lbl

   For further information about User Friendly Naming, see Steve
   Hardcastle-Kille's working document titled, "Using the OSI Directory
   to Achieve User Friendly Naming".

2.7.3.  Backbone Site Aliases

   As ESnet backbone sites join the X.500 pilot, their organizations'
   entries will be placed in various parts of the DIT.  For example,
   National Laboratories will be placed directly under the c=US portion
   of the DIT, while universities and commercial entities will most
   likely be placed under localities, such as states or cities.

   In order to facilitate searching for the ESnet community as a whole,
   ESnet backbone sites will also be listed as organizational units
   under the node "@c=US@o=Energy Sciences Network".  These entries will
   actually be aliases which point to the site's "real" organizational
   entry.  Therefore, ESnet backbone sites will be listed in two
   different places in the DIT and one could search for them in either
   location.

2.7.4.  Multiprotocol Stack Support

   OSI applications currently run over many different transport/network
   protocols, a factor which hinders communication between OSI end
   nodes.  In order to facilitate communication, the ISODE may be
   configured at compile time to support any combination of the
   following stacks:

      RFC-1006 over TCP/IP
      TP0      over X.25
      TP0      over X.25 (84)
      TP0      over the TP0-bridge
      TP4      over CLNP

   Within the ESnet community, the stacks of interest are RFC-1006 over
   TCP/IP, TP4 over CLNP, and TP0 over X.25.  If a backbone site's DSA
   is not running over all three of these stacks, it may eventually
   receive referrals to a DSA that it can not connect to directly, so
   the operation can not proceed.  Since the ESnet DSAs will be
   configured to operate over all of the "stacks of interest," they can
   serve as relay DSAs between site DSAs that do not have direct
   connectivity.  The site's DSA manager will need to contact the ESnet
   DSA manager to arrange for this relaying to occur.  Backbone sites



ESCC X.500/X.400 Task Force                                    [Page 18]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   will be encouraged to eventually provide as many of the three stacks
   of interest as possible.

2.7.5.  Managing a Site's X.500 Information

   For sites which do not initially wish to operate their own DSA,
   ESnet's DSA will master their site's portion of the DIT, enabling the
   site to join the PSI Pilot Project and the ESnet X.500 community.  In
   order to accomplish this, the site must provide the ESnet DSA manager
   with information about the people to be included in the X.500
   Directory.  This information can usually be obtained from your Site's
   Personnel Database.

   ESnet will only maintain a limited amount of information on behalf of
   each person to be represented in the Directory.  The attribute types
   listed in the table in Section 2.5 show the maximum amount of
   information which the ESnet DSA will support for a person's entry in
   the Directory. This set of attribute types is a small subset of the
   attribute types offered by the PSI Pilot Project software.
   Therefore, if a site wishes to include additional attribute types,
   they should consider installing and operating their own DSA.

   The format of the information to be provided to the ESnet DSA manager
   is as follows:  the data should be contained in a flat, ASCII text
   file, one record (line) per person, with a specified delimiter
   separating the fields of the record.  More detailed information and a
   sample of a site-supplied data file can be found in Appendix D.

2.7.5.1.  Open Availability of Site Information

   Although the PSI Pilot Project allows you to control who may access
   Directory objects and their attributes, any information you provide
   about persons at your site to be stored in the ESnet DSA will be
   considered world readable.  This policy is necessary in order to
   minimize the administrative cost of managing potentially many
   organizational objects within the ESnet DSA.  If your site decides
   that it does not wish to have certain information about its employees
   publicly known (e.g. work telephone number) then you should not
   provide this information to the ESnet DSA manager or you should
   consider installing and administering your own DSA.

2.7.5.2.  Access Methods for Local Users

   Backbone sites which choose the option of having the ESnet DSA master
   their organization's X.500 information should make the availability
   of the X.500 service known to their local users.  All of the methods
   described in Section 2.7.2 are available for use, but none of these
   methods will assume the query is relative to the local site.



ESCC X.500/X.400 Task Force                                    [Page 19]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   To facilitate querying relative to the local environment, the site
   will need to make one host available to run the emulation of the
   FINGER service.  Although the resulting query will ultimately be
   directed to the remote ESnet DSA, the search will appear to be local
   to the users at that site.  For example, a user on a workstation at
   site XYZ could type the following, omitting their local domain name
   as this is implied:

      finger jones@wp

   This will retrieve information about user Jones at site XYZ (wp is
   the name or alias of a host at site XYZ, i.e. wp.XYZ.GOV).  The site
   coordinator will need to contact the ESnet DSA manager to arrange the
   set up for this service.

2.7.5.3.  Limitations of Using ESnet Services

   Since the ESnet DSA will potentially be mastering information on
   behalf of numerous backbone sites, limits will need to be placed on
   the volume of site information stored in the ESnet DSAs.  These are
   enforced to ensure DSA responsiveness, as well as to reduce
   administrative maintenance.  The limits are:

                 Item                       Maximum Limit
                 ----                       -------------
                 X.500 Organizations                    1
                 Organizational Units                  50
                 Organizational Unit Depth              3
                 Object Entries                     5,000
                 Update Frequency                 1 Month
                 Aliases                              n/a
                 Object/Attribute Access Control      n/a

   One week before each monthly update cycle, a message will be sent on
   the x500-ops@es.net mailer to remind the sites that an update cycle
   is approaching.  If no changes are required to the site information,
   the reminder message can be ignored and the existing version of this
   information will be used. If the information is to be updated, a
   complete replacement of all information must be supplied to the ESnet
   DSA manager before the next update cycle.  More detailed information
   and a sample of a site-supplied data file can be found in Appendix D.

2.8.  ESnet Running a Level-0 DSA for c=US

   For ESnet to provide high quality X.500 services to the ESnet
   community, the ESnet DSAs must operate as Level-0 (first level) DSAs.
   It is currently planned that these DSAs will act as slave, Level-0
   DSAs to PSI's master, Level-0 DSAs.  Once the ESnet DSAs are in



ESCC X.500/X.400 Task Force                                    [Page 20]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   production service, it is recommended that directly connected ESnet
   backbone sites operating their own X.500 DSAs configure them with one
   of the ESnet DSAs as their parent DSA.  This provides several
   advantages to the ESnet community:

   1.  The ESnet DSAs will be monitored by the NERSC's 24-hour
       Operations Staff.  Additionally, ESnet plans to deploy two
       (2) DSAs in geographically disperse locations to ensure
       reliability and availability.

   2.  All queries to Level-0 DSAs remain within the ESnet high-speed
       backbone.

   3.  If network connectivity is lost to all external Level-0 DSAs,
       X.500 Level-0 connectivity will still exist within the ESnet
       backbone.

2.9.  X.500 Registration Requirements

   X.500 organization names must be nationally unique if they appear
   directly below the c=US level in the DIT structure.  Nationally
   unique names must be registered through an appropriate registration
   authority, i.e., one which grants nationally unique names.

   X.500 organizational unit names need to be unique relative to the
   node directly superior to them in the DIT.  Registration of these
   names should be conducted through the "owner" of the superior node.

   The registration of X.500 names below the organization level are
   usually a local matter.  However, all siblings under a given node in
   the DIT must have unique RDNs.

   See Section 4 for a more complete description of OSI registration
   issues and procedures.

2.10.  Future X.500 Issues to be Considered

2.10.1.  ADDMDS Interoperating with PRDMDS

   This is a problem which currently does not have an answer.  The issue
   of Administrative Directory Management Domains (ADDMDs) interacting
   with Private Directory Management Domains (PRDMDs) is just beginning
   to be investigated by several groups interested in solving this
   problem.

2.10.2.  X.400 Interaction with X.500

   The current level of understanding is that X.400 can benefit from the



ESCC X.500/X.400 Task Force                                    [Page 21]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   use of X.500 in two ways:

   1.  Lookup of message recipient information.

   2.  Lookup of message routing information.

   X.400 technology and products, as they stand today, do not support
   both of these features in a fully integrated fashion across multiple
   vendors.  As the standards and technology evolve, consideration will
   have to be given in applying these new functions to the production
   ESnet X.500/X.400 services environment.

2.10.3.  Use of X.500 for NIC Information

   Work is currently being performed in the IETF to place NIC
   information on-line in an Internet-based X.500 service.

2.10.4.  Use of X.500 for Non-White Pages Information

   The PSI White Pages Pilot Project has caused increasing and popular
   use of X.500 as a white pages services within the Internet community.
   However, the X.500 standard provides for much more than just this
   service.  Application processes, devices and security objects are
   just a few of the objects to be considered for future incorporation
   in the global X.500 database.

2.10.5.  Introduction of New X.500 Implementations

   Thought will have to be given to the use of commercial X.500 products
   in the future as QUIPU (the implementation recommended in this paper)
   may not meet all of the needs of the ESnet community.  As commercial
   products mature and become stable, they will have to be incorporated
   into the ESnet X.500 service in a way which ensures interoperability
   and reliability.

2.10.6.  Interaction of X.500 and DECdns

   There is every indication that DECdns and X.500 will interoperate in
   some fashion in the future.  Since there is an evolving DECdns
   namespace (i.e.  OMNI) and an evolving X.500 DIT (i.e. NADF), some
   consideration should be given to how these two name trees will
   interact.  All of this will be driven by the Digital Equipment
   Corporation's decisions on how to expand and incorporate its DECdns
   product with X.500.







ESCC X.500/X.400 Task Force                                    [Page 22]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


3.  X.400 - OSI Message Handling Services

3.1.  Brief Tutorial

   In 1984 CCITT defined a set of protocols for the exchange of
   electronic messages called Message Handling Systems (MHS) and is
   described in their X.400 series of recommendations.  ISO incorporated
   these recommendations in their standards (ISO 10021).  The name used
   by ISO for their system was MOTIS (Message-Oriented Text Interchange
   Systems).  In 1988 CCITT worked to align their X.400 recommendations
   with ISO 10021.  Currently when people discuss messaging systems they
   use the term X.400.  These two systems are designed for the general
   purpose of exchanging electronic messages in a store and forward
   environment.  The principle use being made of this system today is to
   support electronic mail.  This section will give an overview of X.400
   as used for electronic mail.  In the following sections, the term
   X.400 will be used to describe both the X.400 and MOTIS systems.

   The basic model used by X.400 MHS is that of a Message Transfer
   System (MTS) accessed via a User Agent (UA).  A UA is an application
   that interacts with the Message Transfer System to submit messages on
   behalf of a user.  A user is referred to as either an Originator
   (when sending a message) or a Recipient (when receiving one).  The
   process starts out when an Originator prepares a message with the
   assistance of their UA.  The UA then submits the message to the MTS
   for delivery.  The MTS then delivers the message to one or more
   Recipient UAs.

                    _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
       ______      |      _______          _______     |     ______
      |      |     | MTS |       |        |       |    |    |      |
      |  UA  |<----|---->|  MTA  |<------>|  MTA  |<---|--->|  UA  |
      |______|     |     |_______|        |_______|    |    |______|
                   |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|

   The MTS provides the general store-and-forward message transfer
   service. It is made up of a number of distributed Message Transfer
   Agents (MTA).  Operating together, the MTAs relay the messages and
   deliver them to the intended recipient UAs, which then makes the
   messages available to the recipient (user).

   The basic structure of an X.400 message is an envelope and content
   (i.e.  message).  The envelope carries information to be used when
   transferring the message through the MTS.  The content is the piece
   of information that the originating UA wishes delivered to the
   recipient UA.  There are a number of content types that can be
   carried in X.400 envelopes.  The standard user message content type
   defined by X.400 is called the Interpersonal (IP) message.  An IP



ESCC X.500/X.400 Task Force                                    [Page 23]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   message consists of two parts, the heading and body.  The heading
   contains the message control information. The body contains the user
   message.  The body may consist of a number of different body parts.
   For example one IP message could carry voice, text, Telex and
   facsimile body parts.

   The Management domain (MD) concept within the X.400 recommendations
   defines the ownership, operational and control boundary of an X.400
   administration.  The collection consisting of at least one MTA and
   zero or more UAs owned by an organization or public provider
   constitutes a management domain (MD).  If the MD is managed by a
   public provider it is called an Administration Management Domain
   (ADMD).  The MD managed by a company or organization is called a
   Private Management Domain (PRMD).  A Private MD is considered to
   exist entirely within one country.  Within that country a PRMD may
   have access to one or more ADMDs.

   Each MD must ensure that every user (i.e UA) in the MD has at least
   one name.  This name is called the Originator/Recipient (O/R) Name.
   O/R Names are constructed from a set of standard attributes:

   o  Country Name

   o  Administration Management Domain

   o  Private Management Domain

   o  Organization Name

   o  Organizational Unit Name

   o  Surname

   o  Given name

   o  Initials

   o  Generational Qualifier

   An O/R name must locate one unambiguous O/R UA if the message is to
   be routed correctly through the Message Transfer Service.  Currently
   each MD along the route a message takes determines the next MD's MTA
   to which the message should be transferred.  No attempt is made to
   establish the full route for a message, either in the originating MD
   or in any other MD that acquires the store and forward responsibility
   for the message.

   Messages are relayed by each MD on the basis of the Management domain



ESCC X.500/X.400 Task Force                                    [Page 24]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   portion of their O/R Name until arrival at the recipient MD.  At
   which point, the other attributes in the name are used to further
   route to the recipient UA.  Internal routing within a MD is the
   responsibility of each MD.

3.2.  ESnet X.400 Logical Backbone

   Currently within the ESnet community message handling services are
   implemented with a number of different mail products, resulting in
   what is classically known as an "n-squared" problem.  For example,
   let's say that LLNL only uses QuickMail on site, PPPL only uses
   MAIL-11 (VMS MAIL), and CEBAF only uses SMTP mail.  For LLNL to send
   mail to PPPL and CEBAF, is must support MAIL-11 and SMTP locally on-
   site.  Likewise for PPPL to send mail to LLNL and CEBAF, it must
   support MAIL-11 and QuickMail locally.  Identically, this scenario
   exists for CEBAF.

   To alleviate this problem, a logical X.400 backbone must be
   established through out the entire ESnet backbone.  Then, each ESnet
   backbone site will be responsible for only providing connectivity
   between it's local mail domains (QuickMail, MAIL-11, SMTP Mail, or
   even native X.400) and the logical X.400 backbone.  One of the long-
   term goals is to establish X.400 as the "common denominator" between
   directly connected ESnet backbone sites.

3.3.  Naming Structure

   The name-spaces for X.500 and X.400 are completely different and are
   structured to meet different needs.  The X.500 name-space is
   typically organized to allow quick, optimized searching; while the
   X.400 ORname is used to forward an X.400 message through several
   "levels" of MTAs (X.400 Message Transfer Agents).

   ESnet backbone sites will participate in the X.400 environment
   through one of two options; either participating in the ESnet Private
   Management Domain (PRMD) or operating a site PRMD.  For most sites,
   utilizing the ESnet PRMD will be the simpler and preferable choice.

3.3.1.  Participating in the ESnet Private Management Domain

   ESnet backbone sites participating in the ESnet PRMD will have an
   X.400 name syntax as follows:

                   /.../O=<site>/PRMD=ESnet/ADMD= /C=US/

   A few examples of a possible X.400 ORnames using the above syntax
   are:




ESCC X.500/X.400 Task Force                                    [Page 25]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


         /PN=Smith/OU=Computations/O=LLNL/PRMD=ESnet/ADMD= /C=US/
            /PN=Jones/OU=Physics/O=PPPL/PRMD=ESnet/ADMD= /C=US/

   These sites will operate an MTA at the /O=<organization> level in the
   name hierarchy.

3.3.2.  Operating a Site Private Management Domain

   ESnet backbone sites which operate a PRMD will have an X.400 name
   syntax as follows:

                   /.../O=<org>/PRMD=<site>/ADMD= /C=US/

   A few examples of a possible X.400 ORnames using the above syntax
   are:

              /PN=Smith/O=Computations/PRMD=LLNL/ADMD= /C=US/
                /PN=Jones/O=Physics/PRMD=PPPL/ADMD= /C=US/

   These sites will operate an MTA at the /PRMD=<PRMD> level in the name
   hierarchy.  This MTA will peer with the ESnet PRMD MTA.

3.3.3.  Detailed Name Structure

   GOSIP places several limits on allowable ORnames.  After the
   /O=<organization> name, up to four levels of
   /OU=<organizational_unit> names are allowed.  The ORname string is
   then completed with the /PN=<personal_name> field.

   All ORname fields must use characters from the ISO printable
   character set.  Additionally, the following name length restrictions
   apply:

                PRMD Names                    16 characters
                Organization Names            64 characters
                Organizational Unit Names     32 characters
                Personal Names                64 characters

      NOTE:  A 40 character limit for Personal Names is now being
             studied by the CCITT.

   Within these name constraints, the architecting of an organization's
   name space is a local matter.  Sites are encouraged to consider ease
   of use and stability when determining their naming structure.

3.4.  X.400 Routing

   In the IP environment a SMTP MTA could use the Domain Name Service



ESCC X.500/X.400 Task Force                                    [Page 26]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   (DNS) to locate connection information for the host closest to the
   recipient.  With X.400, MTAs must know the remote MTAs name and
   password along with connection information.  This is because of
   access control requirements on some X.400 systems.  In X.400 MHS this
   information will, at some future date, be provided by X.500.  In the
   mean time the routing and connection process within the X.400
   community is table driven.  This solution requires a coordination and
   distribution effort to ensure a quick and reliable update of these
   tables.

   The current thinking on the problem of X.400 routing is to decompose
   the X.400 address space into a hierarchy, with each node in this
   hierarchy representing the entry point for an X.400 domain.  These
   nodes have been commonly called Well Known Entry Points (WEPs).  Each
   of these WEPs represent one X.400 MHS domain.  For example:

      /O=LBL/PRMD=ESnet/ADMD= /C=US/
      /O=NERSC/PRMD=ESnet/ADMD= /C=US/
      /PRMD=ESnet/ADMD= /C=US/
      /PRMD=ANL/ADMD= /C=US/
      /PRMD=PNL/ADMD= /C=US/

   To minimize the number of hops between Originators and Recipients it
   is the current recommendation of the X.400 community that every PRMD
   peer with all other PRMDs.

   The ESnet backbone will provide connectivity between multiple PRMDs
   (the ESnet PRMD and any site operated PRMDs), each with associated
   well-know entry point MTAs.  Each of these PRMD-level MTAs must be
   configured with routing and mapping information about each other to
   enable peer-to-peer PRMD routing.  These routing tables should be
   updated immediately upon the discovery of new/changed X.400
   connectivity information.  These tables will be made available to the
   ESnet community via the ESnet Information Server.  Once placed on-
   line, a notification message announcing the availability of this new
   routing information will be sent to every WEP owner via the E-mail
   mechanism described in Section 3.5.1.  It is recommended that WEP
   administrators should retrieve this new routing information and
   update their MTAs within 10 working days.

   The well-known entry point MTA for each PRMD can route down to an
   Organizational level MTA or laterally to the well-known entry point
   of a peer PRMD MTA.

   For example, the ESnet MTA would route a message with the address:

               /PN=Funk/OU=CS/O=PPPL/PRMD=ESnet/ADMD= /C=US/




ESCC X.500/X.400 Task Force                                    [Page 27]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   to a well-known entry point for PPPL (O=PPPL).  PPPL must own and
   operate their own X.400 MTA, and it must be configured to accept
   X.400 messages from the ESnet MTA.  Thus, the interpretation of
   remaining "/PN=Funk/OU=CS" is left to the PPPL MTA to route.

   Mail sent from PPPL's MTA would be routed to the ESnet's MTA (PRMD)
   to be eventually routed to its destination.

   The ESnet MTA will also route to peer MTAs which are well-known entry
   points for other PRMDs (e.g. ESnet backbone site PRMDs, XNREN, Hughes
   Air Craft, NASA, CDC).  For example, the ESnet MTA would route a
   message with the address:

                /PN=Smith/OU=MS/O=RL/PRMD=PNL/ADMD= /C=US/

   to a well-known entry point for PNL (PRMD=PNL).  PNL must own and
   operate their own X.400 MTA, and it must be configured to accept
   X.400 messages from the ESnet MTA (as well as possibly other PRMDs).
   Thus, the interpretation of the remaining "/PN=SMITH/OU=MS/O=RL" is
   left to the PNL MTA to route.

   Mail sent from PNL's MTA (PRMD) would be routed to the well-known
   entry point for the PRMD indicated in the destination address.

   Additionally, a site operated PRMD must be able to route mail to any
   other peer-PRMD within the ESnet community.

3.4.1.  Responsibilities in Operating an X.400 PRMD MTA

   If the X.400 world were to operate exactly as the standard
   recommends, PRMDs would only peer with other PRMDs when connectivity
   is available and traffic demand is sufficient, and would utilize ADMD
   services to reach all other PRMDs.  In reality, many PRMDs will not
   subscribe to an ADMD service and will only be reachable through PRMD
   peering.

   Most communities, such as the ESnet, desire the fullest PRMD
   interconnectivity possible to minimize the need for ADMD services.
   Community PRMD operational requirements stem from a policy of
   achieving large scale peering among PRMD operators within the
   community.

   Work is continuing in the IETF X.400 Operations Working Group to
   produce an RFC that specifies the operational requirements that must
   be implemented by X.400 Management Domains.  "Requirements for X.400
   Management Domains (MDs) Operating in the Global Research and
   Development X.400 Service", this document is listed in Appendix G.
   ESnet will comply with all the requirements outlined in this



ESCC X.500/X.400 Task Force                                    [Page 28]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   document.  It is the recommendation that all ESnet PRMDs follow the
   requirements specified in this document.

   As an overview, this document specifies that each PRMD will provide
   at least one WEP and that all PRMDs must be interconnected.  There
   are a number of PRMDs in the International X.400 service that have
   different communication stack requirements.  For example:

                          Stack 1     Stack 2     Stack 3     Stack 4
                          -------     -------     -------     -------
     Transport Layer 4        TP0         TP4    RFC-1006         TP0
     Network Service 1-3     X.25        CLNS      TCP/IP        CONS

   To meet the requirement that all PRMDs must be interconnected a PRMD
   must support one or more of the above stacks.  For stacks that are
   not supported the PRMD must negotiate with another PRMD or ADMD to
   relay messages to a Management Domain that does support the other
   stacks.

   The PRMD requirements also suggest that PRMDs support downgrading of
   X.400 1988 to X.400 1984.  Also, the PRMD must be reachable from the
   Internet Mail service.  This means the PRMD must maintain an Internet
   Mail/X.400 gateway.

   In all cases, members of the ESnet community who operate a PRMD
   should notify ESnet of the WEP and MTA information required to
   perform peering.

3.4.2.  Responsibilities in Operating an X.400 Organizational MTA

   ESnet will provide PRMD service to the ESnet community.  ESnet will
   peer with the other PRMDs in the International X.400 service and
   provide a WEP for the ESnet community.  An Organization/site needs to
   decide if they are going to comply with the above PRMD requirements
   or act as an organization associated to the ESnet PRMD.  Minimally,
   an organizational MTA will only have to support one of the protocol
   stacks provided by it associated PRMD.  But in all cases, the site
   will need to provide a WEP and register/list their MTA(s) with ESnet.

3.5.  Services Provided by ESnet

   ESnet will provide PRMD service to those members of the ESnet
   community who desire it.  ESnet will peer with other PRMDs in the
   International community (e.g. XNREN, Hughes Air Craft, NASA, CDC) and
   provide a WEP for the ESnet community; the intent is to provide the
   fullest PRMD level X.400 services.

   ESnet will deploy two, PRMD level, X.400 MTAs in geographically



ESCC X.500/X.400 Task Force                                    [Page 29]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   disperse locations.  These MTAs will be able to forward mail for
   directly connected ESnet backbone sites, as well as to and from the
   peered PRMDs.

3.5.1.  X.400 Operations Mailing List

   ESnet will provide an X.400 operations mailer for announcements and
   to allow the sharing of X.400 operational information in the ESnet
   community.

      General discussion:  x400-ops@es.net
      To subscribe:        x400-ops-request@es.net

3.5.2.  MTA Routing Table on ESnet Information Server

   ESnet will maintain forwarding information about ESnet community MTAs
   at the /PRMD=<PRMD> or /O=<organization> levels (depending on what
   level the site MTA is operating).  This information will be available
   for use in configuring directly connected ESnet site operated MTAs.
   This information will be made available in a machine independent
   format on the ESnet Information Server.

3.5.3.  MTA Routing Table Format

   The ESnet staff will determine the details of information format,
   update frequency, obtaining, and disseminating the information based
   on operational experience and constraints.

3.5.4.  Gateway Services and Multiprotocol Stack Support

   The ESnet MTAs will minimally support bidirectional SMTP-X.400 mail
   gateway capabilities, and will operate over the OSI CLNS protocol (as
   defined by GOSIP) and RFC-1006 stacks.  Configuration and operation
   of mail protocol gateway functions will be governed by the ESnet
   staff.

   Backbone site MTAs which service ORnames at the /O=<site> level under
   the ESnet PRMD must utilize one of the ESnet PRMD supported protocol
   stacks.  This requirement assures that all users of the ESnet PRMD
   will be able to communicate to one another via the ESnet PRMD MTA.

   Backbone site MTAs which service ORnames in PRMDs other than
   /PRMD=ESnet must utilize the OSI CLNS stack for GOSIP conformance.
   Use of the RFC-1006 stack is optional.  This requirement assures that
   all PRMDs in the ESnet community will be able to peer with the ESnet
   PRMD.





ESCC X.500/X.400 Task Force                                    [Page 30]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


3.5.5.  Registering/Listing your PRMD or Organizational MTA with ESnet

   To provide for the connection and routing requirements in X.400 you
   will need to register/list your MTA with ESnet.  This information
   will be maintained in tables on the ESnet Information Server.  ESnet
   will also maintain information on the International X.400 service.
   ESnet will use the same format for information as maintained by the
   International X.400 service.  This is described in detail in a IETF
   X.400 operations paper "Routing Coordination for X.400 MHS Services
   within a Multiprotocol/Multinetwork Environment".  This paper is a
   working draft, see Appendix G.  It describes a machine independent
   form for distribution of X.400 information.

   There are three tables that must be maintained and exchanged by the
   top level WEPS.

   1.  The Community Document

   2.  The WEP Document

   3.  The Domain Document

   ESnet will submit these documents to the International X.400
   community on behalf of the ESnet Community.  If an ESnet PRMD wishes
   to peer with the International PRMDs they will need to submit these
   documents to that community.

   The Community document is used to list the central coordination point
   and file server where all MHS documents will be stored.  It also
   lists the communication stacks used by the MHS community.  This
   document will be submitted to the International X.400 service by
   ESnet for the ESnet Community.  ESnet PRMDs and Organizations do not
   need to submit this form to ESnet.  If an ESnet PRMD wishes to peer
   with the International X.400 service then they must submit this form
   to that community.

   Each ESnet MHS domain will need to submit a WEP and Domain Document
   to ESnet.  The WEP document is used to list the WEPs used by an ESnet
   MHS domain.  It will contain all the information that is needed for
   MTA connection and access control.  ESnet will submit the ESnet
   community WEP and Domain Documents to the International X.400
   service.  The WEP document consists of a list of WEPs, with the
   following information for each one:

   o  The MTA Name

   o  Password




ESCC X.500/X.400 Task Force                                    [Page 31]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   o  Which MTS supported

   o  Which standard, 84 and/or 88

   o  Connection information outbound

   o  Connection information inbound

   o  Computer system information

   o  Point of contact

   The Domain Document specifies all the X.400 domains managed by a
   site.  It indicates the person responsible and which WEP services
   which Domain.  This document contains the following information
   repeated for each Domain:

   o  X.400 Domain

   o  Point of Contact

   o  Relaying WEP(s)

3.6.  X.400 Message Routing Between ADMDS and PRMDS

   While ESnet will provide X.400 routing service for systems, it cannot
   provide routing via commercial X.400 carriers at this time.  The
   FTS-2000 charge for routing X.400 messages is $.45 (US) plus X.25
   packet charges.  This could result in a charge of several dollars for
   large messages, a real possibility with the multi-media capacity of
   X.400.  The payment of this fee is not within the charter of ESnet
   and the provision of a charging mechanism to charge member sites is
   not currently contemplated.

3.7.  X.400 Registration Requirements

   It is recommended by the CCITT that all X.400 PRMD names be
   nationally unique.  This is a current CCITT agreement and allows
   direct PRMD-PRMD peer routing.  Since national uniqueness is
   required, registration should be performed through an appropriate
   registration authority (such as ANSI).

   X.400 organization names must be unique within a PRMD.  There is no
   need for national uniqueness.  Registration of an X.400 organization
   name should be conducted through the PRMD operator.

   The registration of X.400 names below the organization level are
   usually a local matter.  Uniqueness within the context of a superior



ESCC X.500/X.400 Task Force                                    [Page 32]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   name should always be maintained.

   See Section 4 for a more complete description of OSI registration
   issues and procedures.

3.8.  Future X.400 Issues to be Considered

3.8.1.  X.400 Mail Routing to International DOE Researchers

   Currently there are DOE researchers located in Switzerland, Japan,
   Germany, China and Brazil.  PRMD level connectivity to these
   international locations does not exist presently.  Since ESnet is not
   chartered to pay for commercial X.400 services on behalf of the ESnet
   community, "buying" this service is not a viable option.

   There are efforts taking place to provide international X.400 service
   over the (international) Internet.  Once this becomes fully
   operational, further research will have to be performed to see if
   this provides the X.400 connectivity needed to support the DOE
   researchers located abroad.

3.8.2.  X.400 (1984) and X.400 (1988)

   The ESnet MTAs will initially support the 1984 version of the X.400
   standard.  As the use of 1988 X.400 becomes more prevalent, support
   for the newer standard will need to be addressed.  One important
   point, once the ESnet MTAs become 1988 X.400 compliant, they will
   also have so support "downgrading" to 1984 X.400 to ensure reliable
   X.400 mail delivery to the ESnet community.

3.8.3.  X.400 Interaction with X.500

   This is discussed in Section 2.10.2.

4.  OSI Name Registration and Issues

   Implementing OSI services requires that certain information objects
   (e.g., people, information processing systems and applications) must
   be unambiguously identifiable on a global basis.  These objects may
   be defined by a variety of organizations, e.g., ISO/IEC, CCITT,
   commercial, and government.

   To meet this requirement ISO/IEC and CCITT have established a
   hierarchical structure of names (a tree).  The top level of the
   naming tree, shared by ISO and CCITT, represents the global naming-
   domain.  Naming domains are managed by registration authorities.  A
   registration authority can delegate authority for part of its
   naming-domain to another (lower level) registration authority, thus



ESCC X.500/X.400 Task Force                                    [Page 33]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   forming the tree.

   Each object can be given a unique and unambiguous name by registering
   the object's name with an OSI registration authority at an
   appropriate level in the naming tree.

   OSI name registration authorities and their procedures are expected
   to change over time.  Since names are intended to be stable, these
   changes (hopefully!) will have minimal impact on existing OSI name
   registrations.

   This section describes the role of OSI registration authorities, the
   difference between a "registration" and a "notification", and sources
   of nationally unique names.  Information about three OSI name
   registration authorities; the American National Standards Institute
   (ANSI), the General Services Administration (GSA), and the U.S.
   Department of Energy (U.S. DOE); are given.

   Registration of a name often requires stating a "right" to that name.
   However, an OSI name registration does not guarantee legal name
   rights. Name rights should be reviewed by legal experts prior to
   registration. Information about the U.S. Department of Commerce,
   Patent and Trademark Office (PTO) (potentially useful in asserting or
   defending name rights) is given below.

4.1.  Registration Authorities

   OSI names are obtained through OSI name registration authorities by a
   registration process.  The selection of which particular registration
   authority to use is determined by the desired level of the OSI name
   in the naming hierarchy, possible restrictions on the names allocated
   by each registration authority, and the applicability rules (will
   they service your request) of each registration authority.

   An OSI name registration authority allocates OSI names from the
   particular naming-domain it controls.  Every registration authority
   can trace its naming authority to its parent registration authority,
   and ultimately to the top (global) level of the naming hierarchy.

4.2.  Registration Versus Notification

   Registering an OSI name guarantees its uniqueness and lack of
   ambiguity. For a name to be useful however, other parties (besides
   the registration authority) will need to be notified of the name and
   its usage.

   There is a clear distinction between registration (obtaining an OSI
   name) and notification (informing others of a name and its use).



ESCC X.500/X.400 Task Force                                    [Page 34]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   Often the term "registration" is used to describe both activities,
   this is a potential source of confusion.

   For example, NADF and PSI (see Section 2) are not OSI registration
   authorities.  NADF may operate state registration authorities in the
   future, if delegated that administrative right by the states.  PSI
   operates an X.500 pilot project and needs to be notified of
   registered names when organizations join their pilot.

   X.400 ADMD operators are also not OSI registration authorities,
   although they accept notification of X.400 PRMD names used by their
   customers.

   The PTO is not an OSI registration authority.  PTO names have no
   meaning in an OSI context.

4.3.  Sources of Nationally Unique Name Registration

   There are four potential sources of nationally unique names which are
   of interest to the ESnet community.  These are ANSI, GSA, U.S. DOE
   and the states.  An overview of the ANSI, GSA, and U.S. DOE
   procedures are given in later sections.

   In order to maintain national uniqueness "constructed name syntax" is
   used by GSA, U.S. DOE, and the states.  The form of each name is
   shown below, "name" is the name presented to the registration
   authority for registration.

   1.  ANSI names are of the form "name".

   2.  GSA names are of the form "GOV+name".

   3.  U.S. DOE names are of the form "GOV+USDOE+name".

   4.  State names are of the form "CA+name" (using California).

   State name registration authorities are not in operation at this
   time.  The use of U.S. DOE as a nationally unique name registration
   source is not recommended due to the awkwardness of a double
   constructed name.

4.4.  How to Apply for ANSI Organization Names

   ANSI is the root U.S. source of OSI recognized nationally unique
   organization names.  ANSI registration costs $2500 and results in
   both an alphanumeric name and an associated numeric name.  These
   names may be used for a variety of purposes in X.400, X.500, and
   other OSI services.



ESCC X.500/X.400 Task Force                                    [Page 35]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   For ANSI OSI organization name registration forms and instructions,
   you should send your request to:

                American National Standards Institute, Inc.
                Attn:  Beth Somerville
                OSI Registration Coordinator
                11 West 42nd Street
                New York, NY   10036
                Phone:  (212) 642-4976

   ANSI registration procedures include a 90 day public review period
   during which name requests can be easily challenged.

   There is a mechanism to forward ANSI requests to the GSA, it is
   discussed in the GSA section below.

4.5.  How to Apply for GSA Organization Names

   GSA is the registration authority for government use of GOSIP, their
   registration services are free for federal government organizations.
   Names assigned by GSA always begin with the characters "GOV+" and are
   limited to 16 characters.  By agreement with ANSI, these GSA assigned
   names are national unique.

   For GSA OSI Organization Name registration forms and instructions,
   you should send your request to:

                  General Services Administration
                  Office of Telecommunications Services
                  Registration Services, Room 1221-L KBA
                  18th and F Streets, N.W.
                  Washington, D.C. 20405

4.5.1.  GSA Designated Agency Representatives

   When preparing the GSA registration form a designated agency
   representative must sign where it says "Registration Official Name
   and Signature".  GSA will refuse requests missing this signature.

   The GSA designated Agency Representative for the Department of Energy
   is:










ESCC X.500/X.400 Task Force                                    [Page 36]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


                    Steve Hackman
                    Electronics Engineer
                    U.S. Department of Energy
                    AD-241.3/GTN
                    Washington, D.C. 20585
                    Office Phone:  (301) 903-6111
                    Office FAX:    (301) 903-4125
                    E-Mail:  hackman@gosip.xosi.doe.gov

4.5.2.  Forwarding of ANSI Registrations to GSA

   ANSI registration requests can be forwarded automatically to the GSA.
   This is the equivalent of registering with both ANSI and GSA.  The
   result is two nationally unique OSI name registrations, "name" from
   ANSI and "GOV+name" from GSA.

   There is no GOSIP requirement for GSA registration but many feel the
   additional GSA registration may be useful.

   Assuming your organization is a federal government organization,
   answer the last three questions on the ANSI registration form as
   shown below:

   1.  Do you wish the information supplied in the request to remain
       confidential?  NO.

   2.  Do you wish to have your organization name registered with the
       U.S. GOSIP Registration Authority (a.k.a. GSA)?  YES.

   3.  Is your organization an organization of the Federal Government?
       YES.

   You must indicate on the application form the approval of the GSA
   designated agency representative (Steve Hackman).  He does not sign
   as "Signature of Requestor", but some notation of his approval must
   be attached or GSA will reject the forwarded application.

4.6.  How to Apply for U.S. DOE Organization Names

   ESnet sites are encouraged to review the DOE GOSIP procedures and
   guidelines in planning their GOSIP activities.  This document does
   not conflict with current DOE GOSIP policies.

   DOE can assign nationally unique names which are prefixed by the
   string "GOV+USDOE+".  Use of this name source is not recommended;
   there is no apparent advantage in using U.S. DOE over GSA as a source
   of nationally unique names.




ESCC X.500/X.400 Task Force                                    [Page 37]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   Copies of current U.S. DOE GOSIP policies, guidelines, and
   registration forms may be obtained through site DOE naming
   authorities or Steve Hackman.

4.7.  Why Apply for a Trademark with the PTO?

   Legal issues may arise concerning the rights to use a desired name.
   OSI name registrations are not intended to "legally protect" name
   usage rights; that is not their function.

   Consultation with legal experts concerning the rights to use a name
   being registered is strongly advised, this recommendation does not
   offer specific legal guidance.  Applying for a trademark may be
   considered as a means to assert or protect the rights to a name.

   Per the PTO trademark application instructions there may be several
   benefits in obtaining a trademark.

   o  The filing date of the application is a constructive date of
      first use of the mark in commerce (this gives registrant
      nationwide priority as of the date).

   o  The right to sue in Federal court for trademark infringement.

   o  Constructive notice of claim of ownership.

   o  Limited grounds for attacking a registration once it is five
      years old.

4.8.  How to Apply for a Trademark with the PTO

   You should obtain a trademark application and detailed instructions
   from the U.S. Department of Commerce, Patent and Trademark Office.
   This can be done by mailing your request to the address below, or
   calling the PTO at the phone number below:

                       U.S. Department of Commerce
                       Patent and Trademark Office
                       Washington, D.C.   20231
                       Phone:  (703) 557-INFO

   NOTE:  The following information is based on ESnet experience in
          filing for a trademark based on prior use.

   After you receive your application, you will need to perform the
   following steps.

   1.  Complete the written application form.  If you have more than



ESCC X.500/X.400 Task Force                                    [Page 38]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


       one name you are filing, you must complete a separate form for
       each name.

   2.  Provide a black-and-white drawing of the mark.  In the case
       where there is no artwork, only text, the text must be
       centered on the page in uppercase.

   3.  Provide a check in the amount of $175 (for each application)
       made payable to the Commissioner of Patents and Trademarks.

   4.  Provide three specimens showing actual use of the mark on or
       in connection with the goods or services.

   The class of goods/services associated with this trademark must be
   specified on the registration form.  The currently defined classes of
   services are:

                     35  Advertising and business.
                     36  Insurance and financial.
                     37  Construction and repair.
                     38  Communication.
                     39  Transportation and storage.
                     40  Material treatment.
                     41  Education and entertainment.
                     42  Miscellaneous.

   So, for example, there could be two (or more) "ESnet" trademarks,
   with each trademark associated with a different service class.  Thus,
   trademarks are not nationally unique.

   Before submitting your form, you should see if your trademark is
   already registered to someone else (for the service class you
   specified).  This is typically done by your legal department through
   the PTO Trademark Search Library.

   Since the PTO form is a legal document, you must involve your legal
   department and the documents may only be signed by someone who is a
   legally recognized representative of your organization.  For example,
   in applying for the service mark "ESnet", the "Applicant Name" was
   "The Regents of the University of California", and the legally
   recognized representative was Dr. John Nuckolls, the director of the
   Lawrence Livermore National Laboratory.

4.9.  Future Name Registration Issues to be Considered

4.9.1.  ANSI Registered ADMD and PRMD Names

   There are discussions in the ANSI and CCITT communities revolving



ESCC X.500/X.400 Task Force                                    [Page 39]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   around the idea of having a formal registration of all ADMD and PRMD
   Names (not just ANSI Organization Names).  The ideas being exchanged
   include having a separate ANSI national registry for these names, and
   having to pay a periodic "license" fee.  This is just in the idea
   discussion phase now, but it may impact the cost of ANSI ADMD and
   PRMD Name registration in the near future.

Glossary

AA - See ADMINISTRATIVE AUTHORITY.

ADDMD - See ADMINISTRATIVE DIRECTORY MANAGEMENT DOMAIN.

ADMD - See ADMINISTRATION MANAGEMENT DOMAIN.

ADMINISTRATION - An Administration denotes a public telecommunications
     administration or other organization offering public
     telecommunications services.

ADMINISTRATION MANAGEMENT DOMAIN - An Administrative Management Domain
     (ADMD) is a management domain managed by an Administration;
     generally one of the common carriers (e.g. AT&T, MCI, U.S. Sprint,
     etc.).

ADMINISTRATIVE AUTHORITY - An entity which has administrative control
     over all entries stored within a single Directory System Agent
     (DSA).

ADMINISTRATIVE DIRECTORY MANAGEMENT DOMAIN - An Administrative Directory
     Management Domain (ADDMD) is a Directory Management Domain (DMD)
     which is managed by an administration.

AE - See APPLICATION ENTITY.

ALIAS - An entry of the class "alias" containing information used to
     provide an alternative name for an object.

ANSI - The American National Standards Institute.  ANSI is the official
     representative of the United States to ISO.

AP - See APPLICATION PROCESS.

APPLICATION ENTITY - An application entity is the OSI portion of an
     Application Process (AP).

APPLICATION LAYER - The application layer is the portion of an OSI
     system ultimately responsible for managing communication between
     application processes (APs).



ESCC X.500/X.400 Task Force                                    [Page 40]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


APPLICATION PROCESS - An application process is an object executing in a
     real system (computer).

APPLICATION SERVICE ELEMENT - An application service element (ASE) is
     the building block of an application entity (AE).  Each AE consists
     of one or more service elements, as defined by its application
     context.

ASE - See APPLICATION SERVICE ELEMENT.

ATTRIBUTE - An attribute is the information of a particular type
     concerning an object and appearing in an entry describing that
     object in the Directory Information base (DIB).

ATTRIBUTE TYPE - An attribute type is that component of an attribute
     which indicates the class of information given by that attribute.

ATTRIBUTE VALUE - An attribute value is a particular instance of the
     class of information indicated by an attribute type.

BASE ATTRIBUTE SET - A minimum set of attributes whose values
     unambiguously identify a particular management domain.

BODY - The body of the IP-message is the information the user wishes to
     communicate.

CCITT - An international standards making organization specializing in
     international communications standards and chartered by the United
     Nations.  "CCITT" is a french acronym meaning the International
     Telephone and Telegraph Consultative Committee.

CHAINING - Chaining is a mode of interaction optionally used by a
     Directory System Agent (DSA) which cannot perform an operation
     itself.  The DSA chains by invoking the operation of another DSA
     and then relaying the outcome to the original requestor.

CLNP - The OSI Connectionless Network Protocol.  CLNP's use is required
     by GOSIP.

CONTENT - The piece of information that the originating User Agent (UA)
     wishes delivered to the recipient UA.  For inter-personal messaging
     (IPM) UAs, the content consists of either an IP message or an IPM-
     status-report.

COOPERATING USER AGENT - A User Agent (UA) that cooperates with another
     recipient's UA in order to facilitate the communication between
     originator and recipient.




ESCC X.500/X.400 Task Force                                    [Page 41]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


DAP - See DIRECTORY ACCESS PROTOCOL.

DELIVERY - The interaction by which the Message Transfer Agent (MTA)
     transfers to a recipient User Agent (UA) the content of a message
     plus the delivery envelope.

DELIVERY ENVELOPE - The envelope which contains the information related
     to the delivery of the message.

DESCRIPTIVE NAME - A name that denotes one and only one user in the
     Message Handling System (MHS).

DIB - See DIRECTORY INFORMATION BASE.

DIRECTORY - The Directory is a repository of information about objects
     and which provides directory services to its users which allow
     access to the information.

DIRECTORY ACCESS PROTOCOL - The Directory Access Protocol (DAP) is the
     protocol used between a Directory user Agent (DUA) and a Directory
     System Agent (DSA).

DIRECTORY ENTRY - A Directory Entry is a part of the Directory
     Information Base (DIB) which contains information about an object.

DIRECTORY INFORMATION BASE - The Directory Information Base (DIB) is the
     complete set of information to which the Directory provides access
     and which includes all pieces of information which can be read or
     manipulated using the operations of the Directory.

DIRECTORY INFORMATION TREE - The Directory Information Tree (DIT) is the
     Directory Information Base (DIB), considered as a tree, whose
     vertices (other than the root) are the Directory entries.

DIRECTORY MANAGEMENT DOMAIN - A Directory Management Domain (DMD) is a
     collection of one or more Directory System Agents (DSAs) and zero
     or more Directory User Agents (DUAs) which is managed by a single
     organization.

DIRECTORY SYSTEM AGENT - A Directory System Agent (DSA) is an OSI
     application process which is part of the Directory.

DIRECTORY SYSTEM PROTOCOL - The Directory System Protocol (DSP) is the
     protocol used between two Directory System Agents (DSAs).

DIRECTORY USER - A Directory user is the entity or person that accesses
     the Directory.




ESCC X.500/X.400 Task Force                                    [Page 42]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


DIRECTORY USER AGENT - A Directory User Agent (DUA) is an OSI
     application process which represents the user in accessing the
     Directory.

DISTINGUISHED NAME - The distinguished name of a given object is the
     sequence of relative distinguished names (RDNs) of an entry which
     represents the object and those of all of its superior entries (in
     descending order).

DIT - See DIRECTORY INFORMATION TREE.

DMD - See DIRECTORY MANAGEMENT DOMAIN.

DN - See DISTINGUISHED NAME.

DNS - See DOMAIN NAME SERVICE.

DOMAIN NAME SERVICE - A hierarchical, distributed naming service
     currently used in the Internet.  DNS names typically take the form
     of <machine.site.domain>, where <.domain> may be ".COM", ".EDU",
     ".GOV", ".MIL", ".NET", ".ORG" or ".<country-code>".

DSA - See DIRECTORY SYSTEM AGENT.

DSP - See DIRECTORY SYSTEM PROTOCOL.

DUA - See DIRECTORY USER AGENT.

ENCODED INFORMATION TYPE - It is the code and format of information that
     appears in the body of an IP-message (examples of coded information
     types are Telex, TIFO (Group 4 Facsimile), and voice).

ENVELOPE - A place in which the information to be used in the
     submission, delivery and relaying of a message is contained.

FIPS - Federal Information Processing Standard.  FIPS are produced by
     NIST and specify a standard for the federal government, most FIPS
     reference other formal standards from ANSI, IEEE, ISO or CCITT.

GOSIP - The Government Open System Interconnection (OSI) Profile.  GOSIP
     is a FIPS which defines the elements of OSI to be required by
     government purchasers and how those elements should be implemented.
     GOSIP is based on OSI standards and OIW implementor's agreements.

HEADING - The heading of an IP-message is the control information that
     characterizes an IP-message.

INTERPERSONAL MESSAGING - Interpersonal Messaging (IPM) is communication



ESCC X.500/X.400 Task Force                                    [Page 43]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


     between persons by exchanging messages.

INTERPERSONAL MESSAGING SERVICE - The set of service elements which
     enable users to exchange interpersonal messages.

INTERPERSONAL MESSAGING SYSTEM - An Interpersonal Messaging System
     (IPMS) is the collection of User Agents (UAs) and Message Transfer
     Agents (MTAs), which provide the Interpersonal Messaging Service.

IP - A non-OSI network protocol, the Internet Protocol, used extensively
     in the Internet.  CLNP is the OSI alternative to IP.

IP-MESSAGE - An IP-message carries information generated by and
     transferred between Interpersonal Messaging (IPM) User Agents
     (UAs).  An IP-message contains a Heading and a Body.

IPM - See INTERPERSONAL MESSAGING.

IPM-STATUS-REPORT - The pieces of information generated by an
     Interpersonal Messaging (IPM) User Agent Entity (UAE) and
     transferred to another IPM UAE, either to be used by that UAE or to
     be conveyed to the user.

IPMS - See INTERPERSONAL MESSAGING SYSTEM.

ISO - An international standards making organization which, among other
     things, develops OSI standards.

MANAGEMENT DOMAIN - The set of Message Handling System (MHS) entities
     managed by an Administration or organization that includes at least
     one Message Transfer Agent (MTA).

MD - See MANAGEMENT DOMAIN.

MESSAGE - In the context of Message Handling Systems (MHSs), the unit of
     information transferred by the Message Transfer System (MTS).  It
     consists of an envelope and a content.

MESSAGE HANDLING ADDRESS - An Originator/Recipient (O/R) address which
     is comprised of an Administrative Management Domain (ADMD), a
     country name, and a set of user attributes.

MESSAGE HANDLING SYSTEM - The set of User Agents (UAs) plus the Message
     Transfer System (MTS).

MESSAGE TRANSFER AGENT - The functional component that, together with
     the other Message Transfer Agents (MTAs), constitutes the Message
     Transfer System (MTS).  The MTAs provide message transfer service



ESCC X.500/X.400 Task Force                                    [Page 44]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


     elements by:  (1) interacting with originating User Agents (UAs)
     via the submission dialogue, (2) relaying messages to other MTAs
     based upon recipient designations, and (3) interacting with
     recipient UAs via the delivery dialogue.

MESSAGE TRANSFER AGENT ENTITY - The Message Transfer Agent Entity (MTAE)
     is an entity, located in an MTA, that is responsible for
     controlling the Message Transfer Layer (MTL).  It controls the
     operation of the protocol to other peer entities in the MTL.

MESSAGE TRANSFER LAYER - The Message Transfer Layer (MTL) is a layer in
     the Application layer that provides Message Transfer System (MTS)
     service elements.  These services are provided by means of the
     services of the layer below plus the functionality of the entities
     in the layer, namely the Message Transfer Agent Entities (MTAEs)
     and the Submission and Delivery Entities (SDEs).

MESSAGE TRANSFER PROTOCOL - The Message Transfer Protocol (P1) is the
     protocol which defines the relaying of messages between Message
     Transfer Agents (MTAs) and other interactions necessary to provide
     Message Transfer layer (MTL) services.

MESSAGE TRANSFER SERVICE - The Message Transfer Service is the set of
     optional service elements provided by the Message Transfer System
     (MTS).

MESSAGE TRANSFER SYSTEM - The Message Transfer System (MTS) is the
     collection of Message Transfer Agents (MTAs), which provide the
     Message Transfer Service elements.

MHS - See MESSAGE HANDLING SYSTEM.

MTA - See MESSAGE TRANSFER AGENT.

MTAE - See MESSAGE TRANSFER AGENT ENTITY.

MTL - See MESSAGE TRANSFER LAYER.

MTS - See MESSAGE TRANSFER SYSTEM.

MULTICASTING - Multicasting is a mode of interaction which may
     optionally be used by a Directory System Agent (DSA) which cannot
     perform an operation itself.  The DSA multicasts the operation
     (i.e. it invokes the operation of several other DSAs (in series or
     in parallel) and passes an appropriate outcome to the original
     requestor).

NAME - A name is a construct that singles out a particular object from



ESCC X.500/X.400 Task Force                                    [Page 45]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


     all other objects.  A name must be unambiguous (i.e. denote just
     one object); however, it need not be unique (i.e. be the only name
     which unambiguously denotes the object).

NIST - The national institute of standards, a government organization
     which develops, endorses, and promulgates standards for use by the
     U.S.  government.

O/R ADDRESS - See ORIGINATOR/RECIPIENT ADDRESS.

O/R NAME - See ORIGINATOR/RECIPIENT NAME.

OBJECT (OF INTEREST) - Anything in some "world", generally the world of
     telecommunications and information processing or some part thereof,
     which is identifiable (i.e. can be named), and which it is of
     interest to hold information on in the Directory Information Base
     (DIB).

OIW - The OSI Implementors workshop.  OIW is one of three regional
     workshops (OIW, EWOS, AOW), which specifies implementation
     agreements for base OSI standards.  OIW's participants are mostly
     from the Americas and the OIW is jointly sponsored by the IEEE
     (Institute of Electrical and Electronic Engineers) and NIST.

OPEN SYSTEMS INTERCONNECTION - A term referring to the capability of
     interconnecting different systems.

ORIGINATING USER AGENT - The Originating User Agent (UA) is a UA that
     submits to the Message Transfer System (MTS) a message to be
     transferred.

ORIGINATOR - A user, a human being or computer process, from whom the
     Message Handling System (MHS) accepts a message.

ORIGINATOR/RECIPIENT ADDRESS - A descriptive name for a User Agent (UA)
     that contains certain characteristics which help the Message
     Transfer System (MTS) to locate the UA's point of attachment.  An
     Originator/Recipient (O/R) address is a type of O/R name.

ORIGINATOR/RECIPIENT NAME - The Originator/Recipient Name (O/R Name) is
     the descriptive name for a User Agent (UA).

OSI - See OPEN SYSTEMS INTERCONNECTION.

PRDMD - See PRIVATE DIRECTORY MANAGEMENT DOMAIN.

PRIMITIVE NAME - A name assigned by a naming authority.  Primitive names
     are components of descriptive names.



ESCC X.500/X.400 Task Force                                    [Page 46]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


PRIVATE DIRECTORY MANAGEMENT DOMAIN - A Private Directory Management
     Domain (PRDMD) is a Directory Management Domain which is managed by
     an organization other than an administration.

PRIVATE MANAGEMENT DOMAIN - A Private Management Domain (PRMD) is a
     management domain managed by a company or non-commercial
     organization.

PRMD - See PRIVATE MANAGEMENT DOMAIN.

RDN - See RELATIVE DISTINGUISHED NAME.

RECIPIENT - A user, a human being or computer process, who receives a
     message from the Message Handling System (MHS).

RECIPIENT USER AGENT - A User Agent (UA) to which a message is delivered
     or that is specified for delivery.

REFERRAL - A referral is an outcome which can be returned by a Directory
     System Agent (DSA) which cannot perform an operation itself, and
     which identifies one or more other DSAs more able to perform the
     operation.

RELATIVE DISTINGUISHED NAME - A Relative Distinguished Name (RDN) is a
     set of attribute value assertions, each of which is true,
     concerning the distinguished values of a particular entry.

RELAYING - The interaction by which one Message Transfer Agent (MTA)
     transfers to another MTA the content of a message plus the relaying
     envelope.

RELAYING ENVELOPE - The envelope which contains the information related
     to the operation of the Message Transfer System (MTS) plus the
     service elements requested by the originating User Agent (UA).

RFC - Request for Comments.  The RFC's are documents used to propose or
     specify internet community standards.

ROOT - The vertex that is not the final vertex of any arc is referred to
     as the root vertex (or informally as the root) of the tree.

SCHEMA - The Directory Schema is the set of rules and constraints
     concerning the Directory Information Tree (DIT) structure, object
     class definitions, attribute types, and syntaxes which characterize
     the Directory Information base (DIB).

SDE - See SUBMISSION AND DELIVERY ENTITY.




ESCC X.500/X.400 Task Force                                    [Page 47]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


SMTP - Simple Mail Transfer Protocol.  An e-mail protocol frequently
     used by the Internet community.

SUBMISSION - The interaction by which an originating User Agent (UA)
     transfers to a Message Transfer Agent (MTA) the contents of a
     message plus the submission envelope.

SUBMISSION AND DELIVERY ENTITY - The Submission and Delivery Entity
     (SDE) is an entity located in the Message Transfer Layer (MTL),
     co-resident with a User Agent (UA) and not with a Message Transfer
     Agent (MTA), and responsible for controlling the submission and
     delivery interactions with a Message Transfer Agent Entity (MTAE).

SUBMISSION AND DELIVERY PROTOCOL - The Submission and Delivery Protocol
     (P3) is the protocol which governs communication between a
     Submission and Delivery Entity (SDE) and a Message Transfer Agent
     Entity (MTAE).

SUBMISSION ENVELOPE - The envelope which contains the information the
     Message Transfer System (MTS) requires to provide the requested
     service elements.

TCP - A non-OSI transport protocol, the Transmission Control Protocol,
     used extensively in the Internet.  TP4 is the OSI alternative to
     TCP.

TP0 - An OSI transport protocol specified by GOSIP and generally used
     with connection-oriented networks.

TP4 - An OSI transport protocol specified by GOSIP and generally used
     with connectionless networks such as CLNP.

TREE - A tree is a set of points (vertices), and a set of directed lines
     (arcs); each arc leads from a vertex V to a vertex V'.  The
     vertices V and V' are said to be the initial and final vertices of
     an arc a from V to V'.  In a tree, several different arcs may have
     the same initial vertex, but not the same final vertex.

UA - See USER AGENT.

UAE - See USER AGENT ENTITY.

UAL - See USER AGENT LAYER.

USER - A person or computer application or process who makes use of a
     Message Handling System (MHS).

USER AGENT - Typically, the User Agent (UA) is a set of computer



ESCC X.500/X.400 Task Force                                    [Page 48]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


     processes (for example, an editor, a file system, a word processor)
     that are used to create, inspect, and manage the storage of
     messages.  There is typically one user per User Agent (UA).  During
     message preparation, the originator communicates with his UA via an
     input/output (I/O) device (for example, a keyboard, display,
     printer, facsimile machine, and/or telephone).  Also by means of
     these devices, the UA communicates to its user messages received
     from the Message Transfer System (MTS).  To send and receive
     messages, the UA interacts with the MTS via the submission and
     delivery protocol.

USER AGENT ENTITY - A User Agent Entity (UAE) is an entity in the User
     Agent Layer (UAL) of the Application Layer that controls the
     protocol associated with cooperating UAL services.  It exchanges
     control information with the Message Transfer Agent Entity (MTAE)
     or the Submission and Delivery Entity (SDE) in the layer below.
     The control information is the information the Message Transfer
     layer (MTL) requires to create the appropriate envelope and thus
     provide the desired message transfer service elements.

USER AGENT LAYER - The User Agent Layer (UAL) is the layer that contains
     the User Agent Entities (UAEs).

X.25 - A packet switched network standard often used by public providers
     and optional in GOSIP.

Appendix A:  Current Activities in X.500

   NOTE:  The following are edited excerpts from the IETF Directory
   Services Monthly reports as well as a few IETF scope documents.
   Effort has been taken to make sure this information is current as of
   late 1991.  At the end of each section are lists of anonymous FTP
   and/or an e-mail address if more information is desired.

                                 IETF DISI
       (Directory Information Services Infrastructure Working Group)

   The Directory Information Services (pilot) Infrastructure Working
   Group is chartered to facilitate the deployment in the Internet of
   Directory Services based on implementations of the X.500 standards.
   It will facilitate this deployment by producing informational RFCs
   intended to serve as a Directory Services "Administrator's Guide".
   These RFCs will relate the current usage and scope of the X.500
   standard and Directory Services in North America and the world, and
   will contain information on the procurement, installation, and
   operation of various implementations of the X.500 standard.  As the
   various implementations of the X.500 standard work equally well over
   TCP/IP and CLNP, the DISI working group shall not mandate specific



ESCC X.500/X.400 Task Force                                    [Page 49]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   implementations or transport protocols.

   DISI is an offshoot of the OSI Directory Services group, and,
   accordingly, is a combined effort of the OSI Integration Area and
   User Services Area of the IETF.  The current OSIDS working group was
   chartered to smooth out technical differences in information storage
   schema and difficulties in the interoperability and coherence of
   various X.500 implementations.  The DISI group is concerned solely
   with expanding the Directory Services infrastructure.  As DISI will
   be providing information to facilitate the building of infrastructure
   with an eye towards truly operational status, DISI will need to form
   liaisons with COSINE, PARADISE, and perhaps the RARE WG3.

   As a final document, the DISI working group shall write a charter for
   a new working group concerned with user services, integration,
   maintenance and operations of Directory Services, the Operations and
   Infrastructure of Directory Services (OIDS) Group.

   One particular DISI document you may be interested in is a catalogue
   of the various X.500 implementations:

      Title     : Catalog of Available X.500 Implementations
      Author(s) : R. Lang, R. Wright
      Filename  : rfc1292.txt
      Pages     : 103

   This document is available on the ESnet Information Server in the
   [ANONYMOUS.RFCS] directory.

   Mailing list address:
      General Discussion:  disi@merit.edu
      To Subscribe:        disi-request@merit.edu
   Anonymous FTP site address:  (e-mail archive is here)
      merit.edu

             IETF OSI-DS (OSI Directory Service Working Group)

   The OSI-DS group works on issues relating to building an OSI
   Directory Service using X.500 and its deployment on the Internet.
   Whilst this group is not directly concerned with piloting, the focus
   is practical, and technical work needed as a pre-requisite to
   deployment of an open Directory will be considered.

   The major goal of this WG is to provide the technical framework for a
   Directory Service infrastructure on the Internet.  This
   infrastructure should be based on the OSI Directory (X.500).  It is
   intended that this infrastructure can be used by many applications.
   Whilst this WG is not directly concerned with operation of services,



ESCC X.500/X.400 Task Force                                    [Page 50]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   close liaison is expected with those groups which do operate pilots
   and services.

   Liaisons have been established with RARE WG3, NIST, CCITT/ISO IEC,
   North American Directory Forum.

   X.500 (1984) / ISO 9594 does not have sufficient functionality for
   full deployment on the Internet.  This group identifies areas where
   extensions are required.

   It is a basic aim of the group to be aligned to appropriate base
   standards and functional standards.  Any activity should be
   undertaken in the light of ongoing standardization activity.  Areas
   which should be examined include:

   o  Replication

   o  Knowledge Representation

   o  Schema Management

   o  Access Control

   o  Authentication

   o  Distributed operations for partially connected DSAs

   o  Presentation Address Handling

   Mailing list address:
      General Discussion:  osi-ds@cs.ucl.ac.uk
      To Subscribe:        osi-ds-request@cs.ucl.ac.uk
   Anonymous FTP site address:  (all OSI-DS documents and e-mail archive
      cs.ucl.ac.uk               are here)

                   FOX (Field Operational X.500 Project)

   The FOX project is a DARPA funded effort to provide a basis for
   operational X.500 deployment in the NREN/Internet.  This work is
   being carried out at Merit, NYSERnet/PSI, SRI and ISI.  ISI is the
   main contractor and responsible for project oversight.

   There are two primary thrusts of the FOX project:

   1.  X.500 Infrastructure:  It is important that multiple
       interoperable platforms be available for deployment.  FOX
       plans to examine and test the interoperability of the QUIPU
       and NIST-X.500 (Custos) implementations, and DNANS-X.500 if



ESCC X.500/X.400 Task Force                                    [Page 51]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


       possible.  In addition, FOX will explore X.500 interfaces to
       conventional database systems (one target is Sybase), an
       alternate OS platform (VM) for X.500 servers, and X-window
       based user interfaces.

   2.  X.500 Applications:  A long-range goal is to facilitate the
       use of X.500 for real Internet applications.  FOX will first
       focus on making network infrastructure information available
       through X.500.  This includes network and AS site contacts,
       topology information, and the NIC WHOIS service.

   A centrally managed X.500 version will be the first phase of a WHOIS
   service.  Providing an X.500 version of a well-known widely-used
   service should promote the use of X.500 by Internet users.  In
   addition, this effort will provide experience in designing X.500
   applications.  However, the manageability of this scheme will be
   short-lived, so the next step will be a design for a distributed
   version of WHOIS.

   Finally, it is critical for Internet X.500 efforts to be aligned with
   directory service efforts that are ongoing in other communities.  FOX
   participants are involved in, or are otherwise tracking these
   efforts, and information about FOX activities will be publicly
   available.

                   NADF (North American Directory Forum)

   The North American Directory Forum (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.

   The NADF has produced a document, NADF-175, "A Naming Scheme for
   c=US", which has been issued as RFC-1255.

   The NADF-175 document proposes the use of existing civil
   infrastructure for naming objects under c=US.  This has the advantage
   of using existing registration authorities and not establishing any
   new ones (the document simply maps names assigned by existing
   authorities into different portions of the c=US DIT).  The document
   is intended as the basis for X.500 names in the U.S. for the long-
   term; it is important that interested parties get a copy, review it,
   and return comments.

   A second output, which is still undergoing development, is NADF-128,
   a preliminary draft on "Mapping the DIT onto Multiple ADDMDs".  This
   describes how the c=US portion of the DIT is mapped onto DSAs and
   what service-providers must minimally share in order to achieve a
   working public directory.  The next revision of this document will



ESCC X.500/X.400 Task Force                                    [Page 52]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   likely be ASCII-ized and published as an informational RFC.

           NIST (National Institute of Standards and Technology)

   NIST is involved in several X.500 activities:  standards, pilot
   deployment, and development of an X.500 implementation, Custos.  The
   objective is to see X.500 widely deployed and used in the U.S.
   Government.  X.500 is expected to be in the next release of the U.S.
   Government OSI Profile (GOSIP).  In the standards efforts, emphasis
   is on access control and replication; the other activities are
   described in some detail below.

   o  NIST/GSA X.500 Pilot Deployment:  NIST and GSA are
      collaborating in the creation of a U.S. Government X.500 pilot
      deployment.  To date, two meetings have been held.  At the
      second, held on April 25th at NIST, significant progress was
      made towards refining an initial draft schema developed by
      NIST.  A number of government agency requirements will be
      included in the next schema revision.  Once the schema is
      defined, agencies will begin collecting data for loading into
      the directory.  Initially, NIST will offer to host agency data
      on Custos DSAs running at NIST.  Eventually, agencies are
      expected to obtain and operate DSAs.

   o  CUSTOS:  The NIST X.500 public-domain implementation, Custos,
      is implemented on ISODE, although it otherwise bears no
      relation to QUIPU.  One of its more interesting features is that
      the DBMS interface is SQL, and we provide a simple DBMS as part
      of Custos to support the DSA.  Information can be optionally
      loaded into memory, and the memory usage is reasonably
      efficient on a per-entry basis.

                     OIW (OSI Implementor's Workshop)

   The OSI Implementor's Workshop (OIW) is an open public forum for
   technical issues, concerned with the timely development of
   implementation agreements based on emerging international OSI
   standards.  The Workshop accepts as input the specifications of
   emerging standards for protocols, and produces as output agreements
   on the implementation and testing particulars of these protocols.
   This process is expected to expedite the development of OSI protocols
   and to promote interoperability of independently manufactured data
   communications equipment.

   The Workshop organizes its work through Special Interest Groups
   (SIGs) that prepare technical documentation.  The SIGs are encouraged
   to coordinate with standards organizations and user groups, and to
   seek widespread technical consensus on implementation agreements



ESCC X.500/X.400 Task Force                                    [Page 53]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   through international discussions and liaison activities.

   The Directory SIG of the Workshop produces agreements on the
   implementation of Directory protocols based on ISO 9594 and CCITT
   X.500 Recommendations.  There are three major areas that the SIG is
   working on for 1991:  access control, replication, and distributed
   operations.

   Mailing list address:
      General Discussion:  dssig@nisc.sri.com
      To Subscribe:        dssig-request@nisc.sri.com

                             PARADISE Project

   The PARADISE project is based at the Department of Computer Science,
   University College London (UCL).

   PARADISE is a sub-project of the broader COSINE project sponsored
   under the umbrella of EUREKA by eighteen participating countries and
   aimed at promoting OSI to the academic, industrial and governmental
   research and development organizations in Europe.  The countries
   involved are those of the EC, EFTA plus Yugoslavia; that is:
   Austria, Belgium, Denmark, Finland, France, Germany, Greece, Holland,
   Ireland, Italy, Luxembourg, Norway, Portugal, Spain, Sweden,
   Switzerland, United Kingdom, and Yugoslavia.

   The partners funded by PARADISE besides UCL are:

   o  The Networks Group at the University of London Computer Centre
      (ULCC), which is a service-oriented organization providing a
      range of facilities to the academic community in London and the
      entry point into the UK for IXI, the COSINE international X.25
      backbone;

   o  X-Tel Services Ltd, a software company based in Nottingham
      which currently provides service support to the UK Academic
      X.500 pilot; and

   o  PTT Telematic Systems from the Netherlands, which in turn has
      subcontracted the Swiss and Finnish PTTs, and whose involvement
      is to create a forum for discussion on X.500 among the European
      carrier administrations.

   The project also aims to have representation from all the
   participating countries, which in the majority of cases are the
   existing X.500 national pilots.

   Of the 18 countries involved, at least 12 are registered in the White



ESCC X.500/X.400 Task Force                                    [Page 54]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   Pages Pilot Project.  Most countries are using the QUIPU
   implementation developed at UCL.  However, a French group has
   developed PIZARRO, which will form the basis of the emerging French
   pilot.  In Italy, a Torino-based company Systems Wizards are using
   DirWiz, which is currently the sole representative from Italy in the
   tree.

   Mailing list address:
      helpdesk@paradise.ulcc.ac.uk

                       PSI White Pages Pilot Project

   The White Pages Pilot Project is the first production-quality field
   test of the OSI Directory (X.500).  The pilot currently has a few
   hundred organizations (more each month) and is based on OSI TP4 over
   TCP/IP (RFC-1006).

   Anonymous FTP site address:  (Most X.500 pilot project software is
      uu.psi.com                 here as well as more information)

                 ANSI ASC X3T5.4 (Directory Ad Hoc Group)

   The American National Standards Institute (ANSI) Accredited Standards
   Committee (ASC) X3T5.4.  This group reviews the Proposed Draft
   Amendments (PDAMs) for extensions to the International Consultative
   Committee for Telegraphy and Telephony (CCITT) X.500
   Recommendations/International Organization for Standardization
   (ISO)/International Electrotechnical Commission (IEC) 9594.

Appendix B:  Current Activities in X.400

   NOTE:  The following are edited excerpts from the IETF X.400 Services
   Monthly reports as well as a few IETF scope documents.  Effort has
   been taken to make sure this information is current as of February
   1992.  At the end of each section are lists of anonymous FTP and/or
   an e-mail address if more information is desired.

                IETF OSIX400 (IETF OSI X.400 Working Group)

   The IETF OSI X.400 Working Group is chartered to identify and provide
   solutions for problems encountered when operating X.400 in a dual
   protocol internet.  This charter includes pure X.400 operational
   issues as well as X.400 <-> RFC 822 gateway (ala RFC 987) issues.

   Mailing list address:
      General Discussion:  ietf-osi-x400@cs.wisc.edu
      To Subscribe:        ietf-osi-x400-request@cs.wisc.edu




ESCC X.500/X.400 Task Force                                    [Page 55]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


            IETF X400OPS (IETF X.400 Operations Working Group)

   X.400 management domains are being deployed today on the Internet.
   There is a need for coordination of the various efforts to insure
   that they can interoperate and collectively provide an Internet-wide
   X.400 message transfer service connected to the existing Internet
   mail service.  The overall goal of this group is to insure
   interoperability between Internet X.400 management domains and to the
   existing Internet mail service.  The specific task of this group is
   to produce a document that specifies the requirements and conventions
   of operational Internet PRMDs.

   Mailing list address:
      General Discussion:  ietf-osi-x400ops@pilot.cs.wisc.edu
      To Subscribe:        ietf-osi-x400ops-request@pilot.cs.wisc.edu

     IETF MHS-DS (IETF Message Handling Services - Directory Services)

   The MHS-DS Group works on issues relating to Message Handling Service
   use of Directory Services.  The Message Handling Services are
   primarily X.400, but issues relating to RFC 822 and RFC 822
   interworking, in as far as use of the Directory is concerned, are in
   the scope of the Group.  Directory Services means the services based
   on X.500 as specified by the OSI-DS group (RFCs 1274, 1275, 1276,
   1277, 1278, 1297).  The major aim of this group is to define a set of
   specifications to enable effective large scale deployment of X.400.
   While this Group is not directly concerned with piloting, the focus
   is practical, and implementations of this work by members of the
   Group is expected.

   Mailing list address:
      General Discussion:  mhs-ds@mercury.udev.cdc.com
      To Subscribe:        mhs-ds-request@mercury.udev.cdc.com
   Anonymous FTP site address:  (e-mail archive is here)
      mercury.udev.cdc.com

                         XNREN X.400 Pilot Project

   The Internet X.400 Project at the University of Wisconsin is funded
   by NSF.  We are working on two main areas:

   1.  Supporting the operational use of X.400.

   2.  Working with others to define organizational procedures
       necessary to operate X.400 on a large scale in the Internet.

   To support the use of X.400, we are operating a PRMD, assisting sites
   in running PP or the Wisconsin Argo X.400 software packages, and



ESCC X.500/X.400 Task Force                                    [Page 56]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   running an X.400 Message Transfer Agent (MTA) which is connected to
   U.S. and international MTAs using RFC1006/TCP/IP.  Internet sites are
   invited to join our PRMD or establish X.400 connections with us.  The
   organizational work is being done jointly by IETF working groups and
   RARE Working Group 1.

   Mailing list address:
      General Discussion:  x400-project-team@cs.wisc.edu

        RARE WG1 (RARE Working Group 1 - Message Handling Systems)

   RARE (Reseaux Associes pour la Recherche Europeenne) Working Group 1,
   Message Handling Systems, creates and promotes a European
   infrastructure for a message handling service within the European
   research community, with connections to the global environment.
   Membership of the Working Group is by nomination from the national
   networking organizations, together with a number of invited experts.

      CCITT SG-D MHS-MD (CCITT Study Group D, MHS Management Domains)

   This group initially pursues the  development of  the  rules for
   registering MHS management Domain names within the US.  This group
   also pursues developing  a set of voluntary agreements for North
   American operators of these management  domains  which  will  allow
   the  US  to uphold  its Telecommunications   treaty   obligations
   while   the industry maintains  e-mail  as  an  Information
   Processing  service.  The specific  aspect  of the treaty that is
   immediate concern to this group is that subscribers of MHS  services
   in  other  countries, especially  those countries who treat MHS as a
   Telecommunications service, must  be  able  to reach  MHS  users  in
   this  country regardless  of  how their message enters the US and
   regardless of how many domains are involved in the transfer of the
   message  to the intended recipient.

   The US State Department presently considers MHS  (e-mail)  as  an
   Information  Processing  service.  Some other countries consider any
   MHS (e-mail) service  to  be  a Telecommunications  service  and
   hence, CCITT treaty obligations apply.

              NIST/GSA Interagency X.400 Connectivity Project

   The goal of this project is to assist the members of the Federal
   Information Resource Management Policy Council (FIRMPoC) in
   establishing electronic mail connectivity based on X.400.  The
   outcome of this project is to continue, as the National Institute of
   Standards and Technology (NIST) has done in the past, providing
   Federal agencies with assistance in establishing electronic mail
   connectivity.  This project is sponsored by the General Services



ESCC X.500/X.400 Task Force                                    [Page 57]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   Administration (GSA).

Appendix C:  How to Obtain QUIPU, PP and ISODE

                              ISODE/QUIPU 7.0

   This software supports the development of certain kinds of OSI
   protocols and applications.  Here are the details:

   o  The ISODE is not proprietary, but it is not in the public
      domain.  This was necessary to include a "hold harmless"
      clause in the release.  The upshot of all this is that anyone
      can get a copy of the release and do anything they want with
      it, but no one takes any responsibility whatsoever for any
      (mis)use.

   o  The ISODE runs on native Berkeley (4.2, 4.3) and AT&T System V
      systems, in addition to various other UNIX-like operating
      systems.  No kernel modifications are required.

   o  Current modules include:

      -  OSI transport service (TP0 on top of TCP, X.25 and CONS;
         TP4 for SunLink OSI)

      -  OSI session, presentation, and association control services

      -  ASN.1 abstract syntax/transfer notation tools, including:

         1.  Remote operations stub-generator (front-end for remote
             operations)

         2.  Structure-generator (ASN.1 to C)

         3.  Element-parser (basic encoding rules)

      -  OSI reliable transfer and remote operations services

      -  OSI directory services

      -  OSI file transfer, access and management

      -  FTAM/FTP gateway

      -  OSI virtual terminal (basic class, TELNET profile)

   o  ISODE 7.0 consists of final "IS" level implementations with the
      exception of VT which is a DIS implementation.  The ISODE also



ESCC X.500/X.400 Task Force                                    [Page 58]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


      contains implementations of the 1984 X.400 versions of ROS and
      RTS.

   o  Although the ISODE is not "supported" per se, it does have a
      problem reporting address, Bug-ISODE@XTEL.CO.UK.  Bug reports
      (and fixes) are welcome by the way.

   o  The discussion group ISODE@NISC.SRI.COM is used as an open
      forum on ISODE.  Contact ISODE-Request@NISC.SRI.COM to be added
      to this list.

   o  The primary documentation for this release consists of a five
      volume User's Manual (approx. 1000 pages) and a set of UNIX
      manual pages.  The sources to the User's Manual are in LaTeX
      format.  In addition, there are a number of notes, papers, and
      presentations included in the documentation set, again in
      either LaTeX or SLiTeX format.  If you do not have LaTeX, you
      should probably get a hardcopy from one of the distribution
      sites below.

                      ISODE/QUIPU Distribution Sites

   The FTP or FTAM distributions of ISODE-7.0 consists of 3 files.  The
   source and main ISODE-7.0 distribution is in the file ISODE-7.tar.Z
   which is approximately 4.7MB in size.

   LaTeX source for the entire document set can be found in the ISODE-
   7-doc.tar.Z file (3.5MB).  A list of documents can be found in the
   doc/ directory of the source tree.

   A Postscript version of the five volume manual can be found in the
   ISODE-7-ps.tar.Z file (4.3MB).

   If you can FTP to the Internet, then use anonymous FTP to uu.psi.com
   [136.161.128.3] to retrieve the files in BINARY mode from the ISODE/
   directory.

                 Additional PSI White Pages Pilot Software

   The 'usconfig' program configures a DSA which understands some of the
   NADF naming rules.  This software is primarily intended for creating
   directory hierarchies for DSAs from scratch.  The add-on software is
   available via anonymous FTP from uu.psi.com in:

      wp/src/wpp-addon.tar.Z

   Whether you choose to use 'usconfig' or not, please retrieve and
   install the addon, and follow the instructions therein. You might



ESCC X.500/X.400 Task Force                                    [Page 59]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   want to retrieve pilot-ps.tar.Z again also, as it contains an updated
   Administrator Guide.

   Note that the wpp-addon.tar.Z file needs to be installed on top of
   the ISODE 7.0 distribution; it does not duplicate any of the ISODE
   7.0, you need to retrieve and generate that too.

                                  PP 6.0

   PP is a Message Transfer Agent, intended for high volume message
   switching, protocol conversion, and format conversion.  It is
   targeted for use in an operational environment, but is also be useful
   for investigating message related applications.  Good management
   features are a major aspect of this system.  PP supports the 1984 and
   1988 versions of the CCITT X.400 / ISO 10021 services and protocols.
   Many existing RFC-822 based protocols are supported, along with RFC-
   1148bis conversion to X.400.  PP is an appropriate replacement for
   MMDF or Sendmail.  This is the second public release of PP, and
   includes substantial changes based on feedback from using PP on many
   sites.

   o  PP is not proprietary and can be used for any purpose.  The only
      restriction is that suing of the authors for any damage the
      code may cause is not allowed.

   o  PP runs on a range of UNIX and UNIX-like operating systems,
      including SUNOS, Ultrix, and BSD.  A full list of platforms on
      which PP is know to run is included in the distribution.

   o  Current modules include:

      -  X.400 (1984) P1 protocol.

      -  X.400 (1988) P1 protocol.

      -  Simple mail transfer protocol (SMTP), conformant to host
         requirements.

      -  JNT mail (grey book) Protocol.

      -  UUCP mail transfer.

      -  DECNET Mail-11 transfer

      -  Distribution list expansion and maintenance, using either a
         file based mechanism or an X.500 directory.

      -  RFC 822-based local delivery.



ESCC X.500/X.400 Task Force                                    [Page 60]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


      -  Delivery time processing of messages.

      -  Conversion between X.400 and RFC-822 according to the latest
         revision of RFC-1148, known as RFC-1148bis.

      -  Conversion support for reformatting body parts and headers.

      -  X-Window and line-based management console.

      -  Message Authorization checking.

      -  Reformatting support for "mail hub" operation.

      -  X.500-based distribution list facility using the QUIPU
         directory.

      -  FAX interworking

   o  No User Agents (UAs) are included with PP.  However, procedural
      access to the MTA is documented, to encourage others to write
      or to port UAs.  Several existing UAs, such as MH, may be used
      with PP.

   o  It is expected that a Message Store to be used in conjunction
      with PP (PPMS), and an associated X-Windows User Agent (XUA)
      will be released on beta test in first quarter 92.

   o  The core routing of PP 6.0 is table based.  DNS is used by the
      SMTP channel.  The next version of PP will support Directory
      Based routing, which may use X.500 or DNS.

   o  PP 6.0 requires ISODE 7.0.

   o  X-Windows release X11R4 (or greater) is needed by some of the
      management tools.  PP can be operated without these tools.

   o  Although PP is not "supported" per se (but see later), it does
      have a problem reporting address (bug reports (and fixes) are
      welcome):

      RFC-822:  PP-SUPPORT@CS.UCL.AC.UK
      X.400:    S=PP-Support; OU=CS; O=UCL;
                PRMD=UK.AC; ADMD= ; C=GB;

   o  The discussion group PP-PEOPLE@CS.UCL.AC.UK is used as an open
      forum on PP; Contact PP-PEOPLE-REQUEST@CS.UCL.AC.UK to be added
      to this list.




ESCC X.500/X.400 Task Force                                    [Page 61]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   o  The primary documentation for this release consists of a three
      and a half volume User's Manual (approx. 300 pages) and a set
      of UNIX manual pages.  The sources to the User's Manual are in
      LaTeX format.

                           PP Distribution Sites

   If you can FTP to the Internet from outside Europe, then use
   anonymous FTP to uu.psi.com [136.161.128.3] to retrieve the file pp-
   6.tar.Z in binary mode from the ISODE/ directory.  This file is the
   tar image after being run through the compress program and is
   approximately 3Mb in size.

   If you can FTP to the Internet from Europe, then use anonymous FTP to
   archive.eu.net [192.16.202.1] to retrieve the file pp-6.tar.Z in
   binary mode from the network/ISODE/ directory.  This file is the tar
   image after being run through the compress program and is
   approximately 3Mb in size.

             ISODE/QUIPU and PP Platforms as of December 1991

   Machine          OS                       ISODE  PP   Stacks  Notes
   ====================================================================
   CCUR 6000        RTU 5.0                  7.0    Yes! TCP     1
   --------------------------------------------------------------------
   CCUR 6000        RTU 6.0                  7.0    Yes! TCP     2
                                                         X25
                                                         CLNS
   --------------------------------------------------------------------
   CDC 4000 Series  EP/IX 1.3.2              6.6+        TCP     3
                    EP/IX 1.4.1                          CLNS
                                                         X25
   --------------------------------------------------------------------
   COMPAQ 386/25    SCO Unix 5.2             6.0         TCP
   --------------------------------------------------------------------
   COMPAQ 386       BSD                      7.0         TCP     4
                                                         X25
   --------------------------------------------------------------------
   Convex C120      ConvexOS 8.1             7.0         TCP     5
   --------------------------------------------------------------------
   DEC Vax          2nd Berkeley Network rel 7.0         TCP
                                                         X25
   --------------------------------------------------------------------
   DEC              DECnet-ULTRIX V5.0       7.0         TCP     6
                                                         CLNS
   --------------------------------------------------------------------
   DEC              Ultrix 3.1D              7.0    5.2  TCP     7
                    Ultrix 4.0                           X25



ESCC X.500/X.400 Task Force                                    [Page 62]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


                    Ultrix 4.1
   --------------------------------------------------------------------
   DEC              Ultrix 4.2               7.0        TCP
                                                        X25
                                                        CLNS
   --------------------------------------------------------------------
   DEC              VMS v5.x                 7.0        TCP
                                                        X25
   --------------------------------------------------------------------
   DG Avion         DGUX 4.30                7.0        TCP      8
   --------------------------------------------------------------------
   Encore Multimax 3xx UMAX V 2.2h           6.0        TCP      9
   Encore Multimax 5xx
   --------------------------------------------------------------------
   Encore NP1       UTX/32 3.1a              7.0        TCP      10
                                                        X25
   --------------------------------------------------------------------
   Encore PN6000    UTX/32 2.1b              6.0        TCP      9
   Encore PN9000                                        X25
   --------------------------------------------------------------------
   HP/9000/3xx      HP/UX 6.0                7.0        TCP      11
                    HP-UX 7.05 B
   --------------------------------------------------------------------
   HP/9000/8xx      HP-UX 7.00               7.0        TCP      11
                                                        X25
   --------------------------------------------------------------------
   IBM 3090         AIX/370 1.2.1            7.0        TCP      12
   --------------------------------------------------------------------
   IBM PS/2         AIX 1.2.1                6.7        TCP      13
   --------------------------------------------------------------------
   IBM RS/6000      AIX 3.1                  6.8        TCP
                    AIX 3.0
   --------------------------------------------------------------------
   ICL              DRS/6000                 7.0    5.2 TCP      14
   --------------------------------------------------------------------
   Macintosh        A/UX 2.0.1               7.0        TCP
   --------------------------------------------------------------------
   Macintosh        MacOS V6.x               6.0        TCP      15
   --------------------------------------------------------------------
   Mips 4-52        ATT-V3-0                 7.0    5.2 TCP      16
   --------------------------------------------------------------------
   NeXT                                      7.0    5.2 TCP      17
   --------------------------------------------------------------------
   ORION/Clipper                             6.8        TCP
   --------------------------------------------------------------------
   Olivetti LSX-3020 X/OS 2.1                6.7b   5.0 TCP      1
                                                        X25
   --------------------------------------------------------------------



ESCC X.500/X.400 Task Force                                    [Page 63]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   Pyramid 9800     OSx 5.1 (4.3BSD/SVR3.2)  7.0    5.2 TCP      18
   Pyramid MIS
   --------------------------------------------------------------------
   SEQUENT          DYNIX V3.0.18            7.0        TCP      8
   --------------------------------------------------------------------
   Sony News-1750   NEWS-OS 3.3              6.8        TCP
                    NEWS-OS 4.0c
   --------------------------------------------------------------------
   Sun4             SunOS 4.1                7.0    5.2 TCP
   Sun3             SunOS 4.1.1                         X25
                    SunOS 4.0.3c                        CONS
                                                        CLNS
   --------------------------------------------------------------------

   Notes:

   1.  NOT SNMP or VT

   2.  Little tested

   3.  Official upper layer

   4.  Prototype only!

   5.  Planned port

   6.  Being worked on!

   7.  3.1D binaries compiled under 4.2

   8.  Only QUIPU confirmed

   9.  Not QUIPU

   10.  Need "-Dregister=" in CONFIG.make

   11.  Need bug-fix no. 5 from bug-ISODE@xtel.co.uk. not SNMP,VT or
        FTAM-FTP gateway

   12.  No VT, QUIPU not tested

   13.  Models 80 and 95

   14.  NOT SNMP or VT,PP and X.25 requires patches available from
        X-Tel

   15.  Using MacTCP




ESCC X.500/X.400 Task Force                                    [Page 64]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   16.  Only QUIPU tested, built using BSD43 config

   17.  Need bug-fix no. 6 from bug-ISODE@xtel.co.uk

   18.  Built using BSD config, no VT or SNMP

   The above tables do not refer to beta releases of ISODE  and PP more
   recent than the public ISODE-7.0 or PP-5.2 releases.  The above table
   is generated from reports sent to bug-ISODE and pp-support.  There is
   no guarantee the information is correct.

Appendix D:  Sample X.500 Input File and Restricted Character List

   Below is a sample datafile that illustrates the format for providing
   data about persons at your site to be loaded into the ESnet DSA.
   Following the sample datafile is a detailed explanation of the format
   and content of the file.  We have tried to be as flexible as possible
   in defining the format of the file, given the constraints imposed by
   an automated process.  We would appreciate feedback on the format of
   the file and will try to accommodate any specific needs you may have
   to any extent that is reasonable.

   #
   #        Sample Data File for Bulk Loading X.500 Database
   #
   # delimiter character is ","                                        1
   # field 1 is commonName                                             2
   # field 2 is phone extension                                        3
   #   area code for all numbers is 510                                4
   #   prefix for all numbers is 422                                   5
   # field 3 is rfc822Mailbox                                          6
   # field 4 is facsimileTelephoneNumber                               7
   # default facsimileTelephoneNumber is (510) 422-3333                8
   # postalAddress for all entries is:                                 9
   #     National Energy Research Supercomputer Center                10
   #     P.O. Box 5509                                                11
   #     Livermore, California 94552                                  12
   #
   Chris Anderson,1915,anderson@ws1.nersc.gov,                        13
   Lila Brown,5680,brownl@ws2.nersc.gov,                              14
   Bob Green,4474,,                                                   15
   Max Jones,4488,elvis@presley.nersc.gov,5104224444                  16
   Dave Smith,9818,smithd@ws3.nersc.gov,                              17
   Cathy White,4016,snow@white.nersc.gov,                             18
   <end-of-file>

   Comment lines at the beginning of the file convey relevant formatting
   information.



ESCC X.500/X.400 Task Force                                    [Page 65]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   Following comment lines, each data line contains information about
   one person.

   Fields within a single data line are separated by a delimiter
   character.  You specify the delimiter character you wish to use in
   the comment section; be sure to choose a delimiter which does not
   appear as a legitimate character in any field of a data line.

   You may provide all or part of the attribute types listed in the
   table in Section 2.5 (commonName is required).  In the comment
   section, you must indicate which attribute types are contained in
   each field of a data line.

   Each data line must contain the same number of fields and the same
   order of fields (i.e. same order of attribute types).  Two successive
   delimiters indicated a null value (eof is a considered a field
   delimiter).

   The characters "=", "&", "$", and "#" are NEVER allowed in any
   attribute value.

   Below is a discussion of relevant lines of the sample datafile.

   Line 1      The delimiter character is identified as a comma (,).

   Line 2      Field # 1 is identified as containing the commonName
                 attribute.

   Line 3      Field # 2 is identified as containing the telephoneNumber
                 attribute.  The actual data value is a 4-digit
                 extension.

   Lines 4,5   Identify the area code and prefix which apply to all
                 4-digit extensions in the datafile.  If your actual
                 data values already contain area code and/or prefix,
                 then there would be no need to indicate default values.

   Line 6      Field # 3 is identified as containing the rfc822Mailbox
                 attribute.

   Line 7      Field # 4 is identified as containing the
                 facsimileTelephoneNumber attribute.

   Line 8      Identifies the default value for
                 facsimileTelephoneNumber.  If field 4 is missing in a
                 data line, the default value will be applied.

   Lines 9-12  Identify the value of the postalAddress attribute which



ESCC X.500/X.400 Task Force                                    [Page 66]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


                 applies to all entries.

   Line 13  commonName= Chris Anderson
            surName= Anderson
            telephoneNumber= 510-422-1915
            rfc822MailBox= anderson@ws1.nersc.gov
            facsimileTelephoneNumber= 510-422-3333
            postalAddress= National Energy Research Supercomputer Center
                           P.O. Box 5509
                           Livermore, California 94552

   Line 14  commonName= Lila Brown
            surName= Brown
            telephoneNumber= 510-422-5680
            rfc822MailBox= brownl@ws2.nersc.gov
            facsimileTelephoneNumber= 510-422-3333
            postalAddress= National Energy Research Supercomputer Center
                           P.O. Box 5509
                           Livermore, California 94552

   Line 15  commonName= Bob Green
            surName= Green
            telephoneNumber= 510-422-4474
            rfc822MailBox=
            facsimileTelephoneNumber= 510-422-3333
            postalAddress= National Energy Research Supercomputer Center
                           P.O. Box 5509
                           Livermore, California 94552

   Line 16  commonName= Max Jones
            surName= Jones
            telephoneNumber= 510-422-4488
            rfc822MailBox= elvis@presley.nersc.gov
            facsimileTelephoneNumber= 510-422-4444
            postalAddress= National Energy Research Supercomputer Center
                           P.O. Box 5509
                           Livermore, California 94552

   Line 17  commonName= Dave Smith
            surName= Smith
            telephoneNumber= 510-422-9818
            rfc822MailBox= smithd@ws3.nersc.gov
            facsimileTelephoneNumber= 510-422-3333
            postalAddress= National Energy Research Supercomputer Center
                           P.O. Box 5509
                           Livermore, California 94552





ESCC X.500/X.400 Task Force                                    [Page 67]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   Line 18  commonName= Cathy White
            surName= White
            telephoneNumber= 510-422-4016
            rfc822MailBox= snow@white.nersc.gov
            facsimileTelephoneNumber= 510-422-3333
            postalAddress= National Energy Research Supercomputer Center
                           P.O. Box 5509
                           Livermore, California 94552

Appendix E:  ESnet Backbone Sites

                            Government Agencies

   U.S. Department of Energy, Office of Energy Research (DOE)
   Germantown, Maryland   USA

   U.S. Department of Energy, San Francisco Office (SAN)
   Oakland, California   USA

                           National Laboratories

   NASA Ames Research Center (AMES, FIX-WEST)
   Mountain View, California   USA

   Argonne National Laboratory (ANL)
   Argonne, Illinois   USA

   Brookhaven National Laboratory (BNL)
   Upton, New York   USA

   Continuous Electron Beam Accelerator Facility (CEBAF)
   Newport News, Virginia   USA

   Fermi National Accelerator Laboratory (FNAL)
   Batavia, Illinois   USA

   Lawrence Berkeley Laboratory (LBL)
   Berkeley, California   USA

   Lawrence Livermore National Laboratory (LLNL)
   Livermore, California   USA

   Los Alamos National Laboratory (LANL)
   Los Alamos, New Mexico   USA

   Oak Ridge National Laboratory (ORNL)
   Oak Ridge, Tennessee   USA




ESCC X.500/X.400 Task Force                                    [Page 68]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   Pacific Northwest Laboratory (PNL)
   Richland, Washington   USA

   Princeton Plasma Physics Laboratory (PPPL)
   Princeton, New Jersey   USA

   Sandia National Laboratory, Albuquerque (SNLA)
   Albuquerque, New Mexico   USA

   Stanford Linear Accelerator Center (SLAC)
   Menlo Park, California   USA

   Superconducting Super Collider (SSC)
   Dallas, Texas   USA

                               Universities

   California Institute of Technology (CIT)
   Pasadena, California   USA

   Florida State University (FSU)
   Tallahassee, Florida   USA

   Iowa State University (ISU)
   Ames, Iowa   USA

   Massachusetts Institute of Technology (MIT)
   Cambridge, Massachusetts   USA

   New York University (NYU)
   Upton, New York   USA

   Oak Ridge Associated Universities (ORAU)
   Oak Ridge, Tennessee   USA

   University of California, Los Angeles (UCLA)
   Westwood, California   USA

   University of Maryland (UMD, FIX-EAST)
   College Park, Maryland   USA

   University of Texas, Austin (UTA)
   Austin, Texas   USA

                            Commercial Entities

   General Atomics (GA)
   San Diego, California   USA



ESCC X.500/X.400 Task Force                                    [Page 69]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   Office of Science and Technology Information (OSTI)
   Oak Ridge, Tennessee   USA

   Science Applications, Incorporated (SAIC)
   McLean, Virginia   USA

Appendix F:  Local Site Contacts for DOE Naming Authorities

   Below is a list of all Department of Energy GOSIP Site Authorities
   for OSI registration and addressing.  This information was obtained
   from the DoE GOSIP On-Line Information System (DOE-GOIS), dated
   November 18, 1991.

   Marian F. Sotel
   Director, Information management Division
   U.S. Department of Energy
   DOE Field Office, Albuquerque

   Dennis Jensen
   Ames Laboratory
   258H Development
   Ames, IA 50011-3020
   (515) 294-7909

   Linda Winkler
   Argonne National Laboratory
   Argonne, IL 60439
   (708) 972-7236

   R. E. Kremer
   Manager, Resource Automation
   U.S. Department of Energy
   Bettis Atomic Power laboratory

   Gary Ragsdale
   Manager, Information Services
   U.S. Department of Energy
   Bonneville Power Administration
   905 NE 11th Avenue
   Portland, OR 97232

   Wayne Larson
   Head of Data Communications Unit
   U.S. Department of Energy
   Bonneville Power Administration
   905 NE 11th Avenue
   Portland, OR 97232




ESCC X.500/X.400 Task Force                                    [Page 70]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   George Rabinowitz
   Head Distributed Computing Section
   Brookhaven National Laboratory
   Upton, New York 11973
   (516) 282-7637

   Donna A. Dyxin
   Communications Specialist
   U.S. Department of Energy
   DOE Field Office, Chicago
   9800 South Cass Avenue
   Argonne, IL 60439

   Elaine R. Liebrecht
   System Manager and Planning Supervisor
   EG&G Mound Applied Technologies
   P.O. Box 3000
   Miamisburg, OH 45343-3000
   (FTS) 774-3733 or (513) 865-3733

   Jeffrey J. Johnson
   Communications Supervisor
   EG&G Mound Applied Technologies
   P.O. Box 3000
   Miamisburg, OH 45343-3000
   (FTS) 774-4230 or (513) 865-4230

   Paul P. Herr
   U.S. Department of Energy
   Energy Information Agency
   (202) 586-7318

   William H. Foster
   U.S. Department of Energy
   Energy Information Agency
   (202) 586-6310

   Mark O. Kaletka
   Data Communications Group Leader, Computing Div.
   Fermi National Accelerator Lab
   P.O. Box 500
   Batavia, IL 60510
   (708) 840-2965

   David A. Mackler
   Grand Junction Project Office
   (FTS) 326-6412




ESCC X.500/X.400 Task Force                                    [Page 71]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   Wayne L. Selfors
   Grand Junction Project Office
   (FTS) 326-6525

   Gerald F. Chappell
   Director, ITSO
   U.S. Department of Energy
   Headquarters
   Washington D.C., 20545
   (FTS) 233-3685 or (301) 903-3685

   Joe Diel
   Supervisor, Biomathematics Group
   ITRI

   David H. Robinson
   Section Supervisor, Information Systems
   Allied-Signal Aerospace Company
   Kansas City Division
   P.O. Box 419159
   Kansas City, MO 64141-6159
   (FTS) 997-3690 or (816) 997-3690

   Robert M. Jensen
   Supervisory Engineer, Information Systems
   Allied-Signal Aerospace Company
   Kansas City Division
   P.O. Box 419159
   Kansas City, MO 64141-6159
   (FTS) 997-5538 or (816) 997-5538

   Russell Wright
   Lawrence Berkeley Laboratories
   1 Cyclotron Road
   Berkeley, CA 94720
   (510) 486-6965

   William A. Lokke
   Associate Director for Computation
   Lawrence Livermore National Lab
   (FTS) 532-9870 or (669) 422-9870

   Philip Wood/Glenn Michel
   Los Alamos National Laboratory
   Los Alamos, NM 87545
   (FTS) 843-1845 or (FTS) 843-2598





ESCC X.500/X.400 Task Force                                    [Page 72]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   Robert Bruen
   MIT Laboratory for Nuclear Science
   Computer Facilities Manager
   Massachusetts Institute of Tech.
   Cambridge, MA

   Mark Cerullo
   Morgantown Energy Technology Center
   (FTS) 923-4345

   Hank Latham
   NVRSN
   (FTS) 575-7646

   Bill Morrison
   Network Specialist
   Bechtel Petroleum Operations, Inc
   Naval Petroleum Reserves California
   P.O. Box 127
   Tupman, CA 93276
   (FTS) 797-6933 or (805) 763-6933

   Mary Ann Jones
   DOE Field Office, Nevada

   Bill Freberg
   Computer Sciences Corporation
   DOE Field Office, Nevada

   Roger Hardwick
   Project Director
   Roy F. Weston
   OCRWM
   3885 S. Decatur Blvd.
   Las Vegas, NV 89103
   (702) 873-6200

   John Gandi
   U.S. Department of Energy
   OCRWM
   101 Convention Ctr
   Phase II Complex, Suite 202
   Las Vegas, NV 89109
   (702) 794-7954

   Benny Goodman
   U.S. Department of Energy
   OSTI



ESCC X.500/X.400 Task Force                                    [Page 73]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   Raymond F. Cook
   U.S. Department of Energy
   OSTI

   D. M. Turnpin
   Martin Marietta Energy Systems, Inc
   Oak Ridge
   P.O. Box 2009
   Oak Ridge, TN 37831-8227
   (FTS) 626-8848 or (615) 576-8848

   T. E. Birchfield
   Supervisor, Electronic Informations Delivery Sect.
   Martin Marietta Energy Systems, Inc
   Oak Ridge
   P.O. Box 2008
   Oak Ridge, TN 37831-6283
   (FTS) 624-4635 or (615) 574-4635

   Bobby Brumley
   TRESP Associates
   DOE Field Office, Oak Ridge

   Mike Letterman
   TRESP Associates
   DOE Field Office, Oak Ridge

   S. Dean Carpenter
   Department Head, Communications
   Mason and Hanger
   Pantex Plant

   Wayne C. Phillips
   Section Head, Internal Communications
   Mason and Hanger
   Pantex Plant

   A. J. Lelekacs
   Sr. Networking Engineer
   General Electric
   Pinellas Plant
   P.O. Box 2908
   Neutron Devices Department
   Largo, FL 34649-2908







ESCC X.500/X.400 Task Force                                    [Page 74]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   Paul A. Funk
   Site Access Coordinator
   Princeton Plasma Physics Laboratory
   P.O. Box 451
   Princeton, NJ 08543
   (609) 243-3403

   John Murphy
   Branch Chief, Information and Communication Mgmt
   U.S. Department of Energy
   DOE Field Office, Richland
   P.O. Box 550
   Richland, WA 99352
   (FTS) 444-7543 or (509) 376-7543

   Mike Schmidt
   Telecom & Network Services IRM
   Westinghouse Hanford Company
   DOE Field Office, Richland
   P.O. Box 1970
   Richland, WA 99352
   (FTS) 444-7739 or (509) 376-7739

   Dwayne Ramsey
   Information Resources Management Division
   U.S. Department of Energy
   DOE Field Office, San Francisco
   (FTS) 536-4302

   W. F. Mason
   Central Computing Systems Manager
   Sandia National Laboratories - AL
   P.O. Box 5800
   Albuquerque, NM 87185
   (FTS) 845-8059 or (505) 845-8059

   Harry R. Holden
   U.S. Department of Energy
   DOE Field Office, Savannah River
   P.O. Box A
   Aiken, SC 29802
   (FTS) 239-1118 or (803) 725-1118









ESCC X.500/X.400 Task Force                                    [Page 75]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   Reggie Peagler
   Network Security Officer
   Savannah River Site
   Building 773-51A
   Aiken, SC 29808
   (FTS) 239-3418 or (803) 557-3418

   Wade A. Gaines
   Acting ADP Manager
   U.S. Department of Energy
   Southeastern Power Administration
   Samuel Elbert Building
   Elberton, GA 30635

   Paul Richard
   Southwestern Power Administration
   (FTS) 745-7482

   Dr. R. Les Cottrell
   Assistant Director, SLAC Computer Services
   Stanford Linear Accelerator Center
   P.O. Box 4349
   Stanford, CA 94309

   John Lucero
   Systems Analyst, Management Systems
   Westinghouse Electric Corporation
   Waste Isolation Pilot Plant
   P.O. Box 2078
   Carlsbad, NM 88221
   (FTS) 571-8459 or (505) 887-8459

   Lawrence Bluhm
   Sr. Systems Analyst, Management Systems
   Westinghouse Electric Corporation
   Waste Isolation Pilot Plant
   P.O. Box 2078
   Carlsbad, NM 88221
   (FTS) 571-8459 or (505) 887-8459

   Ben Sandoval
   Western Area Power Administration
   (FTS) 327-7470

   John Sewell
   Western Area Power Administration
   (FTS) 327-7407




ESCC X.500/X.400 Task Force                                    [Page 76]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


Appendix G:  Recommended Reading

                        RFCs (Request For Comments)

   The following RFCs may be obtained from the ESnet Information Server.
   They are stored in the directory [ANONYMOUS.RFCS].  They may be
   retrieved via anonymous FTP (nic.es.net, 128.55.32.3) or DECnet copy
   (ESNIC::, 41.174).

RFC1328  X.400 1988 to 1984 downgrading.  Hardcastle-Kille, S.E.  1992
     May; 5 p. (Format: TXT=10006 bytes)

RFC1327  Mapping Between X.400 (1988) /ISO 10021 and RFC 822.
     Hardcastle-Kille, S.E.  1992 May; 113 p. (Format: TXT=228598 bytes)

RFC1309  Technical overview of directory services using the X.500
     protocol.  Weider, C.; Reynolds, J.K.; Heker, S.  1992 March; 4 p.
     (Format: TXT=35694 bytes)

RFC1308  Executive Introduction to Directory Services Using the X.500
     Protocol.  Weider, C.; Reynolds, J.K.  1992 March; 4 p. (Format:
     TXT=9392 bytes)

RFC1295  North American Directory Forum.  User bill of rights for
     entries and listing in the public directory.  1992 January; 2 p.
     (Format: TXT=3502 bytes)

RFC1292  Lang, R.; Wright, R.  Catalog of Available X.500
     Implementations. 1991 December; 103 p. (Format: TXT=129468 bytes)

RFC1279  Hardcastle-Kille, S.E.  X.500 and domains.  1991 November; 13
     p. (Format: TXT=26669, PS=170029 bytes)

RFC1278  Hardcastle-Kille, S.E.  String encoding of presentation
     address. 1991 November; 5 p. (Format: TXT=10256, PS=128696 bytes)

RFC1277  Hardcastle-Kille, S.E.  Encoding network addresses to support
     operations over non-OSI lower layers.  1991 November; 10 p.
     (Format: TXT=22254, PS=176169 bytes)

RFC1276  Hardcastle-Kille, S.E.  Replication and distributed operations
     extensions to provide an Internet directory using X.500. 1991
     November; 17 p. (Format: TXT=33731, PS=217170 bytes)

RFC1275  Hardcastle-Kille, S.E.  Replication requirements to provide an
     Internet directory using X.500.  1991 November; 2 p. (Format:
     TXT=4616, PS=83736 bytes)




ESCC X.500/X.400 Task Force                                    [Page 77]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


RFC1274  Kille, S.E.; Barker, P.  COSINE and Internet X.500 schema. 1991
     November; 60 p. (Format: TXT=92827 bytes)

RFC1255  North American Directory Forum.  Naming scheme for c=US. 1991
     September; 25 p. (Format: TXT=53783 bytes)  (Obsoletes RFC 1218)

RFC1249  Howes, T.; Smith, M.; Beecher, B.  DIXIE protocol
     specification.  1991 August; 10 p. (Format: TXT=20693 bytes)

RFC1202  Rose, M.T.  Directory Assistance service.  1991 February; 11 p.
     (Format: TXT=21645 bytes)

RFC1006  Rose, M.T.; Cass, D.E.  ISO transport services on top of the
     TCP: Version 3.  1987 May; 17 p. (Format: TXT=31935 bytes)

                         Non Published Working Notes

"A String Representation of Distinguished Names", S.E. Hardcastle-Kille,
     01/30/1992.

     The OSI Directory uses distinguished names as the primary keys to
     entries in the directory.  Distinguished Names are encoded in
     ASN.1. When a distinguished name is communicated between to users
     not using a directory protocol (e.g., in a mail message), there is
     a need to have a user-oriented string representation of
     distinguished name.

"An Access Control Approach for Searching and Listing", S.E.
     Hardcastle-Kille, T. Howes, 09/23/1991.

     This memo defines an extended ACL (Access Control List) mechanism
     for the OSI Directory.  It is intended to meet strong operational
     requirements to restrict searching and listing externally, while
     allowing much more freedom within an organization.  In particular,
     this mechanism makes it possible to restrict searches to certain
     sets of attributes, and to prevent "trawling": the disclosure of
     large organizational data or structure information by repeated
     searches or lists. This capability is necessary for organizations
     that want to hide their internal structure, or to prevent dumping
     of their entire database.  This memo describes functionality
     beyond, but compatible with, that expected in the 1992 X.500
     standard.

"Building an Internet Directory using X.500", S. Kille, 01/07/1991.

     The IETF has established a Working Group on OSI Directory Services.
     A major component of the initial work of this group is to establish
     a technical framework for establishing a Directory Service on the



ESCC X.500/X.400 Task Force                                    [Page 78]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


     Internet, making use of the X.500 protocols and services.  This
     document summarizes the strategy established by the Working Group,
     and describes a number of RFCs which will be written in order to
     establish the technical framework.

"Directory Requirements for COSINE and Internet Pilots (OSI-DS 18)",
     S.E. Hardcastle-Kille, 07/09/1991.

     This document specifies operational requirements for DUAs and DSAs
     in the Internet and COSINE communities.  This document summarizes
     conformance requirements.  In most cases, technical detail is
     handled by reference to other documents.  This document refers to
     core directory infrastructure. Each application using the directory
     may impose additional requirements.

"DSA Naming", S.E. Hardcastle-Kille, 01/24/1992.

     This document describes a few problems with DSA Naming as currently
     deployed in pilot exercises, and suggests a new approach.  This
     approach is suggested for use in the Internet Directory Pilot,
     which overcomes a number of existing problems, and is an important
     component for the next stage in increase of scale.

"Handling QOS (Quality of service) in the Directory", S.E. Kille,
     08/29/1991.

     This document describes a mechanism for specifying the Quality of
     Service for DSA Operations and Data in the Internet Pilot Directory
     Service "Building and internet directory using X.500".

"Interim Directory Tree Structure for Network Infrastructure
     Information", Chris Weider, Mark Knopper, Ruth Lang, 06/14/1991.

     As work progresses on incorporating WHOIS and Network
     Infrastructure information into X.500, we thought it would be
     useful to document the current DIT structure for this information,
     along with some thoughts on future expansion and organization of
     this subtree of the DIT. The first section of this document
     describes the current structure, the second section the possible
     expansion of the structure.

"Interim Schema for Network Infrastructure Information in X.500 New
     name:  Encoding Network Addresses to support operation ov", Chris
     Weider, Mark Knopper, 06/14/1991.

     As the OSI Directory progresses into an operational structure which
     is being increasingly used as a primary resource for Directory
     Information, it was perceived that having the Internet Site



ESCC X.500/X.400 Task Force                                    [Page 79]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


     Contacts and some limited network information in the Directory
     would be immediately useful and would also provide the preliminary
     framework for some distributed NIC functions. This paper describes
     the interim schema used to contain this information.

"Naming Guidelines for Directory Pilots", P. Barker, S.E. Kille,
     01/30/1992.

     Deployment of a Directory will benefit from following certain
     guidelines. This document defines a number of naming guidelines.
     Alignment to these guidelines will be recommended for national
     pilots.

"OSI NSAP Address Format For Use In The Internet", R Colella, R Callon,
     02/13/1991.

     The Internet is moving towards a multi-protocol environment that
     includes OSI. To support OSI, it is necessary to address network
     layer entities and network service users.  The basic principles of
     OSI Network Layer addressing and Network Service Access Points
     (NSAPs) are defined in Addendum 2 to the OSI Network service
     definition.  This document recommends a structure for the Domain
     Specific Part of NSAP addresses for use in the Internet that is
     consistent with these principles.

"Representing Public Archives in the Directory", Wengyik Yeong,
     12/04/1991.

     The proliferation of publicly accessible archives in the Internet
     has created an ever-widening gap between the fact of the existence
     of such archives, and knowledge about the existence and contents of
     these archives in the user community. Related to this problem is
     the problem of also providing users with the necessary information
     on the mechanisms available to retrieve such archives.  In order
     for the Internet user community to better avail themselves of this
     class of resources, there is a need for these gaps in knowledge to
     be bridged.

"Schema for Information Resource Description in X.500", Chris Weider,
     06/14/1991.

     The authors are interested in allowing distributed access and
     updating for Information Resource Description information to users
     of the Internet. This paper discusses the schema used to hold the
     Information Resource Description information.  The new attributes
     are taken from the US-MARC fields, and subfields, with the mapping
     described in the text.




ESCC X.500/X.400 Task Force                                    [Page 80]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


"Schema for NIC Profile Information in X.500", Chris Weider, Mark
     Knopper, 06/14/1991.

     The authors of this document, in conjunction with the chairs of the
     IETF Network Information Services Infrastructure (NISI) group,
     would like to implement a Directory of Network Information Centers,
     or NICs.  This will enable NICs to find each other easily, will
     allow users with access to a DSA to find out where NICs are, and
     will in general facilitate the distribution of information about
     the Internet and some of its infrastructure.  This document
     proposes a set of standard schema for this information.

"Using the OSI Directory to Achieve User Friendly Naming", S. Kille,
     01/30/1992.

     The OSI Directory has user friendly naming as a goal.  A simple
     minded usage of the directory does not achieve this.  Two aspects
     not achieved are:  1)  A user oriented notation  and  2)
     Guessability. This proposal sets out some conventions for
     representing names in a friendly manner, and shows how this can be
     used to achieve really friendly naming.  This then leads to a
     specification of a standard format for representing names, and to
     procedures to resolve them. This leads to a specification which
     allows directory names to be communicated between humans.  The
     format in this specification is identical to that defined in the
     reference of "A String Representation of Distinguished Name", and
     it is intended that these specifications are compatible.

"Requirements for X.400 Management Domains (MDs) Operating in the Global
     Research and Development X.400 Service", R. Hagens, 11/12/1991.

     This  document  specifies  a  set  of  minimal   operational
     requirements that  must  be  implemented  by all Management Domains
     (MDs) in the Global R&D X.400 Service.   This  document  defines
     the  core  operational requirements; in some cases, technical
     detail is handled  by  reference  to other documents.  The Global
     R&D X.400 Service is defined as all organizations which meet the
     requirements described in this document.

"Routing Coordination for X.400 MHS Services within a
     Multiprotocol/Multinetwork Environment", U. Eppenberger,
     10/25/1992.

     The X.400 addresses do start to appear on business cards. The
     different MHS service providers are not well interconnected and
     coordinated which makes it a very hard job for the MHS managers to
     know where to route all the new addresses. A big number of X.400
     implementations support different lower layer stacks. Taking into



ESCC X.500/X.400 Task Force                                    [Page 81]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


     account the variety of existing large transport networks, there is
     now the chance of implementing a worldwide message handling service
     using the same electronic mail standard and therefore without the
     need of gateways with service reduction and without the restriction
     to a single common transport network. This document proposes how
     messages can travel over different networks by using multi stack
     MTAs as relays. Document formats and coordination procedures bridge
     the gap until an X.500 directory service is ready to store the
     needed connectivity and routing information.

                      International Standards Documents

International Consultative Committee for Telephone and Telegraph. Open
     Systems Interconnection - The Directory. X.500 Series
     Recommendations.  December, 1988.

     (also published as)

ISO/IEC. Information Technology - Open Systems Interconnection - The
     Directory. International Standard 9594. 1989.

International Consultative Committee for Telephone and Telegraph. Data
     Communication Networks - Message Handling Systems. X.400 Series
     Recommendations. Geneva 1985.

International Consultative Committee for Telephone and Telegraph. Data
     Communication Networks - Message Handling Systems. X.400 Series
     Recommendations. Melbourne, 1988.

                               NIST Documents
         (National Institute of Standards and Technology Documents)

   The following documents can be retrieved from the ESnet Information
   Server in directory [ANONYMOUS.NIST].

Government Open Systems Interconnection Profile (GOSIP) Version 1,
     National Institute of Standards and Technology, Federal Information
     Processing Standards Publication #146, August, 1988.

Government Open Systems Interconnection Profile (GOSIP) Version 2,
     National Institute of Standards and Technology, October, 1990.

                                DOE Documents

   The following documents prepared by the DOE GOSIP Migration Working
   Group can be retrieved from the ESnet Information Server in directory
   [ANONYMOUS.DOE-GOSIP].




ESCC X.500/X.400 Task Force                                    [Page 82]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


U.S. Department of Energy. Government Open Systems Interconnection
     Profile.  Transition Strategy. DOE GOSIP Document # GW-ST-008.
     November, 1990.

U.S. Department of Energy. Government Open Systems Interconnection
     Profile.  Transition Plan. DOE GOSIP Document # GW_PN_005.
     November, 1990.

U.S. Department of Energy. Government Open Systems Interconnection
     Profile.  Procedures and Guidelines. DOE GOSIP Document # GW-PR-
     007. April, 1991.

                             IETF Working Groups

   Three IETF working groups, OSI X.400, OSI-DS and MHS-DS have been
   working in in X.400 and X.500. Minutes of meetings, descriptions of
   the working groups' charters and goals, information about mailing
   lists, and other pertinent documents can be retrieved from the ESnet
   Information Server in the directories [ANONYMOUS.IETF.OSIDS],
   [ANONYMOUS.IETF.OSIX400] and [ANONYMOUS.IETF.MHSMS].

                                  Others

Marshall T. Rose, Julian P. Onions and Colin J. Robbins. The ISO
     Development Environment: User's Manual, 1991.  ISODE Documentation
     Set.

Marshall T. Rose and Wengyik Yeong.  PSI White Pages Pilot Project:
     Administrator's Guide, 1991.  ISODE Documentation Set.

Marshall T. Rose.  The Open Book: A Practical Perspective on Open
     Systems Interconnection. Prentice-hall, 1990. ISBN 0-13-643016-3.

Marshall T. Rose.  The Little Black Book: Mail Bonding with OSI
     Directory Services. Prentice-hall, 1991. ISBN 0-13-683219-5.

Alan Turner and Paul Gjefle, Pacfic Northwest Laboratory.  Performance
     Analysis of an OSI X.500 (QUIPU) Directory Service Implmentation.
     1992. Available on nic.es.net in the directory [ANONYMOUS.ESNET-
     DOC]QUIPU-PERF.PS

Appendix H:  Task Force Member Information

   Bob Aiken
     U.S. Department of Energy, Office of Energy Research, Scientific
     Computing Staff (now with National Science Foundation)
     Email:  raiken@nsf.gov




ESCC X.500/X.400 Task Force                                    [Page 83]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   Joe Carlson
     Lawrence Livermore National Laboratory
     Livermore, California USA
     Email:  carlson@lll-winken.llnl.gov

   Les Cottrell
     Stanford Linear Accelerator Center
     Menlo Park, California USA
     Email:  cottrell@slacvm.slac.stanford.edu

   Tim Doody
     Fermi National Accelerator Laboratory
     Batavia, Illinois USA
     Email:  doody@fndcd.fnal.gov

   Tony Genovese  (Contributing Author)
     Lawrence Livermore National Laboratory
     Livermore, California USA
     Email:  genovese@es.net

   Arlene Getchell  (Contributing Author)
     Lawrence Livermore National Laboratory
     Livermore, California USA
     Email:  getchell@es.net

   Charles Granieri
     Stanford Linear Accelerator Center
     Menlo Park, California USA
     Email:  cxg@slacvm.slac.stanford.edu

   Kipp Kippenhan  (Contributing Author)
     Fermi National Accelerator Laboratory
     Batavia, Illinois USA
     Email:  kippenhan@fnal.fnal.gov

   Connie Logg
     Stanford Linear Accelerator Center
     Menlo Park, California USA
     Email:  cal@slacvm.slac.stanford.edu

   Glenn Michel
     Los Alamos National Laboratory
     Los Alamos, New Mexico USA
     Email:  gym@lanl.gov

   Peter Mierswa
     Digital Equipment Corporation USA




ESCC X.500/X.400 Task Force                                    [Page 84]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   Jean-Noel Moyne
     Lawrence Berkeley Laboratory
     Berkeley, California USA
     Email:  jnmoyne@lbl.gov

   Kevin Oberman  (Contributing Author)
     Lawrence Livermore National Laboratory
     Livermore, California USA
     Email:  oberman@icdc.llnl.gov

   Dave Oran
     Digital Equipment Corporation USA

   Bob Segrest
     Digital Equipment Corporation USA

   Tim Streater
     Stanford Linear Accelerator Center
     Menlo Park, California USA
     Email:  streater@slacvm.slac.stanford.edu

   Allen Sturtevant  (Chair, Contributing Author, Document Editor)
     Lawrence Livermore National Laboratory
     Livermore, California USA
     Email:  sturtevant@es.net

   Mike Sullenberger
     Stanford Linear Accelerator Center
     Menlo Park, California USA
     Email:  mls@scsw5.slac.stanford.edu

   Alan Turner  (Contributing Author)
     Pacific Northwest Laboratory
     Richland, Washington USA
     Email:  ae_turner@pnl.gov

   Linda Winkler  (Contributing Author)
     Argonne National Laboratory
     Argonne, Illinois USA
     Email:  b32357@anlvm.ctd.anl.gov

   Russ Wright  (Contributing Author)
     Lawrence Berkeley Laboratory
     Berkeley, California USA
     Email:  wright@lbl.gov






ESCC X.500/X.400 Task Force                                    [Page 85]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


Security Considerations

   Security issues are discussed in sections 2.5.1 and 2.7.5.1 of this
   memo.

Authors' Addresses

   Allen Sturtevant
   Lawrence Livermore National Laboratory
   P.O. Box 5509; L-561
   Livermore, CA 94551

   Phone:  +1 510-422-8266
   Email:  sturtevant@es.net


   Tony Genovese
   Lawrence Livermore National Laboratory
   P.O. Box 5509; L-561
   Livermore, CA 94551

   Phone:  +1 510-423-2471
   Email:  genovese@es.net


   Arlene Getchell
   Lawrence Livermore National Laboratory
   P.O. Box 5509; L-561
   Livermore, CA 94551

   Phone:  +1 510-423-6349
   Email:  getchell@es.net


   H. A. Kippenhan Jr.
   Fermi National Accelerator Laboratory
   Wilson Hall 6W, MS-234
   P.O. Box 500
   Batavia, IL 60150

   Phone:  +1 708-840-8068
   Email:  kippenhan@fnal.fnal.gov









ESCC X.500/X.400 Task Force                                    [Page 86]

RFC 1330            X.500 and X.400 Plans for ESnet             May 1992


   Kevin Oberman
   Lawrence Livermore National Laboratory
   P.O. Box 5509; L-156
   Livermore, CA 94551

   Phone:  +1 510-422-6955
   Email:  oberman1@llnl.gov


   Alan Turner
   Pacific Northwest Laboratory
   P.O. Box 999; K7-57
   Richland, WA 99352

   Phone:  +1 509-375-6670
   Email:  ae_turner@pnl.gov


   Linda Winkler
   Argonne National Laboratory
   9700 South Cass Avenue
   Building 221 B251
   Argonne, IL 60439

   Phone:  +1 708-252-7236
   Email:  lwinkler@anl.gov


   Russ Wright
   Lawrence Berkeley Laboratory
   1 Cyclotron Road
   MS 50B-2258
   Berkeley, CA 94720

   Phone:  +1 510-486-6965
   Email:  wright@lbl.gov















ESCC X.500/X.400 Task Force                                    [Page 87]