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






Network Working Group                                     U. Eppenberger
Request for Comments: 1465                                        SWITCH
                                                                May 1993


              Routing Coordination for X.400 MHS Services
          Within a Multi Protocol / Multi Network Environment
                   Table Format V3 for Static Routing

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  Discussion and suggestions for improvement are requested.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

1. Introduction

   The usage of the X.400 Message Handling System (MHS) is growing
   rapidly, especially in the commercial world but much interest can
   also be found in the academic and research community.  New networks
   and new addresses come into use each and every day.  The underlying
   technology for different X.400 networks can vary depending on the
   transport network and the X.400 MHS implementations used.  As a large
   number of X.400 implementations now support multiple stacks, this
   offers the chance of implementing a world wide message handling
   service using the same electronic mail standard and, therefore,
   without the need of gateways with service reduction and without the
   restriction to a single common transport network.  This, however,
   leads to several problems for the MHS manager, two of which are:

   - Where do I route new X.400 addresses and

   - How do I connect to a MHS domain that uses an underlying
     technology that I do not support.

   This document proposes short term solutions to these problems.  It
   proposes a strategy for maintaining and distributing routing
   information and shows how messages can travel over different networks
   by using multi stack MTAs as relays.  Document formats and
   coordination procedures bridge the gap until an X.500 directory
   service is ready to store the needed connectivity and routing
   information.  The format has been designed to allow the information
   to be stored in an X.500 directory service while managers without
   directory service access may still use a table based approach.

   The routing structure proposed can be applied to a global MHS service



Eppenberger                                                     [Page 1]

RFC 1465        Routing Coordination for X.400 Services         May 1993


   but may also be used at a national level or even within an
   organisation.

   Many experts from IETF X.400-Operations Group and RARE Working Group
   1 on Message Handling Systems have read drafts of this document and
   contributed ideas and solutions.  I would especially like to thank
   Harald Alvestrand, Erik Huizer, Marko Kaittola, Allan Cargille and
   Paul-Andre Pays.

   This is the third version of a table format.  The first one was in
   use within COSINE-MHS for about two years.  A second version with
   major enhancements was then proposed which has been in use for the
   past year.  The third version will probably be the last one before it
   will be possible to switch to dynamic, directory service based
   routing.

2. Terminology

   MHS community

      One or more MHS domains form an MHS community.  Mail exchange
      between these MHS domains is defined by the coordination
      procedures within this document.  Examples of such communities are
      the Global Open MHS service GO-MHS and the COSINE-MHS service.

   MHS domain

      One or more MHS subtrees form an MHS domain.  This is a purely
      administrative grouping of MHS subtrees.  It is helpful, if
      someone is responsible for several MHS subtrees, to refer to an
      MHS domain instead of listing all the subtrees.

   MHS subtree

      An MHS subtree consists of the total of the mailboxes addressable
      within a subtree of the X.400 OR address space.

        Example:  O=SWITCH; P=SWITCH; A=ARCOM; C=CH;

        MHS domain of SWITCH in Switzerland, consisting of all
        mailboxes with O=SWITCH; P=SWITCH; A=ARCOM; C=CH; in the OR
        address.

   RELAY-MTA

      An X.400 MTA serving one or several MHS domains.  Note that the
      term WEP -Well Known Entry Point- has been used since the early
      X.400ies (1987/88) until now, giving the wrong impression of a



Eppenberger                                                     [Page 2]

RFC 1465        Routing Coordination for X.400 Services         May 1993


      single entry point (and therefore a single point of failure).
      This document proposes to use the term RELAY-MTA, reflecting more
      clearly the functionality of the MTA.

   COSINE-MHS

      The COSINE-MHS community is mainly formed by European X.400
      service providers from the academic and research area, each of
      which is a member of RARE.  The COSINE-MHS community is used in
      the annex as an example for the usage of this document in a
      multinational environment.

3. Requirements

   X.400 MTAs can communicate using different transport and network
   protocol stacks.  For this document the stacks used in a WAN
   environment need to be considered:

                           Stack 1    Stack 2    Stack 3    Stack 4

      Transport Layer 4    TP0        TP4        RFC1006    TP0
      Networkservice 1-3   X.25       CLNS       TCP/IP     CONS

   A common protocol stack is not the only requirement to enable
   communication between two MTAs.  The networks to which the MTAs
   belong need to be interconnected.  Some well known networks are
   listed together with the stacks they use.

      Network                                Stack   Abbreviation

      Public Switched Packet Data Networks     1     Public-X.25
      International X.25 Infrastructure EMPB   1,4   EMPB-X.25
      US and European connectionless pilot     2     Int-CLNS
      Internet                                 2,3   Internet

   Note that several stacks may be supported over a single network.
   However communication between MTAs is only possible if the MTAs share
   at least a common stack AND a common network.

   Unlike SMTP/TCP/IP systems, there is no directory service available
   which would allow an MTA to look up the next MTA to which it should
   submit a message.  Routing within X.400 will continue to be table
   based until a solution using X.500 directory services is available.

   Furthermore it is not generally allowed to connect to any MTA even on
   the same network without being registered on the destination MTA.
   These restrictions require a large coordination effort and carefully
   configured and updated systems.



Eppenberger                                                     [Page 3]

RFC 1465        Routing Coordination for X.400 Services         May 1993


4. Outline of the proposal

   This proposal offers a solution for describing information about
   X.400 message routing within an MHS community in RELAY-MTA and DOMAIN
   documents.  Basic information on the MHS community is documented in
   the corresponding COMMUNITY document.  All contact persons and
   RELAY-MTA administrators can be found in PERSON documents.  A future
   X.500 based solution may need extended information to overcome still
   unsolved problems like optimal routing or traffic optimization for
   messages with multiple recipients.  The information collected for the
   intermediate solution however is very basic.  All established
   coordination procedures will help and even speed up the future
   introduction of an X.500 based solution.

4.1 The COMMUNITY document

   For each MHS community there exists one single COMMUNITY document
   containing basic information.  First the contact information for the
   central coordination point can be found together with the addresses
   for the file server where all the documents are stored.  It also
   lists network names and stacks to be used in the RELAY-MTA and DOMAIN
   documents.  An MHS community must agree on its own set of mandatory
   and optional networks and stacks.

4.2 The RELAY-MTA document

   Every MHS domain in the community may designate one or more MTAs as
   RELAY-MTAs.  These RELAY-MTAs accept incoming connections from the
   RELAY-MTAs of the other MHS domains and in return are allowed to send
   messages to these RELAY-MTAs.  A RELAY-MTA is documented with all the
   necessary connection information in the corresponding RELAY-MTA
   document.

4.3 The DOMAIN document

   An MHS domain has a responsible person who sets up the routing
   entries for the domain in the DOMAIN document.  The primary RELAY-
   MTAs listed in the DOMAIN document as serving this MHS domain must,
   TOGETHER, offer at least connectivity to all networks and stacks
   listed as mandatory in the COMMUNITY document.  Optional RELAY-MTAs
   may be added, generally with higher priority, to allow more precise
   routing.

   An MHS domain may also decide not to operate a RELAY-MTA.  It will
   then only need agreements with one or more RELAY-MTAs from other MHS
   services which will relay for this domain.  The domain itself,
   however, must either create its own DOMAIN document or document its
   MHS subtrees jointly with another MHS domain.



