File: rfc1616.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 (2467 lines) | stat: -rw-r--r-- 107,432 bytes parent folder | download | duplicates (8)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
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






Network Working Group                          RARE WG-MSG Task Force 88
Request for Comments: 1616                                      May 1994
RARE Technical Report: 10
Category: Informational


     X.400(1988) for the Academic and Research Community in Europe

            A report by the RARE Task Force on X.400(1988)
             of the RARE Working Group on Mail & Messaging

Status of this Memo

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

1.  Abstract

   The European research and development community, as represented by
   the member research networks of RARE, has lead the deployment within
   the global R&D community of X.400 electronic messaging services, as
   specified in the international recommendations CCITT X.400(1984), for
   more than five years. As a result of providing such services to the
   European R&D users it has become clear that there is an existing and
   ever increasing demand from these users for new and enhanced
   electronic messaging services and product to be used to communicate
   within the R&D community but within commercial service providers and
   organisations as well.

   It is also clear that new services, such as Multimedia messaging and
   Secure messaging, and the resulting products promise dramatic
   benefits and opportunities, for not only the R&D community but also
   for the wider commercial, industrial and public communities, in terms
   of facilitating innovative ways of working and living which can only
   enhance the missions and goals of the respective communities. Not
   least the establishment of globally pervasive messaging services
   between all users, R&D and commercial, is facilitated by the early
   adoption of such advanced new services. An indication of the
   importance of such a messaging service can be appreciated if one
   considers that in many organizations (especially commercially based)
   messaging may be the only method to communicate between independent
   organizations due to security considerations and lower layer network
   differences.

   The Commission of European Communities (CEC) VALUE subprogram II has
   been established to support initiatives relating to the development
   and adaptation of R&D networks in member states.  Amongst other



RARE WG-MSG Task Force 88                                       [Page 1]

RFC 1616     X.400(88) for European Academics and Research      May 1994


   initiatives the VALUE program supports X.400 initiatives in certain
   countries. VALUE support has so far been limited to X.400(1984)
   initiatives, as X.400(1984) has up until now been the dominating OSI
   services. However as X.400(1988) implementations have started to
   appear a VALUE funded study of the X.400(1988) aspects of messaging
   and their impact on the R&D community was felt necessary. This report
   is one of the results of that study.

   The report documents the results of a task force on X.400(1988)
   deployment of the RARE Mails and Messaging Work Group during the
   period from November 1992 until October 1993. Open reviews of the
   report have occurred in the RARE Mail and Messaging Work Group and
   within the IETF X.400ops Working Group.

   The scope of the report is limited to deployment of X.400(1988)
   services, and as such the report does not contain any recommendations
   on development and deployment of Internet RFC 822 / MIME/ PEM related
   (pilot) services. However, since the report shows that both
   X.400(1988) and RFC 822 / MIME / PEM will be developed and used
   within the European R&D community, such a pilot should also
   considered.  Note: RFC 822 is also known as Internet STD 11.

   Circulation of this report is unlimited. Comments on this report may
   be sent to the e-mail distribution list:

    RFC 822: wg-msg@rare.nl
    X.400:   S=wg-msg;O=rare;P=surf;A=400net;C=nl;

Task Force Members:

    Claudio Allocchio (INFN),
    Harald T. Alvestrand (SINTEF),
    James C. I. Craigie (JNT),
    Urs Eppenberger (SWITCH),
    Frode Hernes (maXware),
    Jeroen Houttuin (RARE),
    Erik Huizer (SURFnet) - chairman,
    Steve Kille (ISODE Consortium),
    James A. (Jim) Romaguera (NetConsult).

    Editors: James A. (Jim) Romaguera & Erik Huizer

   The work of this Task Force has been funded by the Commission of
   European Communities (CEC) VALUE subprogram II, Stichting SURF and
   SURFnet bv.






RARE WG-MSG Task Force 88                                       [Page 2]

RFC 1616     X.400(88) for European Academics and Research      May 1994


Table of Contents

   1.  Abstract                                                      1
   2.  Management Summary                                            3
   3.  Framework for the report                                      6
   4.  Present situation of European Messaging                       7
      4.1. Messaging services                                        7
      4.2. Requirements for messaging                                8
             4.2.1. User Oriented                                    9
             4.2.2. Service provider viewpoint                      10
      4.3. Messaging capabilities                                   11
   5.  Possible solutions for providing globally pervasive
       messaging                                                    12
      5.1. PC LAN E-mail systems                                    13
      5.2. RFC 822, MIME and PEM services                           15
      5.3. X.400 - 1984 and 1988                                    19
   6.  Migration to X.400(1988)                                     23
      6.1. PC LAN E-mail systems                                    25
      6.2. RFC 822, MIME and PEM services                           25
      6.3. X.400(1984) services                                     27
      6.4. Mail-11 services                                         28
   7.  Benefits of migrating to X.400(1988) and the involved costs  28
   8.  Main Recommendations                                         33
   9.  Security Considerations                                      34
   10. Reading List and Bibliography                                35
   11. Terminology                                                  37
   Appendix A - Elaboration on the main recommendations             38
   Appendix B - A number of detailed guidelines.                    40
   Authors' Addresses                                               44

2.  Management Summary

   This document reports the results of study of the X.400(1988) aspects
   of messaging and their impact on the R&D community. The study was
   funded by the CEC under VALUE Subprogram II and has been carried out
   by a task force on the RARE Mail Working Group.  The document is
   targeted at technical decision makers as well as those who would fund
   activity in this area.

   The document presents the existing situation as regards the
   predominate messaging technologies within Europe. These are presented
   within the context of a number of large messaging communities that
   are using these technologies:

    - RFC 822,
    - X.400(1984),
    - Mail-11 and
    - PC LAN messaging



RARE WG-MSG Task Force 88                                       [Page 3]

RFC 1616     X.400(88) for European Academics and Research      May 1994


   Three major European communities are referenced:

    - Commercial service providers
    - R&D community
    - Commercial organisations using messaging services.

   The report states the following facts:

    - The resources, human or financial, to operate multiple wide
      area messaging services connecting together independent
      organisations are high. As such it is desirable to try and
      keep to a minimum the number of such services. This statement
      is true for the R&D community but is also highly likely to be
      valid for the general European industry.

    - There are two publicly available technological standards
      that can be used by open communities, such as the R&D
      community and public service providers: the X.400(1984 and
      1988) recommendations and the Internet RFC 822 / MIME / PEM
      standards.

    - There is an established very large global user base of
      Internet RFC 822 and X.400(1984) messaging services. Both
      services have their own momentum within different parts of
      the user community, both are still developing and growing
      fast.

   The report concludes that X.400(1988) will be the preferred protocol
   for inter organizational connection for European industry and
   government and parts of the European R&D community.  RFC 822 / MIME /
   PEM will be the preferred protocol suite for inter-organisational
   connection for the Internet community and, as products are already
   widely available, it is the preferred protocol for parts of the
   European R&D community.

   The goal of European pervasive messaging - incorporating Industry,
   Government and Academia - would be best accommodated and reached by
   the establishment of a single messaging service.  However taking the
   above into account, this is not feasible, as X.400(84 and 88) and RFC
   822( and MIME) based services will be around for a long time to come.
   To increase the functionality of Wide Area E-mail services there is a
   clear necessity to:

    - migrate RFC 822 services to a RFC 822 / MIME / PEM service.
      A MIME based service offers more functionality to the user
      than a plain RFC 822 service.

    - migrate existing X.400 services to a X.400(1988) service.



RARE WG-MSG Task Force 88                                       [Page 4]

RFC 1616     X.400(88) for European Academics and Research      May 1994


      Due to the lack of scalability of the X.400(1984) service in
      terms of extra functionality, it will become increasingly
      difficult to meet the needs of research users of existing
      X.400(1984) services unless an X.400(1988) service is put
      into place.

    - provide a transparent gateway between X.400(1988) and RFC
      822/MIME/PEM. For the European R&D community it is essential
      to have a transparent gateway between the X.400(1988) service
      and the RFC 822 / MIME / PEM service, thus ensuring
      connectivity between these two services with a maximum
      functionality.

   Such a gateway is technically feasible and it is an essential part of
   an unified E-mail service. Without such a standardised gateway the
   overall E-mail service would deteriorate.

   The lack of open standards for the PC LAN messaging systems
   discourages their use as 'backbone' messaging technologies within
   open communities. However the products that these systems deliver to
   end users ensures that their already large share of the messaging
   market will continue to exist for some time. Thus it is also
   essential that strategies that allow these systems to be 'seamlessly'
   integrated within the global messaging community are put in place.
   Not least due to the indications that the main messaging vendors are
   developing X.400(1988) and RFC 822/MIME gateways, a strategy to link
   these systems together via X.400 and RFC 822 should be developed.

   The report concludes with a set of recommendations, the main one
   being the establishment of a X.400(1988) European pilot messaging
   service for the R&D community. This pilot should include the
   establishment of a transparent gateway service between X.400(1988)
   and RFC 822/MIME. The goal of a European pilot is to ensure the
   successful deployment of a European wide operational X.400(1988)
   service that is pervasive and meets the needs of users. By collecting
   together the issues related to the establishment of a European
   X.400(1988) service, this report acts as a focal point and stimulant
   for discussion on this topic within the R&D community. In the report
   a summary of the benefits and problems of each of the above messaging
   technologies within the context of achieving a global messaging
   service, of which the R&D community is one part, is presented.
   Further the document identifies issues, strategies and
   recommendations related to the migration and coexistence of these
   technologies within the scope of mainly the European R&D community
   but also in relation to other messaging communities. A cost / benefit
   analysis on the establishment of a European wide pilot X.400(1988)
   messaging service is also presented. Finally a reading list of
   references related to this subject has been compiled.



RARE WG-MSG Task Force 88                                       [Page 5]

RFC 1616     X.400(88) for European Academics and Research      May 1994


   The report does not include any recommendations on development and
   deployment of RFC 822 / MIME / PEM related (pilot) services, as these
   are outside of the scope of the Task Force. However, since the report
   shows that both X.400(1988) and RFC 822 / MIME / PEM will be
   developed and used within the European R&D community, such a pilot
   should also be considered.