Eppenberger                                                     [Page 4]

RFC 1465        Routing Coordination for X.400 Services         May 1993


   The structure of the DOMAIN document is very straightforward.  It
   starts off with one or more MHS subtrees, each on its own line.
   After the domains follows a line indicating the responsible person
   for the MHS subtrees mentioned.  Finally the responsible RELAY-MTA(s)
   are listed with appropriate priorities.

4.4 The PERSON document

   All administrators and responsible persons are documented in PERSON
   documents.  The RELAY-MTA and DOMAIN documents contain just keys
   pointing to a PERSON document.  If such a person can already be found
   in an X.500 directory service, then the key consists of a
   Distinguished Name, else the key is just its OR address.

4.5 Coordination

   This approach requires an identified coordination point.  It is up to
   the MHS community to decide on the level of coordination and support
   to be provided and on the funding mechanisms for such activities.
   Basic information can be found in the COMMUNITY document.  The
   following list of support activities is considered mandatory for an
   operational service:

    - New RELAY-MTAs joining the service are tested and support is
      given to create the RELAY-MTA document.

    - New MHS domains joining the MHS community get assistance to set
      up RELAY-MTA(s) and/or find appropriate RELAY-MTA(s) and to
      create DOMAIN documents.

    - Updated documents are announced to the RELAY-MTA managers and
      responsible persons for the DOMAIN documents unless automatic
      distribution is used.

    - All the RELAY-MTA, DOMAIN and PERSON documents are made
      available on a file server together with the COMMUNITY document.
      The file server must at least be reachable via email.  MHS
      communities with a big number of documents may consider
      additional access methods like ftp and FTAM.

    - Tools should be made available to manage routing tables for the
      X.400 software used on the RELAY-MTAs or to fill in and check
      the documents.  The format of the documents has specifically
      been chosen to enable the use of automated tools.

   The RELAY-MTA managers must be aware that a large number of RELAY-
   MTAs in an MHS community may require significant operational
   resources to keep the local routing tables up-to-date and to



Eppenberger                                                     [Page 5]

RFC 1465        Routing Coordination for X.400 Services         May 1993


   constantly monitor the correct functioning of the connections.  On
   the other hand more than one RELAY-MTA with a good connectivity to an
   MHS domain improves the overall robustness of the domain and thus the
   QOS.

   MHS communities may decide on additional mandatory requirements for
   the operation of a RELAY-MTA.  These may include a hot line, echo
   services, exchange of statistics, response time to problem reports,
   uptime of the RELAY-MTA, etc.  This will ensure a certain quality of
   service for the end users.

4.6 Routing

   The proposal addresses MHS communities spanning several
   organisations.  But it may also be used to manage routing within a
   single organisation or even a global MHS community.

   Two kinds of mail relays are defined, the primary RELAY-MTAs and the
   secondary RELAY-MTAs.  A primary or secondary RELAY-MTA must allow
   incoming connections from all other primary and secondary RELAY-MTAs
   with a common stack.  Primary RELAY-MTAs must be able to connect to
   all other primary RELAY-MTAs which share a common stack.  A secondary
   RELAY-MTA must connect to at least one primary RELAY-MTA.

   Each MHS community must define update procedures for the routing
   based on the documentation.  Automated update has to be studied
   carefully.

   An MHS community should also define procedures for new RELAY-MTAs and
   MHS domains joining the service.  Since the usage of X.400 is growing
   rapidly a flexible but well coordinated way of integrating new
   members into an MHS community is needed.  The proposed documentation
   format supports this by allowing primary and secondary RELAY-MTAs.
   All RELAY-MTAs accept incoming connections from each other.  Sending
   messages can be done by using the primary RELAY-MTAs only.  This
   allows new RELAY-MTAs to join the community as secondary and to get
   primary status when traffic flow increases.  Secondary RELAY-MTAs may
   also require a longer testing period.

5. The documents

   The definition is given in BNF-like syntax.  The following
   conventions are used:


    |    means choice

    \    is used for continuation of a definition over several lines



Eppenberger                                                     [Page 6]

RFC 1465        Routing Coordination for X.400 Services         May 1993



    []   means optional

    {}   means repeated one or more times

    ()   is used to group choices

    \"   is used for double quotes in a text string

    <CR> is a Carriage Return and means that the next section starts
         on its own line.

   The definition is complete only to a certain level of detail.  Below
   this level, all expressions are to be replaced with text strings.
   Expressions without more detailed definition are marked with single
   quotes '.  The format and semantics should be clear from the names of
   the expressions and the comments given.

   Wherever the BNF definition requires a single blank, multiple blanks
   may be used to increase the readability.  Please note that for some
   field values the number of spaces is significant.

   Lines exceeding 80 characters should be wrapped at any convenient
   blank except at blanks which are significant.  The line is continued
   with at least one leading blank.

   Comments may be placed anywhere in the document but only on separate
   lines and without splitting wrapped lines.  Such a comment line must
   either start with a '#' sign followed by white space and the comment
   or consist of a single '#' on a single line.

   The documents must follow the case of the strings defined in BNF.
   Note that some values, especially connection parameters like TSEL or
   MTA password are case dependant too.

   The BNF definitions are ordered top-down.  See Appendix B for an
   alphabetically sorted list.

   A set of one COMMUNITY document and several RELAY-MTA, DOMAIN and
   PERSON documents belong together.  The detailed definitions can be
   found in the following chapters.

      <X.400 routing coordination document set> ::= \
                            <COMMUNITY-document> \
                            { <RELAY-MTA-document> } \
                            { <DOMAIN-document> } \
                            { <PERSON-document> }




Eppenberger                                                     [Page 7]

RFC 1465        Routing Coordination for X.400 Services         May 1993


5.1 Common Definitions

      <DirectoryName> ::= 'Distinguished Name'
                The string representation of a Distinguished Name is
                defined in the RFCxxxx.  If a Distinguished Name is
                used as a key in the documents, then the information
                can be fetched from the directory instead of checking
                the appropriate document.  But as long as not all
                managers in the same community have directory access,
                the same information must also be present in a
                document.  Note that Distinguished Names in the context
                of the routing documents are just used as key strings
                to point to other documents.

      <Community-Identifier> ::= "Community: " \
                            ('community name' | <DirectoryName>) <CR>
                The 'community name' is a string identifying the MHS
                community to be used in the first line of all
                documents.

      <UniqueRELAY-MTAkey> ::= (([ "P=" 'PRMDname' "; " ] \
                            ["A=" 'ADMDname' "; " ] \
                            "C=" <Country-Code> "; " \
                            "MTAname=" 'MTAname')
                            | <DirectoryName> )
                A unique key is needed to identify the RELAY-MTA.  In
                addition to the MTA name itself, it is proposed to use
                OR address attributes of the management domain where
                the RELAY-MTA resides.  ADMD and PRMD fields are both
                optional and may be used to guarantee uniqueness of the
                key.  The values used are irrelevant.  Even non-
                printable characters like @ or ! are acceptable.  The
                result is not an address but a key string.  A
                Distinguished Name may be used instead.

      <UniquePersonKey> ::= (<X.400 address> | <DirectoryName> )
                A unique key is necessary to make the links from the
                documents where a responsible person or an
                administrator is needed, to the PERSON documents.  It
                is either the OR address of the person or a
                Distinguished Name (if the person is already registered
                in the directory).

      <Country-Code> ::= 'Two Character Country Code ISO-3166'

      <X.400 address> ::= 'OR address, ISO 10021-2 Annex F'
                It has been used consequently all over the document.
                This explains also the syntax of the



Eppenberger                                                     [Page 8]

RFC 1465        Routing Coordination for X.400 Services         May 1993


                <UniqueRELAY-MTAkey> and the <MHS-subtree>. Examples:
                S=user; O=org ltd.; OU1=sect1; P=org; A=rel400; C=aq;
                DDA:RFC-822=we(a)sell.it; P=internet; A= ; C=xx;
                G=john; I=w; S=doe; P=org; A=rel400; C=aq;

      <EMail> ::= "Address: " <X.400 address> <CR>

      <tel-no-list> ::= <tel-number> [{"; " <tel-number>}]

      <tel-number> ::=  {"+" <int-pref> " " <national number> \
                            [" x" <extension>]}
                This syntax follows the attribute syntax of the X.500
                directory based on CCITT E.123.

      <int-pref> ::= 'international prefix'

      <national number> ::= 'national telephone number'
                A national number may be written with spaces and
                hyphens to group the figures.

      <extension> ::= 'local extension'

      <Phone> ::= "Phone: " <tel-no-list> <CR>
                One or more phone numbers

      <Fax> ::= "Fax: " <tel-no-list> <CR>
                One or more FAX numbers

      <Mail> ::= "Mail: " 'postal address information' <CR>
                The items of the postal address are separated by ' /'
                wherever the next item goes onto the next line for a
                printed address label.  If the document is for an
                international community, the address should include the
                person's country.
                Example:
                Mail: SWITCH Head Office / Urs Eppenberger /
                      Limmatquai 138 / CH-8001 Zurich / Switzerland
                results in the following mailing label:
                SWITCH Head Office
                Urs Eppenberger
                Limmatquai 138
                CH-8001 Zurich
                Switzerland

      <Update-info> ::= "Update: FORMAT=V3; DATE=" 'yymmdd' \
                            "; START=" 'yymmdd' \
                            ["; END=" 'yymmdd'] <CR>
                The <Update-info> contains also the format identifier.



Eppenberger                                                     [Page 9]