3.  Framework for the report

   With the belief that user demands for new messaging services such as
   Multimedia and Secure Messaging would develop, the RARE community
   (together with other communities; most notably the Internet
   Engineering Task Force (IETF)) has over the preceding years
   experimented in new messaging and related technologies.  Experiments
   and pilots, have been performed in messaging services e.g., as
   recommended by CCITT X.400(1988) and Directory Services based upon
   the CCITT X.500(1988) recommendations.

   The results of such pilots and experiments indicate that it is now
   opportune to commence a pilot X.400(1988) messaging service for the
   European R&D community. The major goals of the pilot being, to

    - establish a large scale European wide pilot messaging
      service based on X.400(1988).

    - collaborate with and facilitate the commencement of similar
      pilot services within diverse communities; both R&D and non-
      R&D (e.g., commercial ADMDs and PRMDs, etc.); both European
      and non-European (e.g., North American , Asian, etc.).

    - encourage and assist the development and deployment of a
      wide variety of commercial and public domain X.400(1988)
      messaging products that meet the user's needs, for instance
      X.400(1988) products such as User Agents (UAs), Message
      Stores (MSs), Message Transfer Agents (MTAs) and gateways
      between X.400(1988) services and other widespread messaging
      services i.e., RFC 822, Mail-11 and proprietary.

    - prove that such a service and products efficiently meets the
      existing and expected demands for new messaging services by
      European R&D users. And as such determine the steps for a
      European deployment of an operational X.400(1988) messaging
      service.

    - determine the needed steps to facilitate migration for the
      existing operational R&D X.400(1984) based messaging service,
      as represented by the R&D MHS service (the former COSINE
      MHS), RFC 822 / MIME / PEM based messaging services and the



RARE WG-MSG Task Force 88                                       [Page 6]

RFC 1616     X.400(88) for European Academics and Research      May 1994


      HEPnet / SPAN Mail-11 based messaging service to an
      operational X.400(1988) messaging service. It is self evident
      that during such migrations, transition steps must be
      included that allow a period of coexistence, at the highest
      possible service level, between X.400(1988), X.400(1984), RFC
      822 / MIME and HEPnet / SPAN Mail-11 services.

    - determine the needed steps that allow proprietary messaging
      systems, that are widely deployed within the European R&D
      community to be integrated at as high as possible service
      level, by an X.400(1988) infrastructure.

   This report identifies the issues involved in such a pilot service.
   It is not a concrete proposal for such a project but the report
   discusses advantages and disadvantages, costs and enefits and
   migration issues for deploying a X.400(1988) service. As such it is a
   discussion and feasibility paper on the creation of a large scale
   European wide pilot X.400(1988) messaging service for the European
   R&D community.

4.  Present situation of European Messaging

4.1. Messaging services

   Electronic messaging within Europe can be viewed as a number of
   messaging services communities. Three important communities comprise,

    - Commercial e-mail networks,
    - Research e-mail networks and
    - PC LAN messaging systems.

   Commercial e-mail networks are classified as either ADMDs or PRMDs.
   ADMDs and PRMDs are operating in nearly every European country.

    - ADMD services (or public commercial e-mail services) are
      provided by over 50 service providers which have
      interconnected using the X.400(1984) protocols. The topology
      between these ADMDs, although not yet 'mesh', can be stated
      as progressing quite rapidly to this optimum goal. However
      there is still a way to go before ADMDs provide full European
      connectivity.

    - PRMDs (or private commercial e-mail service providers) have
      interconnected to ADMDs and other PRMDs predominantly using
      the X.400(1984) protocols but also with proprietary
      protocols.





RARE WG-MSG Task Force 88                                       [Page 7]

RFC 1616     X.400(88) for European Academics and Research      May 1994


   Research networks are providing messaging services in every European
   country. These R&D service providers are operated as either ADMDs or
   PRMDs and are using both X.400(1984) protocols and Internet RFC 822
   protocols to connect to each other.

   Moreover, there are also large R&D communities (i.e., HEPnet and
   SPAN) using proprietary protocols (i.e., DECnet Phase IV and Mail-11)
   as their main messaging systems. The DECnet IV based communities are
   now migrating to DECnet Phase V (OSI connectionless protocol stack),
   which provides X.400(1988) (plus X.400(1984)) as a major messaging
   system.  In general, all these services are totally interconnected.
   As such it is a statement of fact that there exists within the
   European R&D community, two parallel interconnected messaging
   infrastructures based upon X.400(1984) and RFC 822. However
   interconnections between the R&D messaging community and the majority
   of the European commercial service providers use the X.400(1984)
   protocols.

   It is also clear that the commercial world mostly makes inter-
   organizational messaging interconnections using the X.400(1984)
   protocols. And also that the commercial messaging world is not as
   totally interconnected as the R&D messaging community.  Finally, for
   a number of commercial and public organisations there is often a
   mandatory requirement to use X.400 for messaging interconnections.

   The usage of PC LAN messaging systems is increasing very rapidly
   within the academic and commercial communities. In general, PC LAN
   messaging services within both communities do not use X.400(1984) or
   RFC 822 messaging systems but systems based upon proprietary
   protocols. The PC LAN messaging systems can be considered more as
   'Islands of Messaging' that gateway to the commercial and R&D
   messaging services by using X.400(1984) or RFC 822 gateways. PC LAN
   messaging systems within commercial organisations connect to
   commercial service providers also via proprietary protocols. The PC
   LAN messaging services, although probably comprising the largest
   number of users, are in general poorly integrated with the global
   messaging service (The Dutch, UK and Italian academic communities
   confirm that there appears to be many such 'Islands' of PC LAN
   messaging systems within their networks.).

4.2. Requirements for messaging

   Experience with existing global e-mail services has proven that with
   the increased use of messaging, there follows an awareness of extra
   requirements for related services. These requirements can be
   classified into 'User based Requirements' and 'Service Provider based
   Requirements' to either support, or exploit, high quality messaging
   services. These requirements are elaborated upon within this chapter.



RARE WG-MSG Task Force 88                                       [Page 8]

RFC 1616     X.400(88) for European Academics and Research      May 1994


4.2.1. User Oriented

   The only thing a user requires is an easy to use, well integrated,
   user interface to electronic mail. Usually the user does not care
   what protocol is used. However there are certain inherent
   requirements to the functionality that can be identified as user
   requirements. The main user requirements identified are:

   - Distribution Lists (DLs)

      A widely perceived omission from the X.400(1984) recommendations
      was the lack of support of DLs. Distribution lists allow users to
      enlist themselves onto electronic mail expander lists
      (distribution lists). A message to such a distribution list will
      automatically, and without significant delay, be sent on to anyone
      whose electronic mail address is on that list. Such a list can be
      a public list, that is meant for discussions on a specific
      subject, much like a sort of "magazine". However the list can also
      be a "closed" list, containing only a selected set of people who
      need to communicate privately, e.g., a project-team.

   - Multinational language and Multimedia support

      European users have for many years been frustrated in their
      inability to use their national character sets when communicating
      using messaging systems. The problems within e-mail systems that
      were causing this character set frustration are at their base the
      same problem that would get in the way of Multimedia messaging
      like:

         - lack of binary data support
         - lack of standardised encoding schema's
         - definition of multiple body-parts

      The enormous potential of Multimedia systems and services
      (especially within the commercial community as evidenced by the
      enormous press publicity and mega-mergers positioning companies to
      exploit this technology but also within the government spheres
      i.e., the U.S.A. Government's 'Information Superhighway'
      initiative) has acted as a spur to make rapid progress in solving
      the problems in this area.

   - White pages Directory Service

      A white pages directory service provides a unique but very basic
      and important service; a way to store and find information about
      people and resources that is analogous to a telephone service's
      paper based directory i.e., White Pages. User's E-mail addresses



RARE WG-MSG Task Force 88                                       [Page 9]

RFC 1616     X.400(88) for European Academics and Research      May 1994


      can be stored for subsequent retrieval by E-mail systems.

   - EDI

      EDI today is not extensively used within the academic environment.
      However there is a distinct potential within the academic
      community to reduce costs and improve services with EDI. Potential
      EDI uses could be,

         - EDI between universities
         - EDI between universities and government
         - EDI between universities and lower level educational
           institutions (e.g., student records)
         - Commercial EDI using the Internet as an infrastructure.

      The significance of maintaining end to end integrity (especially
      security aspects) of the EDI messages mandates that no gateways
      should be used between originator and recipient.

   - Support of Security services

      E-mail as it is currently used is far from secure. To allow for
      serious usage of E-mail security issues need to be addressed,
      like:

         - integrity; making sure that the message is transferred
           intact, without any changes or additions.
         - encryption; making sure the message content is only
           decipherable by the intended recipient.
         - authentication; making sure that the originator and/or
           recipient are authenticated.

4.2.2. Service provider viewpoint

   The task force believes the following points as being the most
   significant service provider requirements:

   - Network Management

      This area is still very new, in terms of offering standardised
      protocols, services and products for management. However a minimum
      'goal' is to provide for central management functions that will
      allow providers to offer a better quality of service.  There is
      presently ongoing work within the IETF Working Group MADMAN to
      define SNMP monitoring and managing of E-mail systems, gateways
      and X.500 directory systems. A number of management areas that
      need to be worked upon include: QOS, Service Level Agreements
      (SLAs), Multiple system queue management, Accounting, Routing Co-



RARE WG-MSG Task Force 88                                      [Page 10]

RFC 1616     X.400(88) for European Academics and Research      May 1994


      ordination and Message Tracing.

   - Support of MTA routing

      Dynamic routing from MTA to MTA, relieves the necessity to
      maintain large routing tables, especially within a large PRMD, or
      community of PRMDs (like the R&D MHS community).

   - Address mapping between RFC 822 and X.400

      The widespread use of X.500 or DNS for mapping, allows a reduction
      of manpower for centrally co-ordinating globally consistent
      X.400-to-RFC-822 mapping tables and distributes the responsibility
      for updating the mapping rules. This should allow mapping rules to
      change when needed and to be available immediately.

   - UA capabilities registration

      The use of the directory to register UA capabilities for
      X.400(1988), X.400(1984) and RFC 822 / MIME / PEM systems is a
      very desirable benefit for users in terms of speeding the
      deployment of new messaging services (e.g., Multimedia Messaging).

4.3. Messaging capabilities

   Due to the problems of gatewaying within a multi-protocol messaging
   environment, the great majority of R&D E-mail users are reduced to
   using only InterPersonal Messaging (IPM) services based upon the
   exchange of message body parts using CCITT character set IA5 (US
   ASCII).

   Within the R&D community recent work to meet user requirements for
   non ASCII messaging services - as documented above - has resulted in
   enhancements to the messaging services based upon RFC 822 protocols.
   The enhancements provide Multimedia support via the Multipurpose
   Internet Mail Extensions (MIME) and the prospect in the very near
   future of secure messaging via Privacy Enhanced Mail (PEM).
   Deployment of the MIME enhanced RFC 822 based services, via
   distribution of software and the setting up of the needed
   organisational structures, has commenced. The PEM enhancements are in
   a large scale pilot phase e.g., VALUE PASSWORD project.

   In the case of X.400(1984) the usage of non ASCII body parts is
   mostly effected by bilateral agreement between recipient and
   originator, through use of body part 14. In practice this restricts
   the exchange of non ASCII body parts to those cases where the
   recipient and the originator use the same bilateral agreement or else
   the originator includes an ASCII message explaining the included



RARE WG-MSG Task Force 88                                      [Page 11]

RFC 1616     X.400(88) for European Academics and Research      May 1994


   content type. Besides IPM there is a growing usage of EDI on top of
   X.400(1984).

   With the above X.400(1984) deficiencies in mind, X.400(1988) has been
   specified by the CCITT / ISO to meet new user demands.  X.400(1988)
   provides support for various different body parts, enhanced security
   features, international character set support capabilities and
   support of X.500 Directory Services. Due to the technological
   potential of these standards to satisfy user needs for new messaging
   services, the R&D community has been experimenting and piloting
   X.400(1988) and X.500(1988) services.  As there is a strong
   dependency of X.400(1988) messaging upon X.500(1988) directory
   services, the necessary precondition to supply these user demands is
   a deployed and operational X.500(1988) directory service. Piloting
   and deployment of the X.500(1988) directory service within the R&D
   community has been successfully initiated and co-ordinated by the
   COSINE and the VALUE PARADISE projects.

   Similarly, secure messaging has been addressed by the VALUE PASSWORD
   project and the RARE and IETF communities. Work to solve problems
   related to directory support of X.400(1988) messaging has been
   pursued within the IETF and RARE. The relevant RARE and IETF work
   groups (e.g., RARE WG-MSG, IETF MHS-DS, etc.) have also worked to
   produce any needed enhancements to the base X.400(1988) and
   X.500(1988) standards.  Last but not least it should not be
   overlooked that X.400(1988), as compared to X.400(1984), provides a
   comprehensive basis for gatewaying to and from RFC 822 / MIME / PEM
   and PC LAN messaging services. To that respect the IETF has defined
   standards for gatewaying Multimedia mail between RFC 822 / MIME / PEM
   and X.400(1988). As RFC 822 / MIME / PEM is now being deployed on the
   Internet, deployment of X.400(1988) services is needed to assure
   multimedia and secure messaging connectivity for the European R&D
   community.

5.  Possible solutions for providing globally pervasive messaging

   As can be now seen, a correlation of the present situation to the
   requirements of the user, shows that the current messaging services
   do not match the needs of users. To try to meet these needs a number
   of developments within various messaging technology areas are
   occurring. The following messaging technological areas, due to the
   present installed user base within the R&D community, are considered
   relevant:

      - PC LAN E-mail systems such as Lotus cc:Mail, Microsoft Mail
        and Novell MHS
      - RFC 822 / MIME / PEM E-mail services
      - X.400(1988) messaging services



RARE WG-MSG Task Force 88                                      [Page 12]

RFC 1616     X.400(88) for European Academics and Research      May 1994



   Ongoing developments within each of the above technological areas
   provide new messaging options for the R&D community. The ability of
   each technological area to provide solutions for user and service
   provider requirements is summarised within this chapter.

5.1. PC LAN E-mail systems

   Currently the usage of PC LAN E-mail systems is mostly for internal
   communication within an organisation. External connections, if
   present at all, to public service providers or other organisations is
   mostly through gateways to X.400(1984) or RFC 822. The use of a PC
   LAN E-mail system in terms of an infrastructure for interconnecting
   E-mail systems of different hues is not common within the Research
   community.  Recent experience, from amongst others the Dutch Research
   network - SURFnet - [14] and the Norwegian Directorate for Public
   Management - Statskonsult - [18], has shown that a number of problems
   (i.e., limited functionality, high operational management cost, etc.)
   can be expected should these PC LAN E-mail systems be used as an E-
   mail infrastructure. (The use of native X.400 protocols for PC LAN
   E-mail systems would avoid the usage of gateways and would thus
   alleviate many of these problems.) A summary of those problems and
   some relevant issues follows:

   -  Interconnecting heterogeneous PC LAN messaging systems

      One very distinct benefit for E-mail users of all hues is the
      potential to integrate heterogeneous PC LAN messaging systems with
      a minimum loss of service (e.g., multimedia services) by
      connecting them via X.400(1988) (or RFC 822/MIME/SMTP).
      X.400(1988) is already being used, or under active development,
      for connecting together PC LAN messaging systems in a number of
      environments (e.g., Apple Macintoshes, DEC, Microsoft, Lotus,
      etc.). This tendency to gateway PC LAN messaging systems via
      X.400(1988) will increase and is one of the benefits that
      X.400(1988) brings to global multiprotocol messaging.

   - Multimedia and binary data support

      The benefit of E-mail systems using these PC LAN systems is that
      the user interfaces are usually well integrated in the users
      standard working environment. Using a proprietary protocol these
      systems allow not only text (ASCII) but also binary, word
      processor, video, audio and other types of files to be
      transported. To reap the benefits of this multimedia / binary data
      transfer it would normally require that the same type of gateway
      is used by sender and receiver. Transporting these same files to
      another type of PC LAN E-mail system is not possible through the



RARE WG-MSG Task Force 88                                      [Page 13]

RFC 1616     X.400(88) for European Academics and Research      May 1994


      current gateways without some information loss. In effect PC LAN
      E-mail system's X.400 (or RFC 822) gateways from different vendors
      perform acceptably only for text body parts.  True heterogeneous
      multimedia PC LAN messaging needs gateways to X.400(1988)'s
      service.

   - Application Programming Interfaces

      To help solve the problem of portability for Mail Enabled
      Applications Microsoft, Lotus, Novell, XAPIA and X/OPEN have been
      working on a number of standards for the Application Interface to
      mail transport protocols (i.e., Mail Application Programming
      Interface - MAPI, Vendor Independent Messaging - VIM, Common Mail
      Calls - CMC). These efforts are structured independent of the
      existing 'Wide-Area' or inter organisational E-mail protocols of
      X.400(1984) and RFC 822. However the MAPI, VIM and CMC efforts,
      due to their proposers (respectively Microsoft, Lotus and X/OPEN),
      do look like they will provide the stimulant to various software
      developers to develop more portable applications plus allow the
      rich functionality of X.400(1988) to be accessed by these
      applications thus reducing the need for gatewaying to X.400(1988).

   - Security

      As the PC LAN E-mail systems require gateways for connectivity,
      they pose a problem with regard to encrypted messages.  Gatewaying
      of secure messages is normally not possible. The gatewaying of
      secure messages is a general problem of gatewaying from one mail
      system to any other system and is not specific to PC LAN E-mail
      systems.

   - Directory Services

      To date mostly proprietary directory services have been deployed
      that do not match the needs of the users in terms of access
      controls for data, distributed and decentralised across
      organisations. X.500 based services promise solutions to such
      needs. As a result various suppliers have announced support of
      X.500 directory services for their E-mail products. However,
      should these interfaces be delayed then support of an inter
      organisational 'White Pages' services requires either,

      - directory information exchange products (i.e., directory
        gateways) deployed between a proprietary system and an X.500
        directory system






RARE WG-MSG Task Force 88                                      [Page 14]

RFC 1616     X.400(88) for European Academics and Research      May 1994


      - gateways between de-facto market based proprietary
        standards, such as Retix Directory Exchange (DX) or
        Soft*switch's Directory Synchronisation (DS), and X.500
        protocols

      - duplicated directories i.e., one proprietary and one X.500
        need to be operated.

   It should be stressed that gatewaying mechanisms and products are
   often problematic due to the lack of an open standard on the
   proprietary messaging system and or directory system. (As an aside it
   is thus essential to establish an operational X.500 infrastructure,
   including E-mail user interfaces that can transparently access this
   Directory Service, as soon as possible.)

5.2. RFC 822, MIME and PEM services

   RFC 822 messaging services are widely deployed within the R&D
   community. There is ongoing work to extend RFC 822 to meet user
   requirements. Some of these extensions are elaborated upon within
   this chapter.

   - Distribution lists

      RFC 822 allows for the usage of DLs. Management of DLs is not
      (yet) standardised.

   - RFC 822 multimedia messaging via MIME

      With the arrival of MIME, the RFC 822 service has an additional
      protocol standard that addresses Multimedia messaging very
      comprehensively. In terms of user needs, MIME now allows messaging
      body parts to comprise multinational character sets and binary
      data. Multi-body part messages are also supported.  One of MIME's
      real strengths, in terms of deployment within the existing RFC 822
      service, is that it achieves its goals by overlaying its services
      over the existing RFC 822 service and thus mandating no changes to
      the in place RFC 822 infrastructure. This greatly simplifies the
      MIME deployment.

   - RFC 822 secure messaging via PEM

      Just as MIME has brought multimedia messaging to RFC 822 services,
      Privacy Enhanced Mail (PEM) is bringing secure messaging to RFC
      822 services. PEM also has used the same approach as MIME to
      deploy secure messaging within RFC 822 services; overlay PEM
      services over the existing RFC 822 services without requiring
      changes to the RFC 822 infrastructure. PEM brings confidentiality



RARE WG-MSG Task Force 88                                      [Page 15]

RFC 1616     X.400(88) for European Academics and Research      May 1994


      and integrity of messages to RFC 822 users. However a number of
      problems with PEM, and X.400(1988) as well, still need to be
      solved before secure messaging can be considered to be an
      operational service.  These problems are independent of the secure
      messaging protocol (i.e., PEM or X.400(1988)) and deal mainly with
      distribution of secret keys to the end users. There is very active
      work going on within the IETF to solve these problems.

   - MIME and PEM

      There are still problems for messages that are simultaneously a
      multimedia message, as per MIME, and a secure message, as per PEM.
      A PEM encoded MIME message does not allow gatewaying to other
      messaging environments and therefore does not allow any of the
      features inherent within MIME to be exploited along the message
      path. A MIME message that contains PEM encoded body parts can be
      gatewayed but the integrity of the entire message is then not
      guaranteed. This is a real deficiency of both existing approaches
      as it is essential that users are able to simultaneously use
      multimedia and secure messaging. However, once again, the IETF is
      working very hard on solving these problems and solutions can be
      expected, although the solution of the gatewaying of PEM messages
      to other E-mail systems is still unclear.

   - Dynamic and distributed messaging routing via the Domain Name
     System (DNS)

      RFC 822 messaging benefits greatly by having a dynamic and
      distributed mechanism to assist in message routing i.e., Domain
      Name System (DNS). With the support of the DNS, RFC 822 MTAs are
      able to directly route to other RFC 822 MTAs and thus deliver
      messages with a minimum of delay. In practice mail often still
      traverses multiple RFC 822 MTAs for a number of reasons e.g., Mail
      Hubs provided for users who turn their machine off when they go
      home, Firewall Hubs for security reasons, etc. However it is
      commonly accepted that between RFC 822 mail hubs the delivery of
      messages is very fast. Typically resolution of routing decisions
      occurs in less than one minute and very often within seconds. In
      general the DNS service is a very valuable service that functions
      well in practice.

   - Support for Character sets

      Together with the MIME specification for content types, an
      extension for RFC 822 headers was defined that allows for usage of
      multiple character sets in names, subject etc. in RFC 822 headers
      [9]. This allows (European) users to use their preferred character
      set to support their language not only in the contents of a