RFC 1465        Routing Coordination for X.400 Services         May 1993


                The date of the last update of a document is given in
                the form 'yymmdd'.
                A start date must be set.  A document can be published
                this way before the information in it is valid.  (This
                is especially useful in absence of automated tools.
                RELAY-MTA managers get more time to prepare their
                systems.)
                An end date is used to set an expiration date for the
                document.

      <P-address> ::= 'String encoded Presentation Address'
                The format of this string follows RFC1278, A string
                encoding of Presentation Address and RFC1277, Encoding
                Network Addresses to support operation over non-OSI
                layers.  See chapter 5.2 about the usage of macros in a
                Presentation Address.

      <Service-type> ::= <Network-name> "/" \
                            <Network-service> "/" \
                            <Transport-Protocol>
                The service type consists of a string with three parts
                concatenated with a "/": Network-name/Network-
                service/Transport-Protocol.

      <Network-name> ::= 'Name of a network'
                The network-name string identifies a network.  A well
                known key word should be chosen.  (No '/' character is
                allowed.)
                Examples: Public-X.25, Internet, EMPB-X.25, Int-CLNS,
                WIN, Janet,

      <Network-service> ::= 'Name of a network service'
                Examples: X.25, CONS, CLNS, TCP

      <Transport-Protocol> ::= 'Name of a transport protocol'
                Examples: TP0, TP2, TP4, RFC1006

                Since network and stack information forms one string,
                it identifies in an easy way a connection possibility
                between two RELAY-MTAs.  The COMMUNITY document defines
                the strings to be used in the RELAY-MTA and DOMAIN
                documents.  Some examples:
                Internet/TCP/RFC1006
                Public-X.25/X.25/TP0
                RARE-IXI/CONS/TP0
                RARE-CLNS/CLNS/TP4
                (It is probably important to mention here that this
                string has nothing to do with the format of a



Eppenberger                                                    [Page 10]

RFC 1465        Routing Coordination for X.400 Services         May 1993


                presentation address as defined by Steve Hardcastle-
                Kille in RFC1278.  The problem of networks using the
                same address structure (X.121 DTEs, 4 Byte Internet
                addresses) but not being connected is not addressed in
                RFC1278 but solved by using the proposed service
                identifier above in addition to the presentation
                address.  As long as there are network islands, there
                is no other way than the addition of an 'island'-
                identifier.

      <MHS-subtree> ::= ["O=" 'Organization-name' "; "] \
                            ["OU1="'OrganizationalUnit'"; "\
                            ["OU2=" 'OrganizationalUnit' "; " \
                            ["OU3=" 'OrganizationalUnit' "; " \
                            ["OU4=" 'OrganizationalUnit' "; "]]]] \
                            ["P=" 'PRMDname' "; "] \
                            "A=" 'ADMDname' "; " \
                            "C=" <Country-Code> ";"

      <Operation> ::= "Reachable: "  {<time> "-" <time> "; "} \
                            <Time-zone> <CR>

      <time> ::= 'hh:mm'

      <Time-zone> ::= ("UTC+" | "UTC-") 'hhmm'
                The operation information is needed to know the time
                someone is reachable.  This information is important
                for communities spanning several time zones.
                'hhmm' is a four digit value, the first two digits
                indicate hours, the second two digits indicate minutes.
                Use "UTC+" for time zones east of Greenwich.  A simple
                formula helps to calculate the current time at the
                remote place:
                local-time - local-displacement + remote-displacement =
                remote-time
                18:00 - (UTC + 0100) + (UTC - 0800) = 09:00
                The <Time-zone> entry may be followed by a comment line
                indicating when Daylight Saving Time is in effect.
                This is especially reasonable for MHS communities
                spanning continents on the northern and southern
                hemisphere.

5.2 The COMMUNITY document

      <COMMUNITY-document> ::= <Community-Identifier> \
                            <Update-info> \
                            <COMMUNITY-document-body>
                The first line of the COMMUNITY document specifies the



Eppenberger                                                    [Page 11]

RFC 1465        Routing Coordination for X.400 Services         May 1993


                <Community-Identifier> to be used in the header of all
                other documents belonging to the same community.  It is
                recommended to add a few comment lines to describe the
                members of this MHS community.

      <COMMUNITY-document-body> ::= <Coordination> \
                            [{<Macro-definition>}] \
                            {<Connections>}

      <Coordination> ::= <EMail> <Phone> <FAX> \
                            <Mail> <Operation> <File-server>
                Set of contact information for the coordination point

      <File-server> ::= <email-server> [{<FTP-server>}] \
                            [{<FTAM-server>}]
                All documents must be available at least to the
                managers of the MHS domains and the RELAY-MTAs through
                an email server.  If FTAM and FTP are also  available,
                the generation of automated update tools is much
                easier.
                It is suggested to have a single server.  If there is
                only one, knowing a single X.400 OR address will allow
                you to reach the server.  However for FTP and FTAM more
                system addresses may be possible depending on the
                number of available network connections (or service
                types as they are called in this document).

      <email-server> ::= "Mail-server: "<X.400 address> <CR>
                The email address of the file server.

      <FTP-server> ::= "FTP-server: " 'domain name' "; " \
                            'account-name' ["; " 'password'] <CR>
                In addition to the domain name of the server, an
                account name and a password is given.  In most cases
                this will probably be something like "anonymous" and
                "guest".
                Some servers request the RFC822 address of the user.
                This is documented by using the string 'user@domain' as
                password entry.  The meaning is not to use
                'user@domain' literally as password while accessing the
                server (even if this would generally work too since the
                software often just checks the presence of an @ sign,)
                but to use ones own RFC822 email address.

      <FTAM-server> ::= "FTAM-server: " <P-address> "; "\
                            'account-name' ["; " 'password'] \
                            ["; X.500 " <DirectoryName>] <CR>
                The account name is often case sensitive.  Some FTAM



Eppenberger                                                    [Page 12]

RFC 1465        Routing Coordination for X.400 Services         May 1993


                servers offer anonymous access with the account-name
                ANON.  Documenting an FTAM server with a Distinguished
                Name is only allowed if the server is registered in the
                directory.

      <Macro-definition> ::= "Macro: " 'Macro name' " " \
                            'Macro value' <CR>
                Presentation addresses without the usage of macros are
                generally unreadable.  RFC1278 suggests a few macros.
                All macros which are allowed in a community must be
                defined in the COMMUNITY document.  It is recommended
                to use the proposed macros in RFC1278 and add new ones
                if necessary:
                Macro: Int-X25(80)        TELEX+00728722+X.25(80)+01+
                Macro: Janet-X25(80)      TELEX+00728722+X.25(80)+02+
                Macro: Internet-RFC-1006  TELEX+00728722+RFC-1006+03+

      <Connections> ::= {<mandatory-service>} \
                            {[<optional-service>]}
                Note that at least one mandatory service type is
                needed.

      <mandatory-service> ::= "Mandatory-Service: " \
                            <Service-type> <CR>

      <optional-service> ::= "Optional-Service: " \
                            <Service-type> <CR>

5.3 The RELAY-MTA document

      <RELAY-MTA-document> ::= <Community-Identifier> \
                            <Update-info> \
                            <RELAY-MTA-document-Identifier> \
                            <RELAY-MTA-document-body>
                A RELAY-MTA document contains the full description of a
                single RELAY-MTA.  Only one community is allowed.
                Since some of the information is community dependent,
                it would not be easily possible to have a single
                RELAY-MTA document used in different communities.

      <RELAY-MTA-document-Identifier> ::= \
                            "RELAY-MTA: " <UniqueRELAY-MTAkey> <CR>

      <RELAY-MTA-document-body> ::= <Status> <connection-info> \
                            <contact-info>

      <Status> ::= "Status: " ("primary" | "secondary") <CR>
                This defines if the RELAY-MTA has 'primary' or



Eppenberger                                                    [Page 13]

RFC 1465        Routing Coordination for X.400 Services         May 1993


                'secondary' status.  See section 4.3 and 6 for more
                information.

      <connection-info> ::= <password> <RTS> \
                            {<called-connection><calling-connection>}\
                            [<system>] \
                            [<local-domain>] \
                            [<echo-server>]
                More than one set of connection information may be
                present for RELAY-MTAs supporting several networks and
                protocol stacks.

      <password> ::= "Password: " \
                            ("secret" | "none" | \
                            "value=\"" 'password' "\"") <CR>
                If the keyword none is present, then no password is
                sent with the MTAname when this MTA initiates an RTS
                connection or responds to an incoming connection.
                Password: none

                If the keyword secret is present, then the connection
                needs a password which is not made publicly available.
                (For example, a community might keep a list of the
                passwords at the central coordination point.  The list
                would then be faxed to the RELAY-MTA managers.)
                Password: secret

                A password must be documented using the
                value="password" notation.  The double quotes around
                the password are needed, consider the case of a single
                blank as a password.
                Password: value=" "
                Password: value="nume-n-ine"

      <RTS> ::= <dialog-mode> \
                            [<checkpoint-size> <window-size>]

      <dialog-mode> ::= "RTS-dialog-mode: " \
                            ("TWA" | "MONOLOGUE") <CR>

      <checkpoint-size> ::= "RTS-checkpoint-size: " \
                            'checkpoint size' <CR>

      <window-size> ::= "RTS-window-size: " \
                            'window size' <CR>

      <called-connection> ::= "Called-address: " \
                            <Service-type> "; " \



Eppenberger                                                    [Page 14]

RFC 1465        Routing Coordination for X.400 Services         May 1993


                            <P-address> "; " <MTS> \
                            ["; " <Service-priority>] <CR>

      <MTS> ::= "MTS-T" | "MTS-TP" | "MTS-TP-84"
                MTS-T:     mts-transfer
                MTS-TP:    mts-transfer-protocol
                MTS-TP-84: mts-transfer-protocol-1984
                See ISO 10021-6, Section 3, chapter 11.1 for more
                details on this matter.  X.400(84) systems only support
                mts-transfer-protocol-1984.

      <Service-priority> ::= 'Integer 0..99'
                The lowest Integer corresponds to the highest priority
                as in DNS.  It is possible to set different priorities
                for each service type.  This may be chosen, for
                example, to distribute the load amongst different
                networks according to their available bandwidth.

      <calling-connection> ::= "Calling-address: " \
                            <Service-type> "; " \
                            <P-address> <CR>
                Since called and calling network addresses may differ
                in certain configurations and some X.400 systems do
                validation on calling network addresses, it is
                important to have this information in the RELAY-MTA
                document.  (Note: a calling X.121 address might change
                if the X.25 switch is reconfigured.  This will stop a
                RELAY-MTA from connecting to other RELAY-MTAs using
                address validation without having changed anything at
                the higher layers!)

      <system> ::= "System: HW=" 'computer type' "; " \
                            "OS=" 'operating system' "; " \
                            "SW=" 'MHS  software' <CR>
                It is optional to provide HW/SW information.
                Experience, however, has shown that a number of
                communication problems were more easily identified and
                solved with this information present and up-to-date.

      <local-domain> ::= "LocalDomain: " <MHS-subtree> <CR>
                This is a useful but optional extension to the
                documentation.
                The <MHS-subtree> is local to the RELAY-MTA.  The <MHS-
                subtree> attributes might be used together with
                S=nosuchuser; to do connectivity and availability
                tests.





Eppenberger                                                    [Page 15]

RFC 1465        Routing Coordination for X.400 Services         May 1993


      <echo-server> ::= "EchoServer: " <X.400 address> <CR>
                Some of the RELAY-MTAs might offer an echo server
                functionality.  It does make sense to document this in
                the RELAY-MTA document for test purpose.  This field is
                optional.

      <contact-info> ::= {"Administrator: " <UniquePersonKey> <CR>}
                The contact details for the RELAY-MTA administrator can
                be found in the appropriate PERSON document.  It is
                possible to document a whole team using a distribution
                list if this is desired.  It is generally better to
                document one or more 'real' persons.

5.4 The DOMAIN document

      <DOMAIN-document> ::= <Community-Identifier> \
                            <Update-info> \
                            <DOMAIN-document-body>

      <DOMAIN-document-body>::= {<Domain-entry>} <responsible> \
                            {<Relay>}

      <Domain-entry> ::= "Domain: " <OR-matching> <MHS-subtree> <CR>
                Note that it is not allowed to have equal <Domain-
                entry> lines in different DOMAIN documents belonging to
                the same MHS community.  A Domain-entry line can only
                appear in one DOMAIN document.

      <OR-matching> ::=  ( "* " | "= " )
                This qualifier defines how the following OR address
                attributes should be handled for the routing algorithm.
                If a '*' is present, a destination address of a message
                is matched by the "Domain:" entry if at least the OR
                address attributes in the "Domain:" entry are equal to
                the destination address.
                If a "=" is present, a destination address of a message
                is matched by the "Domain:" entry if there are exactly
                the same OR attributes in the destination address as in
                the "Domain:" entry.  (This restriction works for OU4,
                OU3, OU2, OU1, O, P, A and C only.)
                Example:
                a) Domain: * P=switch; A=arcom; C=ch;
                b) Domain: = P=switch; A=arcom; C=ch;
                The address S=eppenberger; P=switch; A=arcom; C=ch;
                matches both cases, a) and b).
                The address S=eppenberger; O=unibe; P=switch; A=arcom;
                C=ch; matches only case a).