RARE WG-MSG Task Force 88                                      [Page 16]

RFC 1616     X.400(88) for European Academics and Research      May 1994


      message but also in the headers.

   - MIME capable gateways

      It is clear that to provide a seamless service to all users
      regardless of whether they are using RFC 822 or X.400 services, a
      widely available set of well run and standardised RFC 822 to X.400
      gateways must be in place. For InterPersonal Messaging (IPM) based
      on US ASCII there are already a large number of such standardised
      (i.e., X.400-to-RFC 822) gateways deployed. To ensure seamless
      gatewaying between MIME and X.400 multimedia users, these existing
      text based gateways must be either upgraded to or replaced with
      multimedia messaging gateways. A number of proposed Internet
      standards to solve these problems, for both X.400(1984) and
      X.400(1988) and generated within the MIMEMHS work group of the
      IETF, have been completed [4].

   - Access to fax, teletex, telex or physical delivery

      For the moment, there is no standardised way for RFC 822 users to
      access gateways to the above services except by indirect access to
      X.400(1988) systems (i.e., concatenated gateways of RFC 822 to
      X.400(1988) and then onwards to the appropriate X.400(1988) Access
      Unit). Although even this indirect method would require some
      further work on standardising mappings between RFC 822 addresses
      and X.400(1992)'s X.121 addresses. As well some experiments within
      the RFC 822 world are occurring on routing fax messages.

   - Operational support

      Generally, RFC 822 messaging services are delivered on a 'best
      effort' basis and thus service level agreements requesting
      stringent response times to operational problems or guaranteed
      delivery times for messages are difficult to agree. This phenomena
      might be a result of the distribution and delegation of authority
      to organisations updating the RFC 822 MTA's routing mechanism
      i.e., DNS. As a result it makes it hard to reach a 'one stop
      shopping' agreement for RFC 822 messaging services.

   - Notifications

      The RFC 822 service provides a minimum amount of base protocol
      support for messaging users. It could be argued that the RFC 822
      protocol is simplified by this choice and thus software that
      implements the standard need be smaller in size and easier to
      build. However some features e.g., delivery & receipt
      notifications and UA capabilities registration, would be commonly
      accepted as being desirable from a user standpoint and thus



RARE WG-MSG Task Force 88                                      [Page 17]

RFC 1616     X.400(88) for European Academics and Research      May 1994


      desirable extensions to RFC 822. Some operational problems
      relating to reliability could be minimised by technology that has
      a standardised support for positive and negative notifications of
      messages. RFC 822, as compared to X.400, technology does not yet
      support positive notifications (although there is work starting
      within the IETF to extend RFC 822 to support delivery
      notifications). However within RFC 821 transport system (i.e.,
      SMTP) there are standardised negative notifications that work
      well.  Alternatively X.400 technology, deployed over TCP/IP (using
      STD 35, RFC 1006), may help to address the lack of adequate
      service quality - notification support - when using E-mail within
      the Internet.

   - Portability of RFC 822 products

      There are only a few mailbox formats in general use by RFC 822
      software, one being the 'bin/mail' format and the other 'MH'
      format.  This 'standard' mailbox format is a definite benefit for
      RFC 822 users as it allows them to change RFC 822 UAs (e.g.,
      upgrading to MIME RFC 822 UAs) whilst not compromising or
      converting their existing archived mail, which may comprise 1000s
      of archived messages.

   - System support for RFC 822 products

      Normally, RFC 822 MTAs and UAs come pre-installed on UNIX
      workstations. As a result, users are spared the effort of
      installing RFC 822 MTA software. If for some reason, a user or
      mail administrator should wish to install a different MTA or UA to
      the pre-installed system, there exists a large number of easily
      available (i.e., via widespread distribution amongst many FTP and
      other information servers) public domain RFC 822 MTAs and UAs.

      Both of the above points encourages the spread and eases the
      installation of software for the RFC 822 messaging service and in
      many ways explains the size and importance of the installed base
      of RFC 822 systems. To illustrate the extent of RFC 822 / MIME
      products, a non-comprehensive list of available MIME enhanced RFC
      822 products follows; ELM 2.4, MH 6.8, Sun Mailtool, HP Mpower
      Desktop, Lotus cc:Mail (unconfirmed), Zcode Zmail, Frontier
      Super-TCP for Windows, PMDF (VAX VMS), Pine, C-Client (library
      routines), Metamail (viewer only), Andrew-MIME gateway.

   - UA capability registration

      The IETF MHS-DS working group has defined how X.400 and RFC 822
      User Agent capabilities can be stored in X.500 directory services.
      This work is still ongoing.



RARE WG-MSG Task Force 88                                      [Page 18]

RFC 1616     X.400(88) for European Academics and Research      May 1994


5.3. X.400 - 1984 and 1988

   X.400(1988) substantially upgrades and enhances the X.400(1984)
   standards. A number of new functions have been incorporated within
   X.400(1988). A description of the most important features of X.400 -
   1984 and 1988 - follows.

   - Notifications

      X.400(1984) provides four notifications - positive and negative
      delivery notifications and positive and negative receipt
      notifications. These notifications allow users to ensure
      successful message delivery or that the message was read. The
      delivery notifications are also used by service operators in their
      fault escalation procedures.

   - Binary Data Transfer

      X.400(1984) allows binary data transfer to be transported without
      the necessity of character encoding. The ability to transfer files
      of whatever type is a valuable end user service.  As well the lack
      of any necessary character encoding allows users to utilise the
      received data without needing any character decoding software.

   - Multiple Body Parts

      The ability to send multiple body parts within one message gives
      the user the ability to send multiple logical components within
      one message. This is a natural mechanism for users as it mirrors
      the real life situation of being able to send within one message,
      a letter, a word processor file, a spreadsheet file, etc.

   - Feature rich messaging model

      The features of X.400 are very rich. This provides benefits for
      users as vendors are able to provide applications that can utilise
      these extensive features in an interoperable manner due to the
      standardisation of the features within X.400.

   - Clear messaging model

      X.400(1984), as one of its most wide reaching achievements, has
      popularised within the market a consistent and clear model to
      describe message handling systems. The decomposition of a message
      handling system into UAs, MSs, MTAs, MTS - ADMDs and PRMDs and
      Access Units / Gateways has proved to be an extremely useful tool
      for users and vendors to understand and communicate their
      messaging needs or solutions.



RARE WG-MSG Task Force 88                                      [Page 19]

RFC 1616     X.400(88) for European Academics and Research      May 1994


   - Multiple lower layer networks

      X.400 has embraced the concept that there are different technology
      lower layer networks. This concept even allows multiple logical
      networks of the same technology to be supported. X.400 allows the
      messaging service to fully function even though the underlying
      network is varying. In the real world of a non-uniform network
      layer this is an extremely powerful capability.

   The list of major X.400(1988) extensions to X.400(1984) follows:

   - Distribution Lists (DLs)

      A powerful mechanism for arbitrarily nested Distribution Lists
      including the ability for DL owners to control access to their
      lists and to control the destination of non delivery reports.  The
      current endemic use of DLs in the R&D community makes this a
      fundamental requirement for any service. X.400(1988) uses X.500 to
      provide a standardised support for DLs, although there have been
      some needed standardised enhancements relating to the CCITT
      defined DLs by the IETF MHS-DS work group. The provision of
      powerful nesting capabilities plus management mechanisms for DL
      owners within X.400(1988) DLs are features providing attractive
      benefits for users and DL managers.  There is already 'running
      code', via the COSINE Explode project which is implementing the
      MHS-DS based enhancements. The project builds upon experience
      gained within a number of networks e.g., JNT and provides:

         - implementation of MHS-DS enhancements related to the
           X.400(1988) DLs
         - archiving of messages received by a DL.
         - access by users to the DL archive via e-mail.
         - subscription to a DL by users via e-mail.

   - Message Store (MS)

      The Message Store provides a server for remote UAs on workstations
      and PCs enabling messages to be held for their recipient, solving
      the problems of non-continuous availability of such UAs. The
      message store allows mobile workers, small offices and local
      schools to become active messaging users in a cost effective
      manner. The message store provides powerful selection mechanisms
      allowing the user to select messages to be transferred between the
      store and the workstation. This facility is not catered for
      adequately by the P3 protocol of X.400(1984) and provides a major
      incentive for transition.





RARE WG-MSG Task Force 88                                      [Page 20]

RFC 1616     X.400(88) for European Academics and Research      May 1994


   - X.500 Directory names

      Support for use of Directory Names in MHS will allow a transition
      from use of O/R addresses to Directory Names when X.500
      Directories become widespread, thus removing the need for users to
      know about MHS topological addressing components.

      The ability for X.400(1988) messages to contain directory names
      instead of the O/R addresses is a powerful feature for users as it
      frees them of the necessity to insert O/R addresses containing
      routing information but allows them to insert the more natural
      directory names. However, the management of the large amounts of
      distributed data contained within the directory is problematic in
      that it involves a number of organisational issues and not just
      software issues. A number of X.400(1988) UAs which allow users to
      insert directory names instead of O/R addresses have already been
      developed.

   - Support for EDI

      Through the definition of Pedi, as defined in X.435, X.400(1988)
      offers integrated support for EDI messaging. The CEC TEDIS program
      has mandated X.400 as the main carrier for EDI, and standardised
      how EDI transactions are inserted into X.400 messages (i.e., Pedi
      and P2). This provides a strong incentive to provide native
      X.400(1988) services to users and applications thus encouraging
      commercial EDI traffic to migrate to X.400(1988).

   - Secure Messaging

      The provision of secure messaging services including
      authentication, confidentiality, integrity and non-repudiation as
      well as secure access between MHS components are important
      benefits for the R&D community. The base standards are adequate
      for security, however organisational and software issues need
      still to be solved. Organisational issues of globally scaling the
      distribution of secret keys is still unsolved. Software issues of
      how end users will be able to comfortably and securely input
      secret keys of length 512 -> 1024 bits into security software need
      to be solved.

   - Multimedia

      The definition of a number of additional body parts plus the
      ability to define new body parts (e.g., Word Processor formats,
      Excel documents, etc.) provides the basis for multimedia services
      over X.400(1988). As well, the newly defined General Text body
      part supports multinational character sets (except for ISO 10646)



RARE WG-MSG Task Force 88                                      [Page 21]

RFC 1616     X.400(88) for European Academics and Research      May 1994


      without the need for transmission encoding. However, unlike MIME,
      X.400(1988) is only specifying a standard for multimedia
      messaging. To achieve multimedia document exchange, there is a
      further text exchange standard such as ODIF, Hytime, etc., needed.

   - Character set support for extended addressing

      A highly desirable potential benefit for European R&D users is
      provided by the extended character set support(i.e., T.61) within
      addresses. Nearly all European languages, except for Greek and
      Cyrillic, are supported by the T.61 teletex encoding. Further
      extensions to X.400 for support of extended character sets has
      been defined by the RARE WG on character sets and RARE WG on
      messaging [15].

   - Physical Delivery Services

      This standardised method for a message to be delivered on a
      physical medium, such as paper, through the normal postal service
      is useful when trying to reach a very wide number of (non-
      electronically reachable) recipients. In effect this service
      provides an ability to 'go the last mile' and communicate with
      users previously not easily reachable e.g., farmers, etc.

   - General Extension Mechanism

      One of the major assets of X.400(1988) is the extension mechanism.
      This is used to carry most of the extensions defined in these
      standards, but its principal benefit will be in reducing the
      trauma of transitions to future versions of the standards.

      Provided that implementations of the X.400(1988) standards do not
      try to place restrictions on the values that may be present, any
      future extension will be relayed by these implementations when the
      extension is not critical, thus providing a painless migration to
      new versions (1992 and beyond) of the standards.

   - UA Capability Registration

      With the extra functionality available to X.400(1988 and
      especially 1992) UAs (i.e., extra non-IA5 body parts, secure
      messaging, etc.) it is expected that the demand to register UA
      capabilities will increase. In that respect X.400(1988)'s ability
      to query X.500, where such capabilities would be stored, is a
      significant potential benefit for users.






RARE WG-MSG Task Force 88                                      [Page 22]

RFC 1616     X.400(88) for European Academics and Research      May 1994


   - X.500 support for MTA routing

      The piloting of X.500 to support MTA routing within the R&D
      community has already commenced, on a small experimental scale,
      via the Longbud project co-ordinated by the IETF MHS-DS work
      group. Some concrete benefits promised by X.500 based routing are:

      - routing based upon content types, security, transport stacks
        and other criteria allow optimum routing paths to a
        destination MTA to be chosen. (There is presently no such
        similar capability within the DNS).

      - allowing the routing information to be inserted and modified
        in a distributed manner reduces (if not eliminates) the
        necessity of central distribution of static routing tables.
        The consequent reduction in manpower to co-ordinate MTA
        routing plus the increase in scalability of the service
        allows a truly global messaging service to be put in place.

6.  Migration to X.400(1988)

   What is clear from the previous chapters is that;

      - The resources, human or financial, to operate multiple wide
        area messaging services connecting together independent
        organisations are high. As such it is desirable to try and
        keep to a minimum the number of such services. This statement
        is true for the R&D community but is also highly likely to be
        valid for the general European industry.

      - There are two publicly available technological standards
        that can be used by open communities, such as the R&D
        community and public service providers: the X.400(1984 and
        1988) recommendations and the Internet RFC 822 / MIME / PEM
        standards.

      - There is an established very large global user base of
        Internet RFC 822 and X.400(1984) messaging services. Both
        services have their own momentum within different parts of
        the user community, both are still developing and growing
        fast.

   From the above discussion, it is clear that the infrastructure
   services that have to be supported within these open communities, and
   especially within the R&D community, are RFC 822 / MIME / PEM,
   X.400(1984) and X.400(1988). X.400(1988) will be the preferred
   protocol for inter-organisational connection for European industry
   and government and parts of the European R&D community. RFC 822 /



RARE WG-MSG Task Force 88                                      [Page 23]

RFC 1616     X.400(88) for European Academics and Research      May 1994


   MIME / PEM will be the preferred protocol suite for inter-
   organisational connection for the Internet community and, as products
   are already widely available, it is the preferred protocol for parts
   of the European R&D community.

   The goal of European pervasive messaging - incorporating Industry,
   Government and Academia - would be best accommodated and reached by
   the establishment of a single messaging service.  However taking the
   above into account, this is not feasible, as X.400 and RFC 822 based
   services will be around for a long time to come. To increase the
   functionality of Wide Area E-mail services there is a clear necessity
   to:

      - migrate RFC 822 services to a RFC 822 / MIME / PEM service.
        A MIME based service offers more functionality to the user
        than a plain RFC 822 service.

      - migrate existing X.400 services to a X.400(1988) service.
        Due to the lack of scalability of the X.400(1984) service in
        terms of extra functionality, it will become increasingly
        difficult to meet the needs of research users of existing
        X.400(1984) services unless an X.400(1988) service is put
        into place.

      - provide a transparent gateway between X.400(1988) and RFC
        822/MIME/PEM. For the European R&D community it is essential
        to have a transparent gateway between the X.400(1988) service
        and the RFC 822 / MIME / PEM service, thus ensuring
        connectivity between these two services with a maximum
        functionality.

   Such a gateway is technically feasible and it is an essential part of
   an unified E-mail service. Without such a standardised gateway the
   overall E-mail service would deteriorate.

   The lack of open standards for the PC LAN messaging systems
   discourages their use as 'backbone' messaging technologies within
   open communities. However the products that these systems deliver to
   end users ensures that their already large share of the messaging
   market will continue to exist for some time. Thus it is also
   essential that strategies that allow these systems to be 'seamlessly'
   integrated within the global messaging community are put in place.
   Not least due to the indications that the main messaging vendors are
   developing X.400(1988) and RFC 822/MIME gateways, a strategy to link
   these systems together via X.400(1988) and RFC 822/MIME should be
   developed.





RARE WG-MSG Task Force 88                                      [Page 24]

RFC 1616     X.400(88) for European Academics and Research      May 1994


   To make migration to a X.400(1988) service feasible, extensive
   migration and coexistence options for various non-X.400(1988) users
   have to be developed. Main issue in each migration strategy remains
   the co-operation of the users. The migration needs to be user-driven,
   i.e., the users need to be convinced of the added functionality
   (versus the cost) of migrating towards X.400(1988). A detailed
   summary of the different issues and possible problems involved in the
   transition to a X.400(1988) based messaging service, with respect to
   what are commonly accepted as the four most important messaging
   services: RFC 822, MIME and PEM; X.400(1984); MAIL-11 and PC LAN
   messaging systems are presented in this chapter.

6.1. PC LAN E-mail systems

   To provide coexistence and migration the usage of gateways is
   unavoidable. The quality of these gateways, with regard to:

      - Transparency (gatewaying multimedia messages, transparent
        addressing)
      - Manageability
      - Reliability

   has to be improved. Ultimately through usage of APIs like MAPI and
   CMC, the users interface hopefully will become independent of the
   mail protocol that is used. It will then be expected to be possible
   to let the user retain his preferred mail user interface, while the
   protocol used migrates to X.400(1988).

   Via the use of these APIs it may be possible to access the full
   features of X.400(1988) while retaining a proprietary PC LAN UAs.
   This way a PC LAN can be easily connected to a X.400(1988) backbone.
   This usage of APIs to ease migration for end users should be
   encouraged.

   The migration of PC LAN E-mail systems will likely be driven by the
   commercial vendors of mail enabled applications, such as UAs, Work
   Group Systems, Task Flow Systems plus X.400(1988) MTAs and gateways
   able to serve these applications via these new APIs.

6.2. RFC 822, MIME and PEM services

   A migration from RFC 822 / MIME and PEM services to X.400(1988) needs
   to be formulated for those management domains that wish to effect
   this change. As well a long term transition and coexistence phase
   needs to be accommodated due to the existing base of RFC 822 users.
   An understanding of the issues involved in migrating from RFC 822 to
   X.400(1988) messaging services is essential before any rational
   decisions on migration can occur.  Certainly one, if not the main,



RARE WG-MSG Task Force 88                                      [Page 25]

RFC 1616     X.400(88) for European Academics and Research      May 1994


   issue in such a migration is that the migration must allow a
   transition period where maximum functionality between both services
   exists. Any migration must be aware that RFC 822 messaging services
   are a 'moving target'.

    - Ease of transition as perceived by an RFC 822 user mandates
      that the user's existing mail folders are converted into the
      new mail product's folder system flawlessly.

    - The RFC 822's user's e-mail address should remain the same
      even after a migration. (i.e., the user keeps the same address
      that has two different notation forms: X.400 and RFC 822).

    - Users contemplating a migration will be stimulated to do so
      if they experience no loss of service as regards MIME and
      X.400(1988) gatewaying; are still able to insert RFC 822
      style addresses into the X.400(1988) UA and are provided with
      high performance X.400-to-RFC 822 gateways.

    - The added connectivity provided by X.400(1984 or 1988)
      gateways to fax, telex, post etc. plus additional X.400 users
      that the user is able to reach easily (whilst not losing
      connectivity to RFC 822 addresses) plus the additional
      functionality of X.400(1988) possible when communicating with
      X.400(1988) users will also act as a stimulant to a
      migration.

    - The functionality provided by RFC 822 / MIME products will
      be the yardstick that an RFC 822 user compares an offered
      X.400(1988) product with. As such X.400(1988) products must
      provide some basic and important functions like: Character
      Set support via GeneralText; Multimedia capability via
      Extended Body Parts; low message delays within the seconds
      time scales and ease of configuration of products. At present
      there is no RFC 822 equivalent to X.400 delivery and receipt
      notifications and as such these functions are seen as extra
      functionality by the user.

    - A follow on to the extra functionality point above is that
      present RFC 822 users, most likely commercial users, that
      want to be able to use EDI or other mail enabled applications
      that need security, message audits and positive confirmations
      will be encouraged to migrate to X.400(1988). A decision to
      use X.400(1988) in this case would be especially attractive
      for those commercial RFC 822 users that are already operating
      multiple lower layer networks. As X.400(1988) accommodates
      multiple different network layers easily, the cost to migrate
      could be considered quite small.



RARE WG-MSG Task Force 88                                      [Page 26]

RFC 1616     X.400(88) for European Academics and Research      May 1994