Eppenberger                                                    [Page 16]

RFC 1465        Routing Coordination for X.400 Services         May 1993


      <responsible> ::= {"Administrator: " <UniquePersonKey> <CR>}
                This is the person responsible for the listed domains.
                His task is to get the agreement of the relaying
                RELAY-MTAs and keep the DOMAIN document up-to-date.
                This person is the only one authorized to make changes
                to this document.  Note that multiple administrators
                may be listed.

      <Relay> ::=         "Relay: " \
                            ( 'UniqueRELAY-MTAkey' | \
                            "Internet-SMTP" ) "; " \
                            <RELAY-MTA-Priority> <CR>
                The priority is used to define the sequence in which
                different RELAY-MTAs may be tried in case of failure.
                A lower integer corresponds to a higher priority as in
                DNS.  Priorities 0..49 are used to indicate backup
                RELAY-MTAs.  Priorities 50..99 are used for RELAY-MTAs
                not acting as backup but as relay service provider for
                a network service type not supported by the main
                RELAY-MTA.
                The keyword "Internet-SMTP" is a placeholder for an
                RFC1327 gateway connected to Internet. The RELAY-MTA
                manager selects a gateway of his choice.

      <RELAY-MTA-Priority> ::= <Integer 0..99>

5.5 The PERSON document

      <PERSON-document> ::= <Community-Identifier> \
                            <Update-info> \
                            <PERSON-document-identifier> \
                            <PERSON-document-body>

      <PERSON-document-identifier> ::= "Key: " <UniquePersonKey> <CR>

      <PERSON-document-body>::= <Name> {<EMail>} {<RFC822>} \
                            <Phone> <Fax> <Mail> <Operation>

      <Name>  ::= "Name: " 'name of person' <CR>
                The name of the person is given.  The issue of the
                character set problem is not addressed in this
                document.  Especially international communities should
                restrict themselves to IA5 or ASCII.

      <RFC822> ::= "RFC822: " <RFC-822-address> <CR>
                This is the RFC-822 address of the person.  It is often
                a big help to know the RFC822 address of someone, for
                example if the X.400 system is not reachable.  This is



Eppenberger                                                    [Page 17]

RFC 1465        Routing Coordination for X.400 Services         May 1993


                also the reason why it is possible to provide multiple
                OR and RFC822 addresses.  The first one is considered
                the primary one.

6. Routing rules

   All the users within the MHS community have the right to send
   messages to each other.  The general agreement is that the RELAY-MTA
   infrastructure is used according to the following routing rules.
   More direct connections based on bilateral agreements are fully
   accepted.

   A primary or secondary RELAY-MTA must allow incoming connections from
   all other primary and secondary RELAY-MTAs with a common stack.
   Primary RELAY-MTAs must be able to connect to all other primary
   RELAY-MTAs which share a common stack.  A secondary RELAY-MTA must
   connect to at least one primary RELAY-MTA.

   A message arriving at a RELAY-MTA must either be sent to the next
   RELAY-MTA based on the DOMAIN documents of the MHS community or it is
   sent to an MTA closer to the destination based on local routing
   decisions.  The following algorithm must be used when forwarding a
   message to the next RELAY-MTA:

      1) Select the relevant DOMAIN document by searching for a match of
      the Recipient address in the message with the entries in the
      document.

      If your own RELAY-MTA appears in this list, this indicates one of
      the following:

      - You offered relay services for another RELAY-MTA with higher
        priority.  Continue with step 2 to decide on the next RELAY-MTA.

      - Your RELAY-MTA is the final destination according the DOMAIN
        document of your community.  You need to forward the message to
        the final destination according local routing information.

      2) From the list of RELAY-MTAs select those that have at least one
      common network service type with your own RELAY-MTA.

      3) Now delete all secondary RELAY-MTAs from the list where no
      direct connection is desired.  For remaining RELAY-MTAs in the
      list no difference is made anymore between primary and secondary
      status.

      4) Select from this reduced set of RELAY-MTAs the one with the
      highest RELAY-MTA-priority.  If there is more than one RELAY-MTA



Eppenberger                                                    [Page 18]

RFC 1465        Routing Coordination for X.400 Services         May 1993


      having the same priority, then select a RELAY-MTA of your choice.
      If your own RELAY-MTA appears in that list, then you are not
      allowed to send to a RELAY-MTA with lower or equal priority.

      5) If there are no service-priorities set in the corresponding
      RELAY-MTA document indicating which service type to use, you are
      free to choose the service type for connecting to the RELAY-MTA.
      However, if there are specific priorities set then select the
      service type with the highest priority.

      6) If the connection fails then try other service types in the
      sequence of descending priority.

      7) If no connection works for the selected RELAY-MTA, then check
      in the list for the one with the same priority, if possible, or
      else select one with the next lower priority.  If there is another
      RELAY-MTA with a RELAY-MTA-priority between 0..49, then select it
      and proceed at step 5.  Without another RELAY-MTA to try the
      currently selected RELAY-MTA will be retried.