6.3. X.400(1984) services

   A number of problems can be identified in a migration from
   X.400(1984) to X.400(1988). They are summarised as,

    - OSI supporting layers are mandatory in the ISO10021 MOTIS
      standard, while the support of the complete OSI stack (normal
      mode ) is optional in the otherwise equivalent CCITT
      X.400(1988) specifications. It is thus recommended that the
      migration from X.400(1984) should be straight to ISO 10021
      i.e., straight to use of the full OSI stack with normal mode
      RTS.

    - There is a negative impact on quality of service caused by
      implementation decisions related to the 'General Extension
      Mechanism'. To overcome this negative impact no minimal
      X.400(1988) MTAs, which relay the syntax but understand none
      of the semantics of extensions, should be used.

    - All X.400(1988) MTAs should generate reports containing the
      extensions that are present in the original message and route
      such reports through the DL expansion hierarchy where
      appropriate.

    - Choice of standards to be used within mixed X.400(1984 and
      1988) management domains needs to accommodate in one option
      the danger of undetectable routing loops from incorrectly
      configured routing entries and in another option the problem
      that systems that have fixed the routing loop problem may not
      all be consistently implemented due to ambiguities within the
      standards. The choice of which of these two options a
      management domain uses internally has no impact on external
      management domains.

    - DDA support is needed by X.400(1984) systems to address
      X.400(1988) Common Name Attribute users [2].

    - Minimum loss of service quality mandates that downgrading of
      X.400(1988) body parts to X.400(1984) bodyparts be done
      according to the MIMEMHS specifications [4].

    - To enhance connectivity to both X.400(1984 and 1988)
      management domains without degradation of X.400(1988)
      service, management domain entry points that support both
      X.400(1984 and 1988) are recommended.






RARE WG-MSG Task Force 88                                      [Page 27]

RFC 1616     X.400(88) for European Academics and Research      May 1994


    - Ensuring that no X.400(1988) MTAs transit via X.400(1984)
      MTAs. This allows no degradation of X.400(1988) service
      quality [17].

   The consequence of the last point is that the existing European
   Research X.400(1984) - formerly COSINE MHS - MTA RELAY backbone
   should be one of the first MTA communities to migrate to X.400(1988).

6.4. Mail-11 services

   The Mail-11 (also known as DECnet mail) e-mail service is the major
   e-mail service used within the High Energy Physics and Space Physics
   Analysis Networks (i.e., HEPnet and SPAN) and is the native e-mail
   service present on VMS operating systems. The Mail-11 service is
   considered the most popular service by the large HEPnet / SPAN
   community. Mail-11 provides also large and easy to use gateways to
   other E-mail protocols, like X.400 (84), RFC 822 (SMTP over TCP/IP,
   DECnet and X.25, BSMTP over NJE), and PC LAN E-mail services.

   Jointly with the "old style" Mail-11 UA, the DECnet Phase V (OSI
   CLNS) service provides the native capability to run X.400 (88) and
   X.400(1984) services. There is thus the potential for X.400 (88)
   services to become available as soon as the HEPnet / SPAN community
   migrates to DECnet Phase V. However the availability of VMS based UAs
   for the X.400(1988) service is still very limited and is thus forcing
   users to continue to stay with their Mail-11 UA (and thus the Mail-11
   service).

   Users in HEPnet / SPAN are demanding enhancements to their mail
   services to support multimedia and delivery / read receipt services.
   This is a strong driving factor for good X.400(1988) UAs to become
   available soon to allow users to properly use the available
   X.400(1988) service of DECnet Phase V.

7.  Benefits of migrating to X.400(1988) and the involved costs

   The actual as compared to the potential benefits of migrating from
   one's existing mail system to a new mail protocol is very dependent
   on good products, good organisation of the migration and a degree of
   commitment that the transition is worth the cost. Quantifiable and
   accurate cost / benefit ratios for such a migration are not possible
   within the decentralised European R&D environment and as such are not
   generated.

   We have in this chapter listed the benefits that such a migration to
   X.400(1988) achieves. We have also given an indication of the
   relative costs of such a migration. Provided that there are good
   products, and taken in conjunction with the recommendations of



RARE WG-MSG Task Force 88                                      [Page 28]

RFC 1616     X.400(88) for European Academics and Research      May 1994


   Chapter 8 and Appendices A and B, the task force is confident that
   these potential benefits will translate into actual benefits and be
   worth the costs incurred.

*Benefits*

   Below is a list of non-technically oriented benefits and the features
   of X.400(1988) that enable these benefits to occur. The benefit of,

    - efficient and innovative communication within Europe is
      assisted by establishing an X.400(1988) messaging service
      that integrates European industry, government and academia;

    - an increase in business efficiency by the use of EDI (for
      example automatic processing of business forms, exchange of
      business contracts, etc.) is enhanced by the security aspects
      of X.400(1988) i.e., non-repudiation, authentication,
      confidentiality, integrity plus secure access between MHS
      components.

    - allowing European users to communicate in their native
      European languages is brought about by the GeneralText body
      part of X.400(1988).

    - remote users and Small and Medium size Enterprises(SME)
      using e-mail for electronic commerce is encouraged by
      reducing the entry level costs for use of e-mail. An SME's
      use of Remote UAs in conjunction with a service provider's MS
      -instead of purchasing their own MTA - is accommodated by
      X.400(1988).

    - providing global messaging for all e-mail users, but
      recognising the existing market realities of heterogeneous e-
      mail systems, would be enhanced by the establishment of
      gateways to X.400(1988).

    - being able to recover costs by charging and accounting for
      messaging services back to users - this is especially
      important for commercial service providers - is brought about
      by the message auditing capabilities of X.400(1988).

    - communication with users that have no access to E-mail (for
      example if such users are defined within Distribution Lists)
      is enhanced by X.400(1988)'s support for gateways to physical
      delivery, fax, telex, teletex, etc.






RARE WG-MSG Task Force 88                                      [Page 29]

RFC 1616     X.400(88) for European Academics and Research      May 1994


    - building upon the existing X.400(1984) infrastructure (i.e.,
      reduction of establishment costs) is brought about by
      migrating the X.400(1984) infrastructure to X.400(1988).

    - a reduction in manpower (and thus costs) to manage a global
      messaging service is brought about by the messaging service's
      ability to utilise the global distributed directory for
      management information.

    - the messaging infrastructure to meet new user requirements
      is enhanced by the support for General Extensible Mechanism.

    - making E-mail more user friendly is brought about by a
      messaging service that allows the use of the more natural
      directory names in E-mail addresses.

    - increased effectiveness of messaging by the use of DLs is
      brought about by X.400(1988)'s support of powerful nesting
      capabilities and management for DLs.

    - an increase in global message delivery performance and
      reliability is enhanced by the ability of X.400(1988) to use
      X.500 for MTA routing.

    - more messages being successfully delivered to mobile or
      transient users is enhanced by the provision of the Message
      Store.

    - multimedia use is enhanced by the ability to define new body
      parts and to support multiple types of binary data such as
      audio and video.

    - establishing optimum and seamless conversion of messages
      based upon the capabilities of a user is brought about by the
      ability of X.400(1988) to act upon UA capabilities.

*Costs*

   The generic costs to establish an X.400(1988) pilot service can be
   broken down into:

       - a cost per backbone of RELAY MTAs (as used by the European
         research community - the former Cosine MHS service),
       - a cost per service provider,
       - a cost per organisation,
       - a cost per user and
       - a cost per user MTA for migrating to X.400(1988).




RARE WG-MSG Task Force 88                                      [Page 30]

RFC 1616     X.400(88) for European Academics and Research      May 1994


   To bring about the benefits, mentioned above, certain costs will be
   incurred and they are summarised below:

   - Cost per backbone of RELAY MTAs (as used by the European
     research community - the former Cosine MHS service)

         - The equipment costs of migrating backbone RELAY MTAs.

         - The establishment of some sort of organisational /
           project group to oversee a backbone RELAY MTA pilot.

      As most of the RELAY MTAs are already X.400(1988) capable, there
      is already a MHS Co-ordination service in place that could be used
      for this function and the number of backbone RELAY MTAs is less
      than 100 in number the cost for migrating the RELAY MTA backbone
      is considered relatively low.

   - Cost per service provider

         - If the RELAY MTA backbone (formerly Cosine MHS) is
           migrated towards X.400(1988), then the remaining cost
           for a service provider for migrating the infrastructure
           towards X.400(1988) is relatively low.

         - The operational costs for organisational issues, for
           example dealing with OID registrations, is low if
           national R&D service providers act as a clearinghouse
           for their own national R&D institutions e.g.,
           Universities.

   - Cost per organisation, end user and MTA

         - The operational costs of migrating end users and their
           MTAs in management domains to X.400(1988) are higher
           than the costs involved with migrating the
           infrastructure. This is due to the order of at least 10
           to 100 times more MTAs, as compared to the service
           providers, that would be involved with a migration to
           X.400(1988). As the infrastructure needs to migrate
           first, the costs for the end user MTAs can be reduced
           by profiting from the migration experience of the
           service providers.

         - The education and training costs for users and system
           managers are significant, due to the amount of end
           users and end user MTAs. Any marginal cost savings per
           user which can be made, e.g., by deployment of automated
           tools, should be considered due to the large overall



RARE WG-MSG Task Force 88                                      [Page 31]

RFC 1616     X.400(88) for European Academics and Research      May 1994


           savings that accrue.

         - The costs of any potential disruption of the end user's
           messaging service are high - due to the huge numbers of
           end users involved - and as such only a very well
           managed, phased and planned migration should be
           considered.

   - Software costs

         - The costs for software development are outside the
           scope of this report. However it is clear that cost
           needs to be incurred in order to provide software that
           is easy to install and use. As a result of the work of
           the task force a list of possibly needed components and
           likely changes to existing components can be proposed,

                Modifications, but not new developments, to
                  software for:

                     - X.400(1988) MTAs, X.400(1988) UAs, DSAs,
                       DUAs and MSs.

                New software developments for:

                     - MIME to MHS Gateways, X.400(1988) network
                       management, mailbox conversion, PC LAN
                       directory synchronisation, PC LAN gateways
                       and UA capability registration.

         - The distribution costs for any new software (for the
           European R&D community) are low if usual academic
           distribution methods - FTP servers, E-mail Based
           servers, Gopher, World Wide Web and Archie - are used.

*Summary*

   Migration towards a X.400(1988) service needs to evolve from the
   inside (the messaging backbone) outward (to the end user MTAs and end
   users themselves). Due to the numbers involved both the costs and the
   benefits associated with the migration increase as the migration
   evolves towards the end users.

   The benefits of migrating to a X.400(1988) service are a feature rich
   well defined open standard with high functionality , scalability, use
   of directory, multimedia and secure messaging capability. The costs
   for migrating a RELAY MTA backbone can be considered relatively low
   whilst the migration of end user MTAs and the migration of the end



RARE WG-MSG Task Force 88                                      [Page 32]