6.1 How to use RELAY-MTA-priorities

   An example helps to explain the usage of RELAY-MTA-priorities.
   Internet/TCP/RFC1006 and Public-X.25/X.25/TP0 are mandatory service
   types in the community REMOTEmail.  The MHS domain P=REMOTE; A=ARCOM;
   C=CH; operates MTA-B, only connected to public X.25.  A second
   RELAY-MTA which is connected to both, Internet and public X.25 is
   needed to offer relay services.  A connection using Internet is
   considered cheap in this example.  Both service types are available
   at MTA-A.  Since MTA-B is the only RELAY-MTA responsible for relaying
   messages to P=REMOTE; A=ARCOM; C=CH; to the final destination it must
   have the highest priority.

      Community: REMOTEmail
      Domain: * P=REMOTE; A=ARCOM; C=CH;
      RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-B; 20
      RELAY-MTA:  P=MTA-C; A=ARCOM; C=CH;MTAname=MTA-C; 80

                                       __________________________
      +-------+    X.25     +-------+ (                          )
      | MTA-A +-------------+ MTA-B +-( P=REMOTE; A=ARCOM; C=CH; )
      +-------+             +-------+ (__________________________)
               \           /
         TCP/IP \         /X.25
                 +-------+
                 | MTA-C |
                 +-------+




Eppenberger                                                    [Page 19]

RFC 1465        Routing Coordination for X.400 Services         May 1993


   If MTA-A needs to relay a message for P=REMOTE; A=ARCOM; C=CH; then
   the rules of chapter 6 are evaluated:

        1. MTA-B and MTA-C are possible destinations

        2. MTA-B and MTA-C are reachable from MTA-A

        3. MTA-B is a primary RELAY-MTA (not relevant in this example)

        4. MTA-B has the highest priority.

        5. MTA-B doesn't have specific service type lines documented.
           MTA-A chooses public X.25, since it is the only possibility
           to connect to MTA-B.

        6. No other service types are available if the connection
           fails.

        7. MTA-C has a priority of 80, it is not a backup RELAY-MTA.
           MTA-A must spool the message and try to connect directly to
           MTA-B.

   The organisation running MTA-A could save money by sending messages
   for the MHS domain P=REMOTE; A=ARCOM; C=CH; via MTA-C.  Since the
   connection between MTA-C and the destination MTA-B is also expensive,
   the organisation running MTA-C would have to pay for external relay
   traffic.  Setting a lower priority for MTA-C forces the other RELAY-
   MTAs with public X.25 connectivity to take their share of the cost.

   Note that forcing other RELAY-MTAs to use a specific stack should be
   avoided wherever possible by offering RELAY-MTAs with equal priority
   for all mandatory network services.  This can be an important
   financial issue for MHS communities spanning several organisations,
   it is not relevant in general for an MHS community within a single
   organisation.

6.2 How to use RELAY-MTA-priorities for backup RELAY-MTAS

   Two RELAY-MTAs offer real backup connectivity for the MHS domain
   P=REMOTE; A=ARCOM; C=CH;.  It is therefore possible to set RELAY-MTA
   priorities in the range of 0..49 for both RELAY-MTAs.  MTA-B will be
   the preferred one since it has the higher priority.  If the
   connection to MTA-B fails, a sending RELAY-MTA may immediately try to
   connect to MTA-C.

      Community: REMOTEmail
      Domain: * P=REMOTE; A=ARCOM; C=CH;
      RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-B; 10



Eppenberger                                                    [Page 20]

RFC 1465        Routing Coordination for X.400 Services         May 1993


      RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-C; 30

                                       __________________________
      +-------+             +-------+ (                          )
      | MTA-A +-------------+ MTA-B +-( P=REMOTE; A=ARCOM; C=CH; )
      +-------+             +-------+ (__________________________)
               \                     /
                \           +-------+
                 -----------+ MTA-C |
                            +-------+

6.3 Load Sharing

   It is possible to set equal priorities to do some sort of load
   sharing.  However, most implementations are not able to do random
   selection of RELAY-MTAs with equal priorities but have a fixed
   configuration.  If load sharing is really needed then it is suggested
   to split up the MHS domain into several MHS subtrees and document
   them separately with a set of RELAY-MTAs with different priorities.

   An example is provided for illustration of the first possibility with
   equal RELAY-MTA-priorities:

      Community: REMOTEmail
      Domain: * P=REMOTE; A=ARCOM; C=CH;
      RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-B; 10
      RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-C; 10
          _               __________________________
           )  +-------+  (                          )
           )--+ MTA-B +--( P=REMOTE; A=ARCOM; C=CH; )
           )  +-------+  (__________________________)
           )            /
           )  +-------+/
           )--+ MTA-C |
          _)  +-------+

      And here is an example where the MHS domain
    C=CH;ADMD=ARCOM;PRMD=REMOTE;O=Big-Org is documented with its own
    DOMAIN document: Note that in this example both RELAY-MTAs serve
    as backup RELAY-MTAs.

      Community: REMOTEmail
      Domain: * P=REMOTE; A=ARCOM; C=CH;
      RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-B; 10
      RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-C; 30

      Community: REMOTEmail
      Domain: * O=Big-Org; P=REMOTE; A=ARCOM; C=CH;



Eppenberger                                                    [Page 21]

RFC 1465        Routing Coordination for X.400 Services         May 1993


      RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-C; 10
      RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-B; 30
          _               __________________________
           )  +-------+  (                          )
           )--+ MTA-B +--( P=REMOTE; A=ARCOM; C=CH; )
           )  +-------+  (__________________________)
           )           \/
           )           /\ _____________________________________
           )  +-------+  (                                     )
           )--+ MTA-C |--( O=Big-Org; P=REMOTE; A=ARCOM; C=CH; )
          _)  +-------+  (_____________________________________)

7. Open issues

   Currently there are about 35 RELAY-MTAs within the COSINE-MHS
   service.  A rough guess is that a network with about 60 RELAY-MTAs is
   still manageable provided there are automated tools for MTA
   configuration.  If there are more MTAs applying for RELAY-MTA status
   in an MHS community, then either an X.500 based solution should be
   ready or a core set of about 30 well operated super-RELAY-MTAs should
   form a backbone, documented within a specific MHS community.

   Since the RELAY-MTA document contains information about the supported
   X.400 version (84 or 88), it is possible for an X.400(88) system to
   select with higher priority an (88)RELAY-MTA.  The rules in chapter 6
   could be modified to select X.400(88) systems first if the sending
   RELAY-MTA is an (88) system itself.  The issue of how to establish an
   X.400(88) RELAY-MTA infrastructure within an MHS community is for
   further study.






















Eppenberger                                                    [Page 22]

RFC 1465        Routing Coordination for X.400 Services         May 1993


Appendix A:  Document examples for the COSINE-MHS community

   Instead of creating artificial documents to show an example document
   set, this appendix contains extracts from a real operational X.400
   service.  The research and development community in Europe has used
   X.400 for several years.  This proposal was initially written to
   address this community only and solve the urgent routing and
   coordination problems.  Contributions from different experts have
   made it more flexible and therefore hopefully useful for other MHS
   communities.

Appendix A1:  The COMMUNITY document

  Community: COSINE-MHS
  # The COSINE-MHS service is a MHS community formed by the European
  # academic and research networks with additional contacts in all
  # other continents.
  #
  # The coordination is done by the COSINE-MHS project team.
  #
  Update: FORMAT=V3; DATE=921218; START=930201
  #
  Address: S=Project-Team; O=SWITCH; P=SWITCH; A=ARCOM; C=CH;
  #
  Phone: +41 1-262-31-43
  Fax:   +41 1-261-81-88
  #
  Mail:  SWITCH Head Office /
         MHS Coordination Service /
         Limmatquai 138 /
         CH-8001 Zurich /
         Switzerland
  #
  Reachable: 09:00-12:00; 14:00-17:30; UTC+1
  #
  Mail-server: S=mhs-server; O=switch; OU1=nic;
               P=SWITCH; A=ARCOM; C=CH;
  FTP-server:  nic.switch.ch; cosine; user@domain
  #
  Macro: Int-X25(80)        TELEX+00728722+X.25(80)+01+
  Macro: Internet-RFC-1006  TELEX+00728722+RFC-1006+03+
  Macro: IXI                TELEX+00728722+X.25(80)+06+
  #
  Mandatory-Service: Public-X.25/X.25/TP0
  # The public X.25 network.  X.25 is supported in most X.400
  # applications and mandatory in X.400 anyhow.
  #
  Mandatory-Service: Internet/TCP/RFC1006



Eppenberger                                                    [Page 23]

RFC 1465        Routing Coordination for X.400 Services         May 1993


  # The Internet, standing for the global TCP/IP network of the
  # research and development community
  # RFC1006 is considered a solution to ease migration to OSI. It will
  # be replaced by TP4/CLNS as soon as a reliable service is
  # available.
  #
  Optional-Service: Int-CLNS/CLNS/TP4
  # The RARE Connectionless pilot service.  Current participants are
  # NORDUnet, SURFnet, CERN, NSFnet and SWITCH.
  #
  Optional-Service: EMPB-X.25/X.25/TP0
  # The International X.25 Infrastructure covering most countries in
  # Europe.  The absence of volume tariffs make it a preferred choice.

Appendix A2:  Example of a RELAY-MTA document

  Community: COSINE-MHS
  #
  Update: FORMAT=V3; DATE=921218; START=930201
  #
  RELAY-MTA: P=SWITCH; A=ARCOM; C=CH; MTAname=chx400.switch.ch
  #
  Status: primary
  #
  Password: none
  RTS-dialog-mode: MONOLOGUE
  #
  Called-address:  Public-X.25/X.25/TP0;
                   "591"/Int-X25(80)=22847971014520+CUDF+03010100;
                   MTS-TP-84
  Calling-address: Public-X.25/X.25/TP0;
                   Int-X25(80)=22847971014520;
  #
  Called-address:  Internet/TCP/RFC1006;
                   "591"/Internet-RFC-1006=chx400.switch.ch;
                   MTS-TP-84
  Calling-address: Internet/TCP/RFC1006;
                   Internet-RFC-1006=chx400.switch.ch
  #
  Called-address:  EMPB-X.25/X.25/TP0;
                   "591"/IXI=20432840100520+CUDF+03010100;
                   MTS-TP-84
  Calling-address: EMPB-X.25/X.25/TP0;
                   IXI=20432840100520;
  #
  Calling-address: Int-CLNS/CLNS/TP4;
                   "591"/NS+39756F11111111010000014560AA00040005E100;
                   MTS-TP-84



Eppenberger                                                    [Page 24]

RFC 1465        Routing Coordination for X.400 Services         May 1993


  Called-address:  DCC+756+x11111111010000014560AA00040005E100
  #
  # For X.400(88) over CLNS
  #
  Calling-address: Int-CLNS/CLNS/TP4;
                   "592"/NS+39756F11111111010000014560AA00040005E100;
                   MTS-T
  Called-address:  DCC+756+x11111111010000014560AA00040005E100
  #
  System: HW=SUN 4/690MP; OS=SunOS 4.1.1; SW=PP-6.0
  #
  LocalDomain: O=switch; OU1=chx400; P=switch; A=arcom; C=ch;
  #
  EchoServer:  S=echo; O=switch; OU1=chx400; P=switch; A=arcom; C=ch;
  #
  Administrator: CN=Felix Kugler, O=SWITCH, C=CH
  Administrator: CN=Christoph Graf, O=SWITCH, C=CH

Appendix A3:  Example of a DOMAIN document

  Community: COSINE-MHS
  #
  Update: FORMAT=V3; DATE=921218; START=930201
  ##
  Domain: *     P=SWITCH; A=ARCOM; C=CH;
  Domain: *     P=SANDOZ; A=ARCOM; C=CH;
  Domain: *        P=ABB; A=ARCOM; C=CH;
  Domain: *        P=UBS; A=ARCOM; C=CH;
  Domain: *      P=ISREC; A=ARCOM; C=CH;
  Domain: *    P=ALCATEL; A=ARCOM; C=CH;
  Domain: *        P=ITU; A=ARCOM; C=CH;
  Domain: * P=OSILABMAIL; A=ARCOM; C=CH;
  Domain: *        P=WHO; A=ARCOM; C=CH;
  Domain: *       P=CERN; A=ARCOM; C=CH;
  Domain: *   P=CERBERUS; A=ARCOM; C=CH;
  #
  Administrator: CN=Christoph Graf, O=SWITCH, C=CH
  Administrator: S=postmaster; O=SWITCH; P=SWITCH; A=ARCOM; C=CH;
  #
  RELAY-MTA: P=SWITCH; A=ARCOM; C=CH; MTAname=chx400.switch.ch; 0
  #
  RELAY-MTA: P=SWITCH; A=ARCOM; C=CH; MTAname=vms.switch; 10

Appendix A4:  Example of a PERSON document

  Community: COSINE-MHS
  #
  Update: FORMAT=V3; DATE=921218; START=930201



Eppenberger                                                    [Page 25]

RFC 1465        Routing Coordination for X.400 Services         May 1993


  #
  Key: CN=Christoph Graf, O=SWITCH, C=CH
  #
  Name:    Christoph Graf
  #
  Address: S=Graf; O=SWITCH; P=SWITCH; A=ARCOM; C=CH;
  RFC822:  Graf@switch.ch
  #
  Phone:   +41 1 2565454
  Fax:     +41 1 2618133
  #
  Mail:    SWITCH Head Office /
           Christoph Graf /
           Limmatquai 138 /
           CH-8001 Zurich /
           Switzerland
  #
  Reachable: 09:00-12:00; 14:00-17:30; UTC+0100

































Eppenberger                                                    [Page 26]

RFC 1465        Routing Coordination for X.400 Services         May 1993


Appendix B:  BNF Definitions

      <called-connection> ::= "Called-address: " \
                            <Service-type> "; " \
                            <P-address> "; " <MTS> \
                            ["; " <Service-priority>] <CR>

      <calling-connection> ::= "Calling-address: " \
                            <Service-type> "; " \
                            <P-address> <CR>

      <checkpoint-size> ::= "RTS-checkpoint-size: " \
                            'checkpoint size' <CR>

      <COMMUNITY-document> ::= <Community-Identifier> \
                            <Update-info> \
                            <COMMUNITY-document-body>

      <COMMUNITY-document-body> ::= <Coordination> \
                            [{<Macro-definition>}] \
                            {<Connections>}

      <Community-Identifier> ::= "Community: " \
                            ('community name' | <DirectoryName>) <CR>

      <connection-info> ::= <password> <RTS> \
                            {<called-connection><calling-connection>}\
                            [<system>] \
                            [<local-domain>] \
                            [<echo-server>]

      <Connections> ::= {<mandatory-service>} \
                            {[<optional-service>]}

      <contact-info> ::= {"Administrator: " <UniquePersonKey> <CR>}

      <Coordination> ::= <EMail> <Phone> <FAX> \
                            <Mail> <Operation> <File-server>

      <Country-Code> ::= 'Two Character Country Code ISO-3166'

      <dialog-mode> ::= "RTS-dialog-mode: " \
                            ("TWA" | "MONOLOGUE") <CR>

      <DirectoryName> ::= 'Distinguished Name'

      <DOMAIN-document> ::= <Community-Identifier> \
                            <Update-info> \