RFC 1616     X.400(88) for European Academics and Research      May 1994


   users themselves are relatively high. These costs should of course be
   balanced against the cost of a disrupted service that one might get
   if no migration occurs at all and the current service (e.g.,
   X.400(1984)) reaches the limits of its scalability and/or
   functionality.

   It is important to realise that if end users themselves do not
   experience direct feedback of the benefits from X.400(1988), this may
   make the organisational motivation needed to effect such a migration
   difficult to achieve. In effect, the establishment of a pilot
   X.400(1988) service is and should be driven by the requirements of
   end users and thus achieving end user benefits - as listed above -
   must be given a higher priority within a X.400(1988) service than
   solely the extra service provider benefits.

8.  Main Recommendations

   The RARE WG-MSG Task Force on 'The Establishment of an X.400(1988)
   Pan European Pilot Messaging Service' has identified a number of high
   level recommendations for establishing such a
    service. The main high level recommendations are listed within this
   chapter. A more detailed elaboration of these main recommendations is
   given in Appendix A. Appendix A is provided for policy makers wishing
   more background on the main recommendations. As well, a list of very
   detailed guidelines, plus some issues requiring further
   investigation, is given in Appendix B. Appendix B will be especially
   useful for personnel seeking detailed technical guidelines which are
   consistent with the main high level recommendations.

*Recommendations*

    - Establish a X.400(1988) pilot service encompassing European
      Commercial, Government and Academic bodies. Such a pilot
      service to be co-ordinated by using an industry forum where
      all parties could meet. The use of an existing forum, where
      user organisations are well represented, is desirable if
      commercial end users organisation's requirements are to be
      met. The forum should also be open to non-European
      participants.

    - X.400(1988) end user services should be provided as well as
      a X.400(1988) backbone RELAY MTA service within a X.400(1988)
      pilot service. The end user services should be given a high
      priority.

    - Help an already emerging market place in X.400(1988)
      products to prosper by ensuring that a suitable supply of
      high quality X.400(1988) public domain software is available.



RARE WG-MSG Task Force 88                                      [Page 33]

RFC 1616     X.400(88) for European Academics and Research      May 1994


      The Internet has proven, that public domain software, free of
      any commercial restrictions, is further rapidly developed, by
      Small and Medium Size Enterprises (SMEs), into derivative
      products suitable for the commercial market.

    - Any pilot service should be well co-ordinated and result
      driven but utilise a distributed market oriented approach. It
      is considered very difficult to organise and plan such a
      pilot under the assumption of a single centrally funded body
      i.e., driven from the 'top'. A more 'market driven' or
      distributed organisation is considered feasible, and likely
      to succeed, if all the market 'players' are fully involved
      i.e., a 'bottom' up approach.

    - For the academic community - and ever more for the
      commercial community - there is a business need to ensure near
      total and 'perfect' integration with the existing and also
      evolving RFC 822 based services.

    - For the academic community a rapid migration of the existing
      X.400(1984) backbone RELAY MTAs, used within the European R&D
      X.400(1984) service, - formerly the COSINE MHS service - is
      considered urgent. This migration will provide a 'bootstrap'
      path for academic organisations to internationally pilot
      X.400(1988) services. Such end user piloting is not
      considered feasible if X.400(1984) backbone RELAY MTAs are
      used for an X.400(1988) service (see Reference [17] for
      technical details).

   The report does not include any recommendations on development and
   deployment of RFC 822 / MIME / PEM related (pilot) services, as these
   are outside of the scope of the Task Force. However, since both
   X.400(1988) and RFC 822 / MIME / PEM will be developed and used
   within the European R&D community, such a pilot should also be
   considered.

9.  Security Considerations

   Security issues are not discussed in this memo.












RARE WG-MSG Task Force 88                                      [Page 34]

RFC 1616     X.400(88) for European Academics and Research      May 1994


10. Reading List and Bibliography

   This section contains a list of relevant reference documents that can
   be used for further reading.

      [1]         Kille;, S., "Mapping between X.400(1988) / ISO 10021
                  and RFC 822", RFC 1327/RTR 2, University College
                  London, May 1992.

      [2]         Kille, S., "X.400 1988 to 1984 downgrading",
                  RFC 1328/RTR 3, University College London, May 1992.

      [3]         Adie, C.,  "A Survey on Multimedia Projects, Products
                  and Standards", RTR 5, Edinburgh University Computing
                  Centre, January 1993.

      [4]         Alvestrand, H., and S. Thompson, "Equivalences between
                  1988 X.400 and RFC 822 Message Bodies", RFC 1494,
                  SINTEF DELAB, Soft*Switch Inc., August 1993.

      [5]         Alvestrand, H.,  Kille, S., Miles, R., Rose, M.,
                  and S. Thompson, "Mapping between X.400 and RFC 822
                  Message Bodies", RFC 1495, SINTEF DELAB, ISODE
                  Consortium, Soft*Switch, Inc., Dover Beach
                  Consulting, Inc., Soft*Switch, Inc., August 1993.

      [6]         Alvestrand, H., Romaguera,  J., and K. Jordan,
                  "Rules for downgrading messages from X.400/88 to
                  X.400/84 when MIME content-types are present in the
                  messages", RFC 1496, SINTEF DELAB, NetConsult AG,
                  Control Data Systems, Inc., August 1993.

      [7]         IETF MHS-DS Working Group, Works in Progress.

      [8]         Borenstein, N., and N. Freed, "MIME (Multipurpose
                  Internet Mail Extensions) Part One: Mechanisms for
                  Specifying and Describing the Format of Internet
                  Message Bodies", RFC 1521, Bellcore, Innosoft,
                  September 1993.

      [9]         Moore, K., "MIME (Multipurpose Internet Mail
                  Extensions) Part Two: Message Header Extensions for
                  Non-ASCII Text", RFC 1522, University of Tennessee,
                  September 1993.







RARE WG-MSG Task Force 88                                      [Page 35]

RFC 1616     X.400(88) for European Academics and Research      May 1994


      [10]        Kaliski, B., "Privacy Enhancement for Internet
                  Electronic Mail: Part IV: Key Certification and
                  Related Services", RFC 1424, RSA Laboratories,
                  February 1993.

      [11]        Balenson, D., "Privacy Enhancement for Internet
                  Electronic Mail: Part III: Algorithms, Modes, and
                  Identifiers", RFC 1423, TIS, February 1993.

      [12]        Kent, S., "Privacy Enhancement for Internet
                  Electronic Mail: Part II: Certificate Based Key
                  Management", RFC 1422, BBN, February 1993.

      [13]        Linn, J., "Privacy Enhancement for Internet
                  Electronic Mail: Part I: Message Encryption and
                  Authentication Procedures", RFC 1421, IAB IRTF PSRG,
                  IETF PEM WG, February 1993.

      [14]        Jurg, P., and E. Huizer, "The SURFnet electronic mail
                  project", SURFnet, EH/PJ932307, July 1993.

      [15]        Alvestrand, H., "X.400 Use of Extended Character
                  Sets", RFC 1502/RTR 7, SINTEF DELAB, August 1993.

      [16]        Manros, C.-U., "The X.400 Blue Book Companion", ISBN
                  1 871802 00 8, Technology Appraisals Ltd, 1989.

      [17]        Houttuin, J., and J. Craigie, "Migrating from
                  X.400(1984) to X.400(1988)", RFC 1615/RTR 9,
                  RARE, JNT, May 1994.

      [18]        Nagelhus, I. et al., "Survey of E-mail systems with
                  X.400 capability".

      [19]        "A White Paper on X.400(1988)", EMA Report.

      [20]        IAB, IESG, "The Internet Standards Process --
                  Revision 2", RFC 1602, March 1994.













RARE WG-MSG Task Force 88                                      [Page 36]

RFC 1616     X.400(88) for European Academics and Research      May 1994


11. Terminology

      ADMD     Administration Management Domain
      ASCII    American Standard Code for Information Exchange
      ASN.1    Abstract Syntax Notation One
      AU       Access Unit
      CCITT    Comite Consultatif International de Telegraphique et
               Telephonique
      CEN      Comite Europeen de Normalisation
      CENELEC  Comite Europeen de Normalisation Electrotechnique
      CEPT     Conference Europeene des Postes et Telecommunications
      CONS     Connection Oriented Network Service
      COSINE   Co-operation for OSI networking in Europe
      DL       Distribution List
      DIS      Draft International Standard
      EMA      Electronic Messaging Association
      EN       European Norm
      ENV      Draft EN, European functional standard
      IEC      International Electrotechnical Commission
      IETF     Internet Engineering Task Force [20]
      IPM      Inter-Personal Message
      IPMS     Inter-Personal Messaging Service
      IPN      Inter-Personal Notification
      ISO      International Organisation for Standardisation
      JNT      Joint Network Team (UK)
      JTC      Joint Technical Committee (ISO/IEC)
      MD       Management Domain (either an ADMD or a PRMD)
      MHS      Message Handling System
      MHS-DS   Message Handling Systems use of Directory Service
               Working Group from the IETF
      MIME     Multi-purpose Internet Mail Extensions (extensions to
               RFC 822) [6]
      MOTIS    Message-Oriented Text Interchange Systems
      MTA      Message Transfer Agent
      MTL      Message Transfer Layer
      MTS      Message Transfer System
      NBS      National Bureau of Standardization
      OSI      Open Systems Interconnection
      PEM      Privacy Enhanced Mail [10]
      PRMD     Private Management Domain
      RARE     Reseaux Associes pour la Recherche Europeenne
      RFC      Request For Comments (series of Internet publications)
      RFC 822  RFC describing Internet Message format for Electronic
               mail
      RTR      RARE Technical Report (series of RARE publications)
      RTS      Reliable Transfer Service
      WG-MSG   RARE Working Group on Mail and Messaging




RARE WG-MSG Task Force 88                                      [Page 37]

RFC 1616     X.400(88) for European Academics and Research      May 1994


Appendix A - Elaboration on the main recommendations

   The main recommendations of the report are elaborated upon in more
   detail within this appendix.

    - In order to provide a globally pervasive messaging service,
      it is recommended to establish a well operated Pan-European
      X.400(1988) pilot backbone comprising MTAs and MSs,
      connecting partners within Industry, Commercial Service
      Providers, Academia and Public Bodies (CEC, National
      Governments, etc.). The pilot should be open to global
      participation.

    - In order to maintain the widest connectivity with the
      highest possible functionality, gateways should be installed
      that gateway between X.400(1988) and RFC 822/MIME. These
      gateways should follow the specifications of RFC 1327 [1] and
      RFC 1494 et al. [4]. Experience with these gateways should be
      fed back into the appropriate RARE and IETF Working Groups to
      improve the standards.

    - In order that the 'business needs' of non-R&D organisations
      can be inserted at an early stage into the goals of the pilot
      and ensuring that the success of the pilot in meeting these
      goals can be measured and disseminated i.e., to encourage the
      active participation of non-R&D organisations within the
      pilot, it is recommended that an open forum comprising
      industry, service providers, public bodies and academia
      should be used. Preferably an existing forum where end users
      are heavily involved is desirable.

    - In order for meaningful co-operation between bodies affected
      by the pilot to occur and thus hopefully reducing unnecessary
      duplications, it is recommended that there are close liaisons
      and contacts between at least the IETF, RARE, EARN, EUnet,
      RIPE, Y-NET, EEMA, EMA, EWOS, OIW, CEN/CENELEC, ISO, CCITT,
      CEC and European governmental bodies and those involved
      within the pilot. The suggested mechanism for a meaningful
      liaison is that enough participants of the above
      organisations attend the common forum mentioned above. It is
      also suggested that as much as possible e-mail distribution
      lists be used to communicate between forum participants.

    - In order that the pilot have measurable results, it is
      recommended that the pilot shall be implemented in phases. It
      is considered that at least two phases are needed:





RARE WG-MSG Task Force 88                                      [Page 38]

RFC 1616     X.400(88) for European Academics and Research      May 1994


         - phase 1 - initial short start up phase with a small
           number of participants. The result of this phase is
           that any needed procedures, co-ordination mechanisms,
           etc. are put into place for the large scale piloting of
           phase 2.

         - phase 2 - phase with a wide Pan-European participation.
           The result of this phase should be a proof of scaling
           of the pilot X.400(1988) service i.e., the goals of the
           pilot as defined in Chapter 1 are met. It is expected
           that upon successful completion of this phase a natural
           evolution to a global deployment of a X.400(1988)
           service will have started.

    - In order to rapidly complete phase 1 of the pilot and that
      the pilot is at least Pan-European in scope, it is
      recommended that; a number of R&D service providers, one each
      from several European countries; at least 2 North American
      R&D service providers; at least 1 Japanese R&D service
      provider and a small number of commercial service providers
      and commercial organisations are actively involved in phase
      1.

    - In order to stimulate the creation of an economically viable
      market place for X.400(1988) products (i.e., MTAs, UAs, etc.)
      (i.e., users are willing to purchase such products), it is
      recommended that a suitable minimum number of new software
      implementations and or modifications to existing software
      implementations be funded. The resulting software to be
      inserted into the Public Domain free of any financial
      restrictions on further commercial exploitation. By using
      this mechanism, Small and Medium Size Enterprises (SMEs) will
      be encouraged to commercially exploit such products.

    - Due to the strong influence of the R&D community within the
      pilot plus the desire to produce standardised products
      quickly and pragmatically, it is recommended that any
      standards proposed within the scope of an X.400(1988) pilot
      (for example standards re: character sets and body parts
      gatewayed to and from X.400(1988) and RFC 822 / MIME) are
      conformant to and candidates for Internet standardisation. As
      a concrete example of the standardisation process, this means
      that at least two independent software implementations, for
      each product category, (of which one product preferably in
      the Public Domain) must be proven as interworking to a
      proposed standard before the proposed standard can be
      elevated to draft standard [20].




RARE WG-MSG Task Force 88                                      [Page 39]

RFC 1616     X.400(88) for European Academics and Research      May 1994


    - To ensure that there is a market driven demand for
      X.400(1988) products within the commercial market place, it
      is recommended that the maximum number of Public Domain
      implementations that are funded, by any one public funding
      organisation, is two. It is desirable that at least one other
      product, preferably commercially based and not within the
      Public Domain, is produced.

    - In order that any necessary information required for the
      effective operation of the X.400(1988) pilot, including not
      least OID assignments, mapping rules, information about
      interconnection partners, naming authority information be
      made widely available, it is recommended that an
      electronically accessible information base be established.

    - In order that any necessary organisational issues needed for
      a deployment of an X.400(1988) service have a body in place
      to deal with this issue, it is recommended that the pilot
      either identify and list which bodies are responsible for
      which issues or else actively ensure that a suitable body is
      being put in place.

Appendix B - A number of detailed guidelines.

   The Task Force has the following detailed guidelines:

*Product and operational service guidelines*

    - To ensure that there is no degradation of X.400(1988)
      service between X.400(1988) originators and destinations, the
      topology of the MTS must be such that no X.400(1984) MTA acts
      as a relay between any two X.400(1988) users.

    - As the existing R&D X.400(1984) service (formerly COSINE
      MHS) now comprises a large number of X.400(1988) capable
      RELAYs, it would be relatively straight forward that the
      existing COSINE MHS RELAYs be one of the first communities
      that are migrated to X.400(1988) capabilities. This would
      ensure that X.400(1988) MTAs using the RELAY backbone
      experience no loss of service.

    - To be able to operate an X.400(1988) service a properly
      operated X.400(1988) infrastructure should be established,
      consisting of X.400(1988) MTAs, X.400(1988) MTAs with
      downgrading capabilities according to RTR 3, Message Store
      services and gateways to RFC 822 based upon RTR 2 and
      extended gatewaying functionality for multimedia mail.




RARE WG-MSG Task Force 88                                      [Page 40]

RFC 1616     X.400(88) for European Academics and Research      May 1994


    - To ensure maximum use of the OSI supporting layers plus
      support of normal mode RTS, it is recommended that a
      migration to ISO 10021 is effected i.e., straight to use of
      the full OSI stack with normal mode RTS.

    - To ensure maximum quality of service as impacted by
      implementation decisions related to the 'General Extension
      Mechanism', it is recommended that no minimal X.400(1988)
      MTAs, which relay the syntax but understand none of the
      semantics of extensions, should be used.

    - It is recommended that all X.400(1988) MTAs should generate
      reports containing extensions copied from the subject message
      and route reports through the DL expansion hierarchy where
      appropriate.

    - It is recommended that all X.400(1984) UAs are able to
      generate and display DDAs. This will allow such systems to
      address X.400(1988) Common Name Attribute users.

    - To enhance connectivity to both X.400(1984 and 1988)
      management domains without degradation of X.400(1988)
      service, management domain entry points that support both
      X.400(1984 and 1988) are recommended.

    - To ensure total connectivity between RFC 822 domains
      migrating to X.400(1988), it is recommended that a local
      X.400-to-RFC-822 gateway is made operational or a reliable
      service agreement for the external provision of such a
      gateway is effected before any migration begins.

*Migration utilities needed*

    - It is considered very helpful if conversion utilities that
      allow a flawless conversion of an RFC 822 user's existing
      mail folders to a X.400(1988) product's folder system be
      implemented. However further investigation is needed before
      recommending that such tools be made a mandatory part of any
      funded software development.

    - It is recommended that the ease of configuration of
      X.400(1988) products is made as automatic as possible.
      Consideration should be given to a) modern user interfaces b)
      automatic processing of 'old RFC 822' configuration files
      into the 'new X.400(1988)' configuration files i.e., a reuse
      of the user's previous options and configurations should be
      the result. If a 'simple' configuration interface is needed
      it should be as compatible as possible with the present RFC



RARE WG-MSG Task Force 88                                      [Page 41]

RFC 1616     X.400(88) for European Academics and Research      May 1994


      822 mailer's i.e., this concretely means editing of ASCII
      files.

*Issues for further study*

   The pilot X.400(1988) messaging service must ensure that the issues
   listed below are either being investigated by an appropriate body or
   if not initiate actions to properly address them. The issues have
   been grouped under Products, Organisational and Deployment.

    - Products

         - Any X.500 DSAs, DUAs, APIs e.g., LDAP, etc. changes
           needed to support X.400(1988) messaging.

         - X.400(1988) MTAs, UAs, MSs, gateways to RFC 822/MIME
           and X.400(1984) plus gateways to other messaging
           systems e.g., Microsoft Mail, Lotus cc:Mail, etc.

         - User Interfaces that integrate X.400(1988) UAs and
           X.500 DUAs with user applications such as Word
           Processors, etc.

         - E-mail network management software both for users and
           administrators

    - Organisational

         - trusted network for security (i.e., the distribution of
           security keys) and whether this trusted network should
           or can be the same as the PEM trusted network presently
           under deployment.

         - usage of PEM within X.400(1988).

         - PEM to and from X.400(1988) gatewaying.

         - how to register and publicise object IDs for
           X.400(1988).

         - addresses are well publicised of PRMD and ADMD
           registration authorities.

         - creation and modification authority for X.400-to-RFC-
           822 mapping rules is defined.

         - creation and modification authority for MTA routing
           rules is defined.



RARE WG-MSG Task Force 88                                      [Page 42]

RFC 1616     X.400(88) for European Academics and Research      May 1994



         - what methods should be used to liaison to other bodies
           like IETF, ISO, EEMA, EMA, etc.

         - ensuring that any Public Domain software needed for the
           X.400(1988) service is distributed widely, quickly and
           efficiently.

    - Deployment

         - which services should start such a migration (i.e.,
           COSINE MHS RELAYs, Universities, other).

         - the topology of the X.400(1988) MTS.

         - addressing of users between X.400(1984 and 1988) and
           RFC 822 e.g., how will X.400(1988) T.61 address
           components be processed by X.400(1984) and RFC 822
           systems.

         - which X.400(1988) body parts MUST be supported by the
           research community.

         - if any new APIs - or modified APIs - are needed for
           X.400(1988) and messaging in general.

         - the specifications and development of any needed Public
           Domain software.

         - what existing Public Domain software should be modified
           to accommodate X.400(1988) systems.

         - how rapidly to deploy the X.400(1988) service.

         - ensuring that there is 'little or no loss of service'
           in any migration from X.400(1984), or RFC 822, to
           X.400(1988).

         - considering what Value Added Services, based upon
           X.400(1988), could be started to encourage uptake of
           X.400(1988).










RARE WG-MSG Task Force 88                                      [Page 43]

RFC 1616     X.400(88) for European Academics and Research      May 1994


Authors' Addresses

   Only the two editors' complete addresses are listed here:

   Erik Huizer (Task Force chair)
   SURFnet bv
   P.O. Box 19035
   NL-3501 DA  Utrecht
   Europe

   Phone: +31 30 310 290
   RFC 822: huizer@surfnet.nl
   X.400:   S=huizer;O=SURFnet;PRMD=surf;ADMD=400net;C=nl;


   James A. (Jim) Romaguera
   NetConsult AG
   Berner Technopark
   Morgenstrasse 129
   CH-3018 Bern
   Europe

   Phone: +41 31 998 4141
   RFC 822: romaguera@netconsult.ch
   X.400: S=romaguera;O=netconsult;PRMD=SWITCH;ADMD=ARCOM;C=CH;

   The Task Force as a whole can be reached per e-mail at the
   address:

   RFC 822: tf-88@SURFnet.nl
   X.400:   S=tf-88;O=SURFnet;PRMD=surf;ADMD=400net;C=nl;




















RARE WG-MSG Task Force 88                                      [Page 44]