Eppenberger                                                    [Page 27]

RFC 1465        Routing Coordination for X.400 Services         May 1993


                            <DOMAIN-document-body>

      <DOMAIN-document-body>::= {<Domain-entry>} <responsible> \
                            {<Relay>}

      <Domain-entry> ::= "Domain: " <OR-matching> <MHS-subtree> <CR>

      <echo-server> ::= "EchoServer: " <X.400 address> <CR>

      <EMail> ::= "Address: " <X.400 address> <CR>

      <email-server> ::= "Mail-server: "<X.400 address> <CR>

      <extension> ::= 'local extension'

      <Fax> ::= "Fax: " <tel-no-list> <CR>

      <File-server> ::= <email-server> [{<FTP-server>}] \
                            [{<FTAM-server>]}

      <FTAM-server> ::= "FTAM-server: " <P-address> "; "\
                            'account-name' ["; " 'password'] \
                            ["; X.500 " <DirectoryName>] <CR>

      <FTP-server> ::= "FTP-server: " 'domain name' "; " \
                            'account-name' ["; " 'password'] <CR>

      <int-pref> ::= 'international prefix'

      <local-domain> ::= "LocalDomain: " <MHS-subtree> <CR>

      <Macro-definition> ::= "Macro: " 'Macro name' " " \
                            'Macro value' <CR>

      <Mail> ::= "Mail: " 'postal address information' <CR>

      <mandatory-service> ::= "Mandatory-Service: " \
                            <Service-type> <CR>

      <MHS-subtree> ::= ["O=" 'Organization-name' "; "] \
                            ["OU1="'OrganizationalUnit'"; "\
                            ["OU2=" 'OrganizationalUnit' "; " \
                            ["OU3=" 'OrganizationalUnit' "; " \
                            ["OU4=" 'OrganizationalUnit' "; "]]]] \
                            ["P=" 'PRMDname' "; "] \
                            "A=" 'ADMDname' "; " \
                            "C=" <Country-Code> ";"




Eppenberger                                                    [Page 28]

RFC 1465        Routing Coordination for X.400 Services         May 1993


      <MTS> ::= "MTS-T" | "MTS-TP" | "MTS-TP-84"

      <Name>  ::= "Name: " 'name of person' <CR>

      <national number> ::= 'national telephone number'

      <Network-name> ::= 'Name of a network'

      <Network-service> ::= 'Name of a network service'

      <Operation> ::= "Reachable: "  {<time> "-" <time> "; "} \
                            <Time-zone> <CR>

      <optional-service> ::= "Optional-Service: " \
                            <Service-type> <CR>

      <OR-matching> ::=  ( "* " | "= " )

      <P-address> ::= 'String encoded Presentation Address'

      <password> ::= "Password: " \
                            ("secret" | "none" | \
                            "value=\"" 'password' "\"") <CR>

      <PERSON-document> ::= <Community-Identifier> \
                            <Update-info> \
                            <PERSON-document-identifier> \
                            <PERSON-document-body>

      <PERSON-document-identifier> ::= "Key: " <UniquePersonKey> <CR>

      <PERSON-document-body>::= <Name> {<EMail>} {<RFC822>} \

      <Phone> ::= "Phone: " <tel-no-list> <CR>

      <Relay> ::=         "Relay: " \
                            'UniqueRELAY-MTAkey' "; " \
                            <RELAY-MTA-Priority> <CR>

      <RELAY-MTA-document> ::= <Community-Identifier> \
                            <Update-info> \
                            <RELAY-MTA-document-Identifier> \
                            <RELAY-MTA-document-body>

      <RELAY-MTA-document-body> ::= <Status> <connection-info> \
                            <contact-info>

      <RELAY-MTA-document-Identifier> ::= \



Eppenberger                                                    [Page 29]

RFC 1465        Routing Coordination for X.400 Services         May 1993


                            "RELAY-MTA: " <UniqueRELAY-MTAkey> <CR>

      <RELAY-MTA-Priority> ::= <Integer 0..99>

      <responsible> ::= {"Administrator: " <UniquePersonKey> <CR>}

      <RFC822> ::= "RFC822: " <RFC-822-address> <CR>

      <RTS> ::= <dialog-mode> \
                            [<checkpoint-size> <window-size>]

      <Service-priority> ::= 'Integer 0..99'

      <Service-type> ::= <Network-name> "/" \
                            <Network-service> "/" \
                            <Transport-Protocol>

      <Status> ::= "Status: " ("primary" | "secondary") <CR>

      <system> ::= "System: HW=" 'computer type' "; " \
                            "OS=" 'operating system' "; " \
                            "SW=" 'MHS  software' <CR>

      <tel-no-list> ::= <tel-number> [{"; " <tel-number>}]

      <tel-number> ::=  {"+" <int-pref> " " <national number> \
                            [" x" <extension>]}

      <time> ::= 'hh:mm'

      <Time-zone> ::= ("UTC+" | "UTC-") 'hhmm'

      <Transport-Protocol> ::= 'Name of a transport protocol'

      <UniquePersonKey> ::= (<X.400 address> | <DirectoryName> )

      <UniqueRELAY-MTAkey> ::= (([ "P=" 'PRMDname' "; " ] \
                            ["A=" 'ADMDname' "; " ] \
                            "C=" <Country-Code> "; " \
                            "MTAname=" 'MTAname')
                            | <DirectoryName> )

      <Update-info> ::= "Update: FORMAT=V3; DATE=" 'yymmdd' \
                            "; START=" 'yymmdd' \
                            ["; END=" 'yymmdd'] <CR>

      <window-size> ::= "RTS-window-size: " \
                            'window size' <CR>



Eppenberger                                                    [Page 30]

RFC 1465        Routing Coordination for X.400 Services         May 1993



      <X.400 address> ::= 'OR address, ISO 10021-2 Annex F'

      <X.400 routing coordination document set> ::= \
                            <COMMUNITY-document> \
                            { <RELAY-MTA-document> } \
                            { <DOMAIN-document> } \
                            { <PERSON-document> }

Security Considerations

   Security issues are not discussed in this memo.

Author's Address

   Urs Eppenberger
   SWITCH Head Office
   Limmatquai 138
   CH-8001 Zurich
   Switzerland

   Phone: +41 1 261 8112
   Fax:   +41 1 261 8133

   EMail: Eppenberger@switch.ch
          S=Eppenberger; O=SWITCH; P=SWITCH; A=ARCOM; C=CH;

   Comments to the document may also be sent to the distribution list
   wg-msg@rare.nl of the RARE Working Group on Mail and Messaging.






















Eppenberger                                                    [Page 31]