home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1400s / rfc1465.txt < prev    next >
Text File  |  1993-06-24  |  67KB  |  1,739 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                     U. Eppenberger
  8. Request for Comments: 1465                                        SWITCH
  9.                                                                 May 1993
  10.  
  11.  
  12.               Routing Coordination for X.400 MHS Services
  13.           Within a Multi Protocol / Multi Network Environment
  14.                    Table Format V3 for Static Routing
  15.  
  16. Status of this Memo
  17.  
  18.    This memo defines an Experimental Protocol for the Internet
  19.    community.  Discussion and suggestions for improvement are requested.
  20.    Please refer to the current edition of the "IAB Official Protocol
  21.    Standards" for the standardization state and status of this protocol.
  22.    Distribution of this memo is unlimited.
  23.  
  24. 1. Introduction
  25.  
  26.    The usage of the X.400 Message Handling System (MHS) is growing
  27.    rapidly, especially in the commercial world but much interest can
  28.    also be found in the academic and research community.  New networks
  29.    and new addresses come into use each and every day.  The underlying
  30.    technology for different X.400 networks can vary depending on the
  31.    transport network and the X.400 MHS implementations used.  As a large
  32.    number of X.400 implementations now support multiple stacks, this
  33.    offers the chance of implementing a world wide message handling
  34.    service using the same electronic mail standard and, therefore,
  35.    without the need of gateways with service reduction and without the
  36.    restriction to a single common transport network.  This, however,
  37.    leads to several problems for the MHS manager, two of which are:
  38.  
  39.    - Where do I route new X.400 addresses and
  40.  
  41.    - How do I connect to a MHS domain that uses an underlying
  42.      technology that I do not support.
  43.  
  44.    This document proposes short term solutions to these problems.  It
  45.    proposes a strategy for maintaining and distributing routing
  46.    information and shows how messages can travel over different networks
  47.    by using multi stack MTAs as relays.  Document formats and
  48.    coordination procedures bridge the gap until an X.500 directory
  49.    service is ready to store the needed connectivity and routing
  50.    information.  The format has been designed to allow the information
  51.    to be stored in an X.500 directory service while managers without
  52.    directory service access may still use a table based approach.
  53.  
  54.    The routing structure proposed can be applied to a global MHS service
  55.  
  56.  
  57.  
  58. Eppenberger                                                     [Page 1]
  59.  
  60. RFC 1465        Routing Coordination for X.400 Services         May 1993
  61.  
  62.  
  63.    but may also be used at a national level or even within an
  64.    organisation.
  65.  
  66.    Many experts from IETF X.400-Operations Group and RARE Working Group
  67.    1 on Message Handling Systems have read drafts of this document and
  68.    contributed ideas and solutions.  I would especially like to thank
  69.    Harald Alvestrand, Erik Huizer, Marko Kaittola, Allan Cargille and
  70.    Paul-Andre Pays.
  71.  
  72.    This is the third version of a table format.  The first one was in
  73.    use within COSINE-MHS for about two years.  A second version with
  74.    major enhancements was then proposed which has been in use for the
  75.    past year.  The third version will probably be the last one before it
  76.    will be possible to switch to dynamic, directory service based
  77.    routing.
  78.  
  79. 2. Terminology
  80.  
  81.    MHS community
  82.  
  83.       One or more MHS domains form an MHS community.  Mail exchange
  84.       between these MHS domains is defined by the coordination
  85.       procedures within this document.  Examples of such communities are
  86.       the Global Open MHS service GO-MHS and the COSINE-MHS service.
  87.  
  88.    MHS domain
  89.  
  90.       One or more MHS subtrees form an MHS domain.  This is a purely
  91.       administrative grouping of MHS subtrees.  It is helpful, if
  92.       someone is responsible for several MHS subtrees, to refer to an
  93.       MHS domain instead of listing all the subtrees.
  94.  
  95.    MHS subtree
  96.  
  97.       An MHS subtree consists of the total of the mailboxes addressable
  98.       within a subtree of the X.400 OR address space.
  99.  
  100.         Example:  O=SWITCH; P=SWITCH; A=ARCOM; C=CH;
  101.  
  102.         MHS domain of SWITCH in Switzerland, consisting of all
  103.         mailboxes with O=SWITCH; P=SWITCH; A=ARCOM; C=CH; in the OR
  104.         address.
  105.  
  106.    RELAY-MTA
  107.  
  108.       An X.400 MTA serving one or several MHS domains.  Note that the
  109.       term WEP -Well Known Entry Point- has been used since the early
  110.       X.400ies (1987/88) until now, giving the wrong impression of a
  111.  
  112.  
  113.  
  114. Eppenberger                                                     [Page 2]
  115.  
  116. RFC 1465        Routing Coordination for X.400 Services         May 1993
  117.  
  118.  
  119.       single entry point (and therefore a single point of failure).
  120.       This document proposes to use the term RELAY-MTA, reflecting more
  121.       clearly the functionality of the MTA.
  122.  
  123.    COSINE-MHS
  124.  
  125.       The COSINE-MHS community is mainly formed by European X.400
  126.       service providers from the academic and research area, each of
  127.       which is a member of RARE.  The COSINE-MHS community is used in
  128.       the annex as an example for the usage of this document in a
  129.       multinational environment.
  130.  
  131. 3. Requirements
  132.  
  133.    X.400 MTAs can communicate using different transport and network
  134.    protocol stacks.  For this document the stacks used in a WAN
  135.    environment need to be considered:
  136.  
  137.                            Stack 1    Stack 2    Stack 3    Stack 4
  138.  
  139.       Transport Layer 4    TP0        TP4        RFC1006    TP0
  140.       Networkservice 1-3   X.25       CLNS       TCP/IP     CONS
  141.  
  142.    A common protocol stack is not the only requirement to enable
  143.    communication between two MTAs.  The networks to which the MTAs
  144.    belong need to be interconnected.  Some well known networks are
  145.    listed together with the stacks they use.
  146.  
  147.       Network                                Stack   Abbreviation
  148.  
  149.       Public Switched Packet Data Networks     1     Public-X.25
  150.       International X.25 Infrastructure EMPB   1,4   EMPB-X.25
  151.       US and European connectionless pilot     2     Int-CLNS
  152.       Internet                                 2,3   Internet
  153.  
  154.    Note that several stacks may be supported over a single network.
  155.    However communication between MTAs is only possible if the MTAs share
  156.    at least a common stack AND a common network.
  157.  
  158.    Unlike SMTP/TCP/IP systems, there is no directory service available
  159.    which would allow an MTA to look up the next MTA to which it should
  160.    submit a message.  Routing within X.400 will continue to be table
  161.    based until a solution using X.500 directory services is available.
  162.  
  163.    Furthermore it is not generally allowed to connect to any MTA even on
  164.    the same network without being registered on the destination MTA.
  165.    These restrictions require a large coordination effort and carefully
  166.    configured and updated systems.
  167.  
  168.  
  169.  
  170. Eppenberger                                                     [Page 3]
  171.  
  172. RFC 1465        Routing Coordination for X.400 Services         May 1993
  173.  
  174.  
  175. 4. Outline of the proposal
  176.  
  177.    This proposal offers a solution for describing information about
  178.    X.400 message routing within an MHS community in RELAY-MTA and DOMAIN
  179.    documents.  Basic information on the MHS community is documented in
  180.    the corresponding COMMUNITY document.  All contact persons and
  181.    RELAY-MTA administrators can be found in PERSON documents.  A future
  182.    X.500 based solution may need extended information to overcome still
  183.    unsolved problems like optimal routing or traffic optimization for
  184.    messages with multiple recipients.  The information collected for the
  185.    intermediate solution however is very basic.  All established
  186.    coordination procedures will help and even speed up the future
  187.    introduction of an X.500 based solution.
  188.  
  189. 4.1 The COMMUNITY document
  190.  
  191.    For each MHS community there exists one single COMMUNITY document
  192.    containing basic information.  First the contact information for the
  193.    central coordination point can be found together with the addresses
  194.    for the file server where all the documents are stored.  It also
  195.    lists network names and stacks to be used in the RELAY-MTA and DOMAIN
  196.    documents.  An MHS community must agree on its own set of mandatory
  197.    and optional networks and stacks.
  198.  
  199. 4.2 The RELAY-MTA document
  200.  
  201.    Every MHS domain in the community may designate one or more MTAs as
  202.    RELAY-MTAs.  These RELAY-MTAs accept incoming connections from the
  203.    RELAY-MTAs of the other MHS domains and in return are allowed to send
  204.    messages to these RELAY-MTAs.  A RELAY-MTA is documented with all the
  205.    necessary connection information in the corresponding RELAY-MTA
  206.    document.
  207.  
  208. 4.3 The DOMAIN document
  209.  
  210.    An MHS domain has a responsible person who sets up the routing
  211.    entries for the domain in the DOMAIN document.  The primary RELAY-
  212.    MTAs listed in the DOMAIN document as serving this MHS domain must,
  213.    TOGETHER, offer at least connectivity to all networks and stacks
  214.    listed as mandatory in the COMMUNITY document.  Optional RELAY-MTAs
  215.    may be added, generally with higher priority, to allow more precise
  216.    routing.
  217.  
  218.    An MHS domain may also decide not to operate a RELAY-MTA.  It will
  219.    then only need agreements with one or more RELAY-MTAs from other MHS
  220.    services which will relay for this domain.  The domain itself,
  221.    however, must either create its own DOMAIN document or document its
  222.    MHS subtrees jointly with another MHS domain.
  223.  
  224.  
  225.  
  226. Eppenberger                                                     [Page 4]
  227.  
  228. RFC 1465        Routing Coordination for X.400 Services         May 1993
  229.  
  230.  
  231.    The structure of the DOMAIN document is very straightforward.  It
  232.    starts off with one or more MHS subtrees, each on its own line.
  233.    After the domains follows a line indicating the responsible person
  234.    for the MHS subtrees mentioned.  Finally the responsible RELAY-MTA(s)
  235.    are listed with appropriate priorities.
  236.  
  237. 4.4 The PERSON document
  238.  
  239.    All administrators and responsible persons are documented in PERSON
  240.    documents.  The RELAY-MTA and DOMAIN documents contain just keys
  241.    pointing to a PERSON document.  If such a person can already be found
  242.    in an X.500 directory service, then the key consists of a
  243.    Distinguished Name, else the key is just its OR address.
  244.  
  245. 4.5 Coordination
  246.  
  247.    This approach requires an identified coordination point.  It is up to
  248.    the MHS community to decide on the level of coordination and support
  249.    to be provided and on the funding mechanisms for such activities.
  250.    Basic information can be found in the COMMUNITY document.  The
  251.    following list of support activities is considered mandatory for an
  252.    operational service:
  253.  
  254.     - New RELAY-MTAs joining the service are tested and support is
  255.       given to create the RELAY-MTA document.
  256.  
  257.     - New MHS domains joining the MHS community get assistance to set
  258.       up RELAY-MTA(s) and/or find appropriate RELAY-MTA(s) and to
  259.       create DOMAIN documents.
  260.  
  261.     - Updated documents are announced to the RELAY-MTA managers and
  262.       responsible persons for the DOMAIN documents unless automatic
  263.       distribution is used.
  264.  
  265.     - All the RELAY-MTA, DOMAIN and PERSON documents are made
  266.       available on a file server together with the COMMUNITY document.
  267.       The file server must at least be reachable via email.  MHS
  268.       communities with a big number of documents may consider
  269.       additional access methods like ftp and FTAM.
  270.  
  271.     - Tools should be made available to manage routing tables for the
  272.       X.400 software used on the RELAY-MTAs or to fill in and check
  273.       the documents.  The format of the documents has specifically
  274.       been chosen to enable the use of automated tools.
  275.  
  276.    The RELAY-MTA managers must be aware that a large number of RELAY-
  277.    MTAs in an MHS community may require significant operational
  278.    resources to keep the local routing tables up-to-date and to
  279.  
  280.  
  281.  
  282. Eppenberger                                                     [Page 5]
  283.  
  284. RFC 1465        Routing Coordination for X.400 Services         May 1993
  285.  
  286.  
  287.    constantly monitor the correct functioning of the connections.  On
  288.    the other hand more than one RELAY-MTA with a good connectivity to an
  289.    MHS domain improves the overall robustness of the domain and thus the
  290.    QOS.
  291.  
  292.    MHS communities may decide on additional mandatory requirements for
  293.    the operation of a RELAY-MTA.  These may include a hot line, echo
  294.    services, exchange of statistics, response time to problem reports,
  295.    uptime of the RELAY-MTA, etc.  This will ensure a certain quality of
  296.    service for the end users.
  297.  
  298. 4.6 Routing
  299.  
  300.    The proposal addresses MHS communities spanning several
  301.    organisations.  But it may also be used to manage routing within a
  302.    single organisation or even a global MHS community.
  303.  
  304.    Two kinds of mail relays are defined, the primary RELAY-MTAs and the
  305.    secondary RELAY-MTAs.  A primary or secondary RELAY-MTA must allow
  306.    incoming connections from all other primary and secondary RELAY-MTAs
  307.    with a common stack.  Primary RELAY-MTAs must be able to connect to
  308.    all other primary RELAY-MTAs which share a common stack.  A secondary
  309.    RELAY-MTA must connect to at least one primary RELAY-MTA.
  310.  
  311.    Each MHS community must define update procedures for the routing
  312.    based on the documentation.  Automated update has to be studied
  313.    carefully.
  314.  
  315.    An MHS community should also define procedures for new RELAY-MTAs and
  316.    MHS domains joining the service.  Since the usage of X.400 is growing
  317.    rapidly a flexible but well coordinated way of integrating new
  318.    members into an MHS community is needed.  The proposed documentation
  319.    format supports this by allowing primary and secondary RELAY-MTAs.
  320.    All RELAY-MTAs accept incoming connections from each other.  Sending
  321.    messages can be done by using the primary RELAY-MTAs only.  This
  322.    allows new RELAY-MTAs to join the community as secondary and to get
  323.    primary status when traffic flow increases.  Secondary RELAY-MTAs may
  324.    also require a longer testing period.
  325.  
  326. 5. The documents
  327.  
  328.    The definition is given in BNF-like syntax.  The following
  329.    conventions are used:
  330.  
  331.  
  332.     |    means choice
  333.  
  334.     \    is used for continuation of a definition over several lines
  335.  
  336.  
  337.  
  338. Eppenberger                                                     [Page 6]
  339.  
  340. RFC 1465        Routing Coordination for X.400 Services         May 1993
  341.  
  342.  
  343.  
  344.     []   means optional
  345.  
  346.     {}   means repeated one or more times
  347.  
  348.     ()   is used to group choices
  349.  
  350.     \"   is used for double quotes in a text string
  351.  
  352.     <CR> is a Carriage Return and means that the next section starts
  353.          on its own line.
  354.  
  355.    The definition is complete only to a certain level of detail.  Below
  356.    this level, all expressions are to be replaced with text strings.
  357.    Expressions without more detailed definition are marked with single
  358.    quotes '.  The format and semantics should be clear from the names of
  359.    the expressions and the comments given.
  360.  
  361.    Wherever the BNF definition requires a single blank, multiple blanks
  362.    may be used to increase the readability.  Please note that for some
  363.    field values the number of spaces is significant.
  364.  
  365.    Lines exceeding 80 characters should be wrapped at any convenient
  366.    blank except at blanks which are significant.  The line is continued
  367.    with at least one leading blank.
  368.  
  369.    Comments may be placed anywhere in the document but only on separate
  370.    lines and without splitting wrapped lines.  Such a comment line must
  371.    either start with a '#' sign followed by white space and the comment
  372.    or consist of a single '#' on a single line.
  373.  
  374.    The documents must follow the case of the strings defined in BNF.
  375.    Note that some values, especially connection parameters like TSEL or
  376.    MTA password are case dependant too.
  377.  
  378.    The BNF definitions are ordered top-down.  See Appendix B for an
  379.    alphabetically sorted list.
  380.  
  381.    A set of one COMMUNITY document and several RELAY-MTA, DOMAIN and
  382.    PERSON documents belong together.  The detailed definitions can be
  383.    found in the following chapters.
  384.  
  385.       <X.400 routing coordination document set> ::= \
  386.                             <COMMUNITY-document> \
  387.                             { <RELAY-MTA-document> } \
  388.                             { <DOMAIN-document> } \
  389.                             { <PERSON-document> }
  390.  
  391.  
  392.  
  393.  
  394. Eppenberger                                                     [Page 7]
  395.  
  396. RFC 1465        Routing Coordination for X.400 Services         May 1993
  397.  
  398.  
  399. 5.1 Common Definitions
  400.  
  401.       <DirectoryName> ::= 'Distinguished Name'
  402.                 The string representation of a Distinguished Name is
  403.                 defined in the RFCxxxx.  If a Distinguished Name is
  404.                 used as a key in the documents, then the information
  405.                 can be fetched from the directory instead of checking
  406.                 the appropriate document.  But as long as not all
  407.                 managers in the same community have directory access,
  408.                 the same information must also be present in a
  409.                 document.  Note that Distinguished Names in the context
  410.                 of the routing documents are just used as key strings
  411.                 to point to other documents.
  412.  
  413.       <Community-Identifier> ::= "Community: " \
  414.                             ('community name' | <DirectoryName>) <CR>
  415.                 The 'community name' is a string identifying the MHS
  416.                 community to be used in the first line of all
  417.                 documents.
  418.  
  419.       <UniqueRELAY-MTAkey> ::= (([ "P=" 'PRMDname' "; " ] \
  420.                             ["A=" 'ADMDname' "; " ] \
  421.                             "C=" <Country-Code> "; " \
  422.                             "MTAname=" 'MTAname')
  423.                             | <DirectoryName> )
  424.                 A unique key is needed to identify the RELAY-MTA.  In
  425.                 addition to the MTA name itself, it is proposed to use
  426.                 OR address attributes of the management domain where
  427.                 the RELAY-MTA resides.  ADMD and PRMD fields are both
  428.                 optional and may be used to guarantee uniqueness of the
  429.                 key.  The values used are irrelevant.  Even non-
  430.                 printable characters like @ or ! are acceptable.  The
  431.                 result is not an address but a key string.  A
  432.                 Distinguished Name may be used instead.
  433.  
  434.       <UniquePersonKey> ::= (<X.400 address> | <DirectoryName> )
  435.                 A unique key is necessary to make the links from the
  436.                 documents where a responsible person or an
  437.                 administrator is needed, to the PERSON documents.  It
  438.                 is either the OR address of the person or a
  439.                 Distinguished Name (if the person is already registered
  440.                 in the directory).
  441.  
  442.       <Country-Code> ::= 'Two Character Country Code ISO-3166'
  443.  
  444.       <X.400 address> ::= 'OR address, ISO 10021-2 Annex F'
  445.                 It has been used consequently all over the document.
  446.                 This explains also the syntax of the
  447.  
  448.  
  449.  
  450. Eppenberger                                                     [Page 8]
  451.  
  452. RFC 1465        Routing Coordination for X.400 Services         May 1993
  453.  
  454.  
  455.                 <UniqueRELAY-MTAkey> and the <MHS-subtree>. Examples:
  456.                 S=user; O=org ltd.; OU1=sect1; P=org; A=rel400; C=aq;
  457.                 DDA:RFC-822=we(a)sell.it; P=internet; A= ; C=xx;
  458.                 G=john; I=w; S=doe; P=org; A=rel400; C=aq;
  459.  
  460.       <EMail> ::= "Address: " <X.400 address> <CR>
  461.  
  462.       <tel-no-list> ::= <tel-number> [{"; " <tel-number>}]
  463.  
  464.       <tel-number> ::=  {"+" <int-pref> " " <national number> \
  465.                             [" x" <extension>]}
  466.                 This syntax follows the attribute syntax of the X.500
  467.                 directory based on CCITT E.123.
  468.  
  469.       <int-pref> ::= 'international prefix'
  470.  
  471.       <national number> ::= 'national telephone number'
  472.                 A national number may be written with spaces and
  473.                 hyphens to group the figures.
  474.  
  475.       <extension> ::= 'local extension'
  476.  
  477.       <Phone> ::= "Phone: " <tel-no-list> <CR>
  478.                 One or more phone numbers
  479.  
  480.       <Fax> ::= "Fax: " <tel-no-list> <CR>
  481.                 One or more FAX numbers
  482.  
  483.       <Mail> ::= "Mail: " 'postal address information' <CR>
  484.                 The items of the postal address are separated by ' /'
  485.                 wherever the next item goes onto the next line for a
  486.                 printed address label.  If the document is for an
  487.                 international community, the address should include the
  488.                 person's country.
  489.                 Example:
  490.                 Mail: SWITCH Head Office / Urs Eppenberger /
  491.                       Limmatquai 138 / CH-8001 Zurich / Switzerland
  492.                 results in the following mailing label:
  493.                 SWITCH Head Office
  494.                 Urs Eppenberger
  495.                 Limmatquai 138
  496.                 CH-8001 Zurich
  497.                 Switzerland
  498.  
  499.       <Update-info> ::= "Update: FORMAT=V3; DATE=" 'yymmdd' \
  500.                             "; START=" 'yymmdd' \
  501.                             ["; END=" 'yymmdd'] <CR>
  502.                 The <Update-info> contains also the format identifier.
  503.  
  504.  
  505.  
  506. Eppenberger                                                     [Page 9]
  507.  
  508. RFC 1465        Routing Coordination for X.400 Services         May 1993
  509.  
  510.  
  511.                 The date of the last update of a document is given in
  512.                 the form 'yymmdd'.
  513.                 A start date must be set.  A document can be published
  514.                 this way before the information in it is valid.  (This
  515.                 is especially useful in absence of automated tools.
  516.                 RELAY-MTA managers get more time to prepare their
  517.                 systems.)
  518.                 An end date is used to set an expiration date for the
  519.                 document.
  520.  
  521.       <P-address> ::= 'String encoded Presentation Address'
  522.                 The format of this string follows RFC1278, A string
  523.                 encoding of Presentation Address and RFC1277, Encoding
  524.                 Network Addresses to support operation over non-OSI
  525.                 layers.  See chapter 5.2 about the usage of macros in a
  526.                 Presentation Address.
  527.  
  528.       <Service-type> ::= <Network-name> "/" \
  529.                             <Network-service> "/" \
  530.                             <Transport-Protocol>
  531.                 The service type consists of a string with three parts
  532.                 concatenated with a "/": Network-name/Network-
  533.                 service/Transport-Protocol.
  534.  
  535.       <Network-name> ::= 'Name of a network'
  536.                 The network-name string identifies a network.  A well
  537.                 known key word should be chosen.  (No '/' character is
  538.                 allowed.)
  539.                 Examples: Public-X.25, Internet, EMPB-X.25, Int-CLNS,
  540.                 WIN, Janet,
  541.  
  542.       <Network-service> ::= 'Name of a network service'
  543.                 Examples: X.25, CONS, CLNS, TCP
  544.  
  545.       <Transport-Protocol> ::= 'Name of a transport protocol'
  546.                 Examples: TP0, TP2, TP4, RFC1006
  547.  
  548.                 Since network and stack information forms one string,
  549.                 it identifies in an easy way a connection possibility
  550.                 between two RELAY-MTAs.  The COMMUNITY document defines
  551.                 the strings to be used in the RELAY-MTA and DOMAIN
  552.                 documents.  Some examples:
  553.                 Internet/TCP/RFC1006
  554.                 Public-X.25/X.25/TP0
  555.                 RARE-IXI/CONS/TP0
  556.                 RARE-CLNS/CLNS/TP4
  557.                 (It is probably important to mention here that this
  558.                 string has nothing to do with the format of a
  559.  
  560.  
  561.  
  562. Eppenberger                                                    [Page 10]
  563.  
  564. RFC 1465        Routing Coordination for X.400 Services         May 1993
  565.  
  566.  
  567.                 presentation address as defined by Steve Hardcastle-
  568.                 Kille in RFC1278.  The problem of networks using the
  569.                 same address structure (X.121 DTEs, 4 Byte Internet
  570.                 addresses) but not being connected is not addressed in
  571.                 RFC1278 but solved by using the proposed service
  572.                 identifier above in addition to the presentation
  573.                 address.  As long as there are network islands, there
  574.                 is no other way than the addition of an 'island'-
  575.                 identifier.
  576.  
  577.       <MHS-subtree> ::= ["O=" 'Organization-name' "; "] \
  578.                             ["OU1="'OrganizationalUnit'"; "\
  579.                             ["OU2=" 'OrganizationalUnit' "; " \
  580.                             ["OU3=" 'OrganizationalUnit' "; " \
  581.                             ["OU4=" 'OrganizationalUnit' "; "]]]] \
  582.                             ["P=" 'PRMDname' "; "] \
  583.                             "A=" 'ADMDname' "; " \
  584.                             "C=" <Country-Code> ";"
  585.  
  586.       <Operation> ::= "Reachable: "  {<time> "-" <time> "; "} \
  587.                             <Time-zone> <CR>
  588.  
  589.       <time> ::= 'hh:mm'
  590.  
  591.       <Time-zone> ::= ("UTC+" | "UTC-") 'hhmm'
  592.                 The operation information is needed to know the time
  593.                 someone is reachable.  This information is important
  594.                 for communities spanning several time zones.
  595.                 'hhmm' is a four digit value, the first two digits
  596.                 indicate hours, the second two digits indicate minutes.
  597.                 Use "UTC+" for time zones east of Greenwich.  A simple
  598.                 formula helps to calculate the current time at the
  599.                 remote place:
  600.                 local-time - local-displacement + remote-displacement =
  601.                 remote-time
  602.                 18:00 - (UTC + 0100) + (UTC - 0800) = 09:00
  603.                 The <Time-zone> entry may be followed by a comment line
  604.                 indicating when Daylight Saving Time is in effect.
  605.                 This is especially reasonable for MHS communities
  606.                 spanning continents on the northern and southern
  607.                 hemisphere.
  608.  
  609. 5.2 The COMMUNITY document
  610.  
  611.       <COMMUNITY-document> ::= <Community-Identifier> \
  612.                             <Update-info> \
  613.                             <COMMUNITY-document-body>
  614.                 The first line of the COMMUNITY document specifies the
  615.  
  616.  
  617.  
  618. Eppenberger                                                    [Page 11]
  619.  
  620. RFC 1465        Routing Coordination for X.400 Services         May 1993
  621.  
  622.  
  623.                 <Community-Identifier> to be used in the header of all
  624.                 other documents belonging to the same community.  It is
  625.                 recommended to add a few comment lines to describe the
  626.                 members of this MHS community.
  627.  
  628.       <COMMUNITY-document-body> ::= <Coordination> \
  629.                             [{<Macro-definition>}] \
  630.                             {<Connections>}
  631.  
  632.       <Coordination> ::= <EMail> <Phone> <FAX> \
  633.                             <Mail> <Operation> <File-server>
  634.                 Set of contact information for the coordination point
  635.  
  636.       <File-server> ::= <email-server> [{<FTP-server>}] \
  637.                             [{<FTAM-server>}]
  638.                 All documents must be available at least to the
  639.                 managers of the MHS domains and the RELAY-MTAs through
  640.                 an email server.  If FTAM and FTP are also  available,
  641.                 the generation of automated update tools is much
  642.                 easier.
  643.                 It is suggested to have a single server.  If there is
  644.                 only one, knowing a single X.400 OR address will allow
  645.                 you to reach the server.  However for FTP and FTAM more
  646.                 system addresses may be possible depending on the
  647.                 number of available network connections (or service
  648.                 types as they are called in this document).
  649.  
  650.       <email-server> ::= "Mail-server: "<X.400 address> <CR>
  651.                 The email address of the file server.
  652.  
  653.       <FTP-server> ::= "FTP-server: " 'domain name' "; " \
  654.                             'account-name' ["; " 'password'] <CR>
  655.                 In addition to the domain name of the server, an
  656.                 account name and a password is given.  In most cases
  657.                 this will probably be something like "anonymous" and
  658.                 "guest".
  659.                 Some servers request the RFC822 address of the user.
  660.                 This is documented by using the string 'user@domain' as
  661.                 password entry.  The meaning is not to use
  662.                 'user@domain' literally as password while accessing the
  663.                 server (even if this would generally work too since the
  664.                 software often just checks the presence of an @ sign,)
  665.                 but to use ones own RFC822 email address.
  666.  
  667.       <FTAM-server> ::= "FTAM-server: " <P-address> "; "\
  668.                             'account-name' ["; " 'password'] \
  669.                             ["; X.500 " <DirectoryName>] <CR>
  670.                 The account name is often case sensitive.  Some FTAM
  671.  
  672.  
  673.  
  674. Eppenberger                                                    [Page 12]
  675.  
  676. RFC 1465        Routing Coordination for X.400 Services         May 1993
  677.  
  678.  
  679.                 servers offer anonymous access with the account-name
  680.                 ANON.  Documenting an FTAM server with a Distinguished
  681.                 Name is only allowed if the server is registered in the
  682.                 directory.
  683.  
  684.       <Macro-definition> ::= "Macro: " 'Macro name' " " \
  685.                             'Macro value' <CR>
  686.                 Presentation addresses without the usage of macros are
  687.                 generally unreadable.  RFC1278 suggests a few macros.
  688.                 All macros which are allowed in a community must be
  689.                 defined in the COMMUNITY document.  It is recommended
  690.                 to use the proposed macros in RFC1278 and add new ones
  691.                 if necessary:
  692.                 Macro: Int-X25(80)        TELEX+00728722+X.25(80)+01+
  693.                 Macro: Janet-X25(80)      TELEX+00728722+X.25(80)+02+
  694.                 Macro: Internet-RFC-1006  TELEX+00728722+RFC-1006+03+
  695.  
  696.       <Connections> ::= {<mandatory-service>} \
  697.                             {[<optional-service>]}
  698.                 Note that at least one mandatory service type is
  699.                 needed.
  700.  
  701.       <mandatory-service> ::= "Mandatory-Service: " \
  702.                             <Service-type> <CR>
  703.  
  704.       <optional-service> ::= "Optional-Service: " \
  705.                             <Service-type> <CR>
  706.  
  707. 5.3 The RELAY-MTA document
  708.  
  709.       <RELAY-MTA-document> ::= <Community-Identifier> \
  710.                             <Update-info> \
  711.                             <RELAY-MTA-document-Identifier> \
  712.                             <RELAY-MTA-document-body>
  713.                 A RELAY-MTA document contains the full description of a
  714.                 single RELAY-MTA.  Only one community is allowed.
  715.                 Since some of the information is community dependent,
  716.                 it would not be easily possible to have a single
  717.                 RELAY-MTA document used in different communities.
  718.  
  719.       <RELAY-MTA-document-Identifier> ::= \
  720.                             "RELAY-MTA: " <UniqueRELAY-MTAkey> <CR>
  721.  
  722.       <RELAY-MTA-document-body> ::= <Status> <connection-info> \
  723.                             <contact-info>
  724.  
  725.       <Status> ::= "Status: " ("primary" | "secondary") <CR>
  726.                 This defines if the RELAY-MTA has 'primary' or
  727.  
  728.  
  729.  
  730. Eppenberger                                                    [Page 13]
  731.  
  732. RFC 1465        Routing Coordination for X.400 Services         May 1993
  733.  
  734.  
  735.                 'secondary' status.  See section 4.3 and 6 for more
  736.                 information.
  737.  
  738.       <connection-info> ::= <password> <RTS> \
  739.                             {<called-connection><calling-connection>}\
  740.                             [<system>] \
  741.                             [<local-domain>] \
  742.                             [<echo-server>]
  743.                 More than one set of connection information may be
  744.                 present for RELAY-MTAs supporting several networks and
  745.                 protocol stacks.
  746.  
  747.       <password> ::= "Password: " \
  748.                             ("secret" | "none" | \
  749.                             "value=\"" 'password' "\"") <CR>
  750.                 If the keyword none is present, then no password is
  751.                 sent with the MTAname when this MTA initiates an RTS
  752.                 connection or responds to an incoming connection.
  753.                 Password: none
  754.  
  755.                 If the keyword secret is present, then the connection
  756.                 needs a password which is not made publicly available.
  757.                 (For example, a community might keep a list of the
  758.                 passwords at the central coordination point.  The list
  759.                 would then be faxed to the RELAY-MTA managers.)
  760.                 Password: secret
  761.  
  762.                 A password must be documented using the
  763.                 value="password" notation.  The double quotes around
  764.                 the password are needed, consider the case of a single
  765.                 blank as a password.
  766.                 Password: value=" "
  767.                 Password: value="nume-n-ine"
  768.  
  769.       <RTS> ::= <dialog-mode> \
  770.                             [<checkpoint-size> <window-size>]
  771.  
  772.       <dialog-mode> ::= "RTS-dialog-mode: " \
  773.                             ("TWA" | "MONOLOGUE") <CR>
  774.  
  775.       <checkpoint-size> ::= "RTS-checkpoint-size: " \
  776.                             'checkpoint size' <CR>
  777.  
  778.       <window-size> ::= "RTS-window-size: " \
  779.                             'window size' <CR>
  780.  
  781.       <called-connection> ::= "Called-address: " \
  782.                             <Service-type> "; " \
  783.  
  784.  
  785.  
  786. Eppenberger                                                    [Page 14]
  787.  
  788. RFC 1465        Routing Coordination for X.400 Services         May 1993
  789.  
  790.  
  791.                             <P-address> "; " <MTS> \
  792.                             ["; " <Service-priority>] <CR>
  793.  
  794.       <MTS> ::= "MTS-T" | "MTS-TP" | "MTS-TP-84"
  795.                 MTS-T:     mts-transfer
  796.                 MTS-TP:    mts-transfer-protocol
  797.                 MTS-TP-84: mts-transfer-protocol-1984
  798.                 See ISO 10021-6, Section 3, chapter 11.1 for more
  799.                 details on this matter.  X.400(84) systems only support
  800.                 mts-transfer-protocol-1984.
  801.  
  802.       <Service-priority> ::= 'Integer 0..99'
  803.                 The lowest Integer corresponds to the highest priority
  804.                 as in DNS.  It is possible to set different priorities
  805.                 for each service type.  This may be chosen, for
  806.                 example, to distribute the load amongst different
  807.                 networks according to their available bandwidth.
  808.  
  809.       <calling-connection> ::= "Calling-address: " \
  810.                             <Service-type> "; " \
  811.                             <P-address> <CR>
  812.                 Since called and calling network addresses may differ
  813.                 in certain configurations and some X.400 systems do
  814.                 validation on calling network addresses, it is
  815.                 important to have this information in the RELAY-MTA
  816.                 document.  (Note: a calling X.121 address might change
  817.                 if the X.25 switch is reconfigured.  This will stop a
  818.                 RELAY-MTA from connecting to other RELAY-MTAs using
  819.                 address validation without having changed anything at
  820.                 the higher layers!)
  821.  
  822.       <system> ::= "System: HW=" 'computer type' "; " \
  823.                             "OS=" 'operating system' "; " \
  824.                             "SW=" 'MHS  software' <CR>
  825.                 It is optional to provide HW/SW information.
  826.                 Experience, however, has shown that a number of
  827.                 communication problems were more easily identified and
  828.                 solved with this information present and up-to-date.
  829.  
  830.       <local-domain> ::= "LocalDomain: " <MHS-subtree> <CR>
  831.                 This is a useful but optional extension to the
  832.                 documentation.
  833.                 The <MHS-subtree> is local to the RELAY-MTA.  The <MHS-
  834.                 subtree> attributes might be used together with
  835.                 S=nosuchuser; to do connectivity and availability
  836.                 tests.
  837.  
  838.  
  839.  
  840.  
  841.  
  842. Eppenberger                                                    [Page 15]
  843.  
  844. RFC 1465        Routing Coordination for X.400 Services         May 1993
  845.  
  846.  
  847.       <echo-server> ::= "EchoServer: " <X.400 address> <CR>
  848.                 Some of the RELAY-MTAs might offer an echo server
  849.                 functionality.  It does make sense to document this in
  850.                 the RELAY-MTA document for test purpose.  This field is
  851.                 optional.
  852.  
  853.       <contact-info> ::= {"Administrator: " <UniquePersonKey> <CR>}
  854.                 The contact details for the RELAY-MTA administrator can
  855.                 be found in the appropriate PERSON document.  It is
  856.                 possible to document a whole team using a distribution
  857.                 list if this is desired.  It is generally better to
  858.                 document one or more 'real' persons.
  859.  
  860. 5.4 The DOMAIN document
  861.  
  862.       <DOMAIN-document> ::= <Community-Identifier> \
  863.                             <Update-info> \
  864.                             <DOMAIN-document-body>
  865.  
  866.       <DOMAIN-document-body>::= {<Domain-entry>} <responsible> \
  867.                             {<Relay>}
  868.  
  869.       <Domain-entry> ::= "Domain: " <OR-matching> <MHS-subtree> <CR>
  870.                 Note that it is not allowed to have equal <Domain-
  871.                 entry> lines in different DOMAIN documents belonging to
  872.                 the same MHS community.  A Domain-entry line can only
  873.                 appear in one DOMAIN document.
  874.  
  875.       <OR-matching> ::=  ( "* " | "= " )
  876.                 This qualifier defines how the following OR address
  877.                 attributes should be handled for the routing algorithm.
  878.                 If a '*' is present, a destination address of a message
  879.                 is matched by the "Domain:" entry if at least the OR
  880.                 address attributes in the "Domain:" entry are equal to
  881.                 the destination address.
  882.                 If a "=" is present, a destination address of a message
  883.                 is matched by the "Domain:" entry if there are exactly
  884.                 the same OR attributes in the destination address as in
  885.                 the "Domain:" entry.  (This restriction works for OU4,
  886.                 OU3, OU2, OU1, O, P, A and C only.)
  887.                 Example:
  888.                 a) Domain: * P=switch; A=arcom; C=ch;
  889.                 b) Domain: = P=switch; A=arcom; C=ch;
  890.                 The address S=eppenberger; P=switch; A=arcom; C=ch;
  891.                 matches both cases, a) and b).
  892.                 The address S=eppenberger; O=unibe; P=switch; A=arcom;
  893.                 C=ch; matches only case a).
  894.  
  895.  
  896.  
  897.  
  898. Eppenberger                                                    [Page 16]
  899.  
  900. RFC 1465        Routing Coordination for X.400 Services         May 1993
  901.  
  902.  
  903.       <responsible> ::= {"Administrator: " <UniquePersonKey> <CR>}
  904.                 This is the person responsible for the listed domains.
  905.                 His task is to get the agreement of the relaying
  906.                 RELAY-MTAs and keep the DOMAIN document up-to-date.
  907.                 This person is the only one authorized to make changes
  908.                 to this document.  Note that multiple administrators
  909.                 may be listed.
  910.  
  911.       <Relay> ::=         "Relay: " \
  912.                             ( 'UniqueRELAY-MTAkey' | \
  913.                             "Internet-SMTP" ) "; " \
  914.                             <RELAY-MTA-Priority> <CR>
  915.                 The priority is used to define the sequence in which
  916.                 different RELAY-MTAs may be tried in case of failure.
  917.                 A lower integer corresponds to a higher priority as in
  918.                 DNS.  Priorities 0..49 are used to indicate backup
  919.                 RELAY-MTAs.  Priorities 50..99 are used for RELAY-MTAs
  920.                 not acting as backup but as relay service provider for
  921.                 a network service type not supported by the main
  922.                 RELAY-MTA.
  923.                 The keyword "Internet-SMTP" is a placeholder for an
  924.                 RFC1327 gateway connected to Internet. The RELAY-MTA
  925.                 manager selects a gateway of his choice.
  926.  
  927.       <RELAY-MTA-Priority> ::= <Integer 0..99>
  928.  
  929. 5.5 The PERSON document
  930.  
  931.       <PERSON-document> ::= <Community-Identifier> \
  932.                             <Update-info> \
  933.                             <PERSON-document-identifier> \
  934.                             <PERSON-document-body>
  935.  
  936.       <PERSON-document-identifier> ::= "Key: " <UniquePersonKey> <CR>
  937.  
  938.       <PERSON-document-body>::= <Name> {<EMail>} {<RFC822>} \
  939.                             <Phone> <Fax> <Mail> <Operation>
  940.  
  941.       <Name>  ::= "Name: " 'name of person' <CR>
  942.                 The name of the person is given.  The issue of the
  943.                 character set problem is not addressed in this
  944.                 document.  Especially international communities should
  945.                 restrict themselves to IA5 or ASCII.
  946.  
  947.       <RFC822> ::= "RFC822: " <RFC-822-address> <CR>
  948.                 This is the RFC-822 address of the person.  It is often
  949.                 a big help to know the RFC822 address of someone, for
  950.                 example if the X.400 system is not reachable.  This is
  951.  
  952.  
  953.  
  954. Eppenberger                                                    [Page 17]
  955.  
  956. RFC 1465        Routing Coordination for X.400 Services         May 1993
  957.  
  958.  
  959.                 also the reason why it is possible to provide multiple
  960.                 OR and RFC822 addresses.  The first one is considered
  961.                 the primary one.
  962.  
  963. 6. Routing rules
  964.  
  965.    All the users within the MHS community have the right to send
  966.    messages to each other.  The general agreement is that the RELAY-MTA
  967.    infrastructure is used according to the following routing rules.
  968.    More direct connections based on bilateral agreements are fully
  969.    accepted.
  970.  
  971.    A primary or secondary RELAY-MTA must allow incoming connections from
  972.    all other primary and secondary RELAY-MTAs with a common stack.
  973.    Primary RELAY-MTAs must be able to connect to all other primary
  974.    RELAY-MTAs which share a common stack.  A secondary RELAY-MTA must
  975.    connect to at least one primary RELAY-MTA.
  976.  
  977.    A message arriving at a RELAY-MTA must either be sent to the next
  978.    RELAY-MTA based on the DOMAIN documents of the MHS community or it is
  979.    sent to an MTA closer to the destination based on local routing
  980.    decisions.  The following algorithm must be used when forwarding a
  981.    message to the next RELAY-MTA:
  982.  
  983.       1) Select the relevant DOMAIN document by searching for a match of
  984.       the Recipient address in the message with the entries in the
  985.       document.
  986.  
  987.       If your own RELAY-MTA appears in this list, this indicates one of
  988.       the following:
  989.  
  990.       - You offered relay services for another RELAY-MTA with higher
  991.         priority.  Continue with step 2 to decide on the next RELAY-MTA.
  992.  
  993.       - Your RELAY-MTA is the final destination according the DOMAIN
  994.         document of your community.  You need to forward the message to
  995.         the final destination according local routing information.
  996.  
  997.       2) From the list of RELAY-MTAs select those that have at least one
  998.       common network service type with your own RELAY-MTA.
  999.  
  1000.       3) Now delete all secondary RELAY-MTAs from the list where no
  1001.       direct connection is desired.  For remaining RELAY-MTAs in the
  1002.       list no difference is made anymore between primary and secondary
  1003.       status.
  1004.  
  1005.       4) Select from this reduced set of RELAY-MTAs the one with the
  1006.       highest RELAY-MTA-priority.  If there is more than one RELAY-MTA
  1007.  
  1008.  
  1009.  
  1010. Eppenberger                                                    [Page 18]
  1011.  
  1012. RFC 1465        Routing Coordination for X.400 Services         May 1993
  1013.  
  1014.  
  1015.       having the same priority, then select a RELAY-MTA of your choice.
  1016.       If your own RELAY-MTA appears in that list, then you are not
  1017.       allowed to send to a RELAY-MTA with lower or equal priority.
  1018.  
  1019.       5) If there are no service-priorities set in the corresponding
  1020.       RELAY-MTA document indicating which service type to use, you are
  1021.       free to choose the service type for connecting to the RELAY-MTA.
  1022.       However, if there are specific priorities set then select the
  1023.       service type with the highest priority.
  1024.  
  1025.       6) If the connection fails then try other service types in the
  1026.       sequence of descending priority.
  1027.  
  1028.       7) If no connection works for the selected RELAY-MTA, then check
  1029.       in the list for the one with the same priority, if possible, or
  1030.       else select one with the next lower priority.  If there is another
  1031.       RELAY-MTA with a RELAY-MTA-priority between 0..49, then select it
  1032.       and proceed at step 5.  Without another RELAY-MTA to try the
  1033.       currently selected RELAY-MTA will be retried.
  1034.  
  1035. 6.1 How to use RELAY-MTA-priorities
  1036.  
  1037.    An example helps to explain the usage of RELAY-MTA-priorities.
  1038.    Internet/TCP/RFC1006 and Public-X.25/X.25/TP0 are mandatory service
  1039.    types in the community REMOTEmail.  The MHS domain P=REMOTE; A=ARCOM;
  1040.    C=CH; operates MTA-B, only connected to public X.25.  A second
  1041.    RELAY-MTA which is connected to both, Internet and public X.25 is
  1042.    needed to offer relay services.  A connection using Internet is
  1043.    considered cheap in this example.  Both service types are available
  1044.    at MTA-A.  Since MTA-B is the only RELAY-MTA responsible for relaying
  1045.    messages to P=REMOTE; A=ARCOM; C=CH; to the final destination it must
  1046.    have the highest priority.
  1047.  
  1048.       Community: REMOTEmail
  1049.       Domain: * P=REMOTE; A=ARCOM; C=CH;
  1050.       RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-B; 20
  1051.       RELAY-MTA:  P=MTA-C; A=ARCOM; C=CH;MTAname=MTA-C; 80
  1052.  
  1053.                                        __________________________
  1054.       +-------+    X.25     +-------+ (                          )
  1055.       | MTA-A +-------------+ MTA-B +-( P=REMOTE; A=ARCOM; C=CH; )
  1056.       +-------+             +-------+ (__________________________)
  1057.                \           /
  1058.          TCP/IP \         /X.25
  1059.                  +-------+
  1060.                  | MTA-C |
  1061.                  +-------+
  1062.  
  1063.  
  1064.  
  1065.  
  1066. Eppenberger                                                    [Page 19]
  1067.  
  1068. RFC 1465        Routing Coordination for X.400 Services         May 1993
  1069.  
  1070.  
  1071.    If MTA-A needs to relay a message for P=REMOTE; A=ARCOM; C=CH; then
  1072.    the rules of chapter 6 are evaluated:
  1073.  
  1074.         1. MTA-B and MTA-C are possible destinations
  1075.  
  1076.         2. MTA-B and MTA-C are reachable from MTA-A
  1077.  
  1078.         3. MTA-B is a primary RELAY-MTA (not relevant in this example)
  1079.  
  1080.         4. MTA-B has the highest priority.
  1081.  
  1082.         5. MTA-B doesn't have specific service type lines documented.
  1083.            MTA-A chooses public X.25, since it is the only possibility
  1084.            to connect to MTA-B.
  1085.  
  1086.         6. No other service types are available if the connection
  1087.            fails.
  1088.  
  1089.         7. MTA-C has a priority of 80, it is not a backup RELAY-MTA.
  1090.            MTA-A must spool the message and try to connect directly to
  1091.            MTA-B.
  1092.  
  1093.    The organisation running MTA-A could save money by sending messages
  1094.    for the MHS domain P=REMOTE; A=ARCOM; C=CH; via MTA-C.  Since the
  1095.    connection between MTA-C and the destination MTA-B is also expensive,
  1096.    the organisation running MTA-C would have to pay for external relay
  1097.    traffic.  Setting a lower priority for MTA-C forces the other RELAY-
  1098.    MTAs with public X.25 connectivity to take their share of the cost.
  1099.  
  1100.    Note that forcing other RELAY-MTAs to use a specific stack should be
  1101.    avoided wherever possible by offering RELAY-MTAs with equal priority
  1102.    for all mandatory network services.  This can be an important
  1103.    financial issue for MHS communities spanning several organisations,
  1104.    it is not relevant in general for an MHS community within a single
  1105.    organisation.
  1106.  
  1107. 6.2 How to use RELAY-MTA-priorities for backup RELAY-MTAS
  1108.  
  1109.    Two RELAY-MTAs offer real backup connectivity for the MHS domain
  1110.    P=REMOTE; A=ARCOM; C=CH;.  It is therefore possible to set RELAY-MTA
  1111.    priorities in the range of 0..49 for both RELAY-MTAs.  MTA-B will be
  1112.    the preferred one since it has the higher priority.  If the
  1113.    connection to MTA-B fails, a sending RELAY-MTA may immediately try to
  1114.    connect to MTA-C.
  1115.  
  1116.       Community: REMOTEmail
  1117.       Domain: * P=REMOTE; A=ARCOM; C=CH;
  1118.       RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-B; 10
  1119.  
  1120.  
  1121.  
  1122. Eppenberger                                                    [Page 20]
  1123.  
  1124. RFC 1465        Routing Coordination for X.400 Services         May 1993
  1125.  
  1126.  
  1127.       RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-C; 30
  1128.  
  1129.                                        __________________________
  1130.       +-------+             +-------+ (                          )
  1131.       | MTA-A +-------------+ MTA-B +-( P=REMOTE; A=ARCOM; C=CH; )
  1132.       +-------+             +-------+ (__________________________)
  1133.                \                     /
  1134.                 \           +-------+
  1135.                  -----------+ MTA-C |
  1136.                             +-------+
  1137.  
  1138. 6.3 Load Sharing
  1139.  
  1140.    It is possible to set equal priorities to do some sort of load
  1141.    sharing.  However, most implementations are not able to do random
  1142.    selection of RELAY-MTAs with equal priorities but have a fixed
  1143.    configuration.  If load sharing is really needed then it is suggested
  1144.    to split up the MHS domain into several MHS subtrees and document
  1145.    them separately with a set of RELAY-MTAs with different priorities.
  1146.  
  1147.    An example is provided for illustration of the first possibility with
  1148.    equal RELAY-MTA-priorities:
  1149.  
  1150.       Community: REMOTEmail
  1151.       Domain: * P=REMOTE; A=ARCOM; C=CH;
  1152.       RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-B; 10
  1153.       RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-C; 10
  1154.           _               __________________________
  1155.            )  +-------+  (                          )
  1156.            )--+ MTA-B +--( P=REMOTE; A=ARCOM; C=CH; )
  1157.            )  +-------+  (__________________________)
  1158.            )            /
  1159.            )  +-------+/
  1160.            )--+ MTA-C |
  1161.           _)  +-------+
  1162.  
  1163.       And here is an example where the MHS domain
  1164.     C=CH;ADMD=ARCOM;PRMD=REMOTE;O=Big-Org is documented with its own
  1165.     DOMAIN document: Note that in this example both RELAY-MTAs serve
  1166.     as backup RELAY-MTAs.
  1167.  
  1168.       Community: REMOTEmail
  1169.       Domain: * P=REMOTE; A=ARCOM; C=CH;
  1170.       RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-B; 10
  1171.       RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-C; 30
  1172.  
  1173.       Community: REMOTEmail
  1174.       Domain: * O=Big-Org; P=REMOTE; A=ARCOM; C=CH;
  1175.  
  1176.  
  1177.  
  1178. Eppenberger                                                    [Page 21]
  1179.  
  1180. RFC 1465        Routing Coordination for X.400 Services         May 1993
  1181.  
  1182.  
  1183.       RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-C; 10
  1184.       RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-B; 30
  1185.           _               __________________________
  1186.            )  +-------+  (                          )
  1187.            )--+ MTA-B +--( P=REMOTE; A=ARCOM; C=CH; )
  1188.            )  +-------+  (__________________________)
  1189.            )           \/
  1190.            )           /\ _____________________________________
  1191.            )  +-------+  (                                     )
  1192.            )--+ MTA-C |--( O=Big-Org; P=REMOTE; A=ARCOM; C=CH; )
  1193.           _)  +-------+  (_____________________________________)
  1194.  
  1195. 7. Open issues
  1196.  
  1197.    Currently there are about 35 RELAY-MTAs within the COSINE-MHS
  1198.    service.  A rough guess is that a network with about 60 RELAY-MTAs is
  1199.    still manageable provided there are automated tools for MTA
  1200.    configuration.  If there are more MTAs applying for RELAY-MTA status
  1201.    in an MHS community, then either an X.500 based solution should be
  1202.    ready or a core set of about 30 well operated super-RELAY-MTAs should
  1203.    form a backbone, documented within a specific MHS community.
  1204.  
  1205.    Since the RELAY-MTA document contains information about the supported
  1206.    X.400 version (84 or 88), it is possible for an X.400(88) system to
  1207.    select with higher priority an (88)RELAY-MTA.  The rules in chapter 6
  1208.    could be modified to select X.400(88) systems first if the sending
  1209.    RELAY-MTA is an (88) system itself.  The issue of how to establish an
  1210.    X.400(88) RELAY-MTA infrastructure within an MHS community is for
  1211.    further study.
  1212.  
  1213.  
  1214.  
  1215.  
  1216.  
  1217.  
  1218.  
  1219.  
  1220.  
  1221.  
  1222.  
  1223.  
  1224.  
  1225.  
  1226.  
  1227.  
  1228.  
  1229.  
  1230.  
  1231.  
  1232.  
  1233.  
  1234. Eppenberger                                                    [Page 22]
  1235.  
  1236. RFC 1465        Routing Coordination for X.400 Services         May 1993
  1237.  
  1238.  
  1239. Appendix A:  Document examples for the COSINE-MHS community
  1240.  
  1241.    Instead of creating artificial documents to show an example document
  1242.    set, this appendix contains extracts from a real operational X.400
  1243.    service.  The research and development community in Europe has used
  1244.    X.400 for several years.  This proposal was initially written to
  1245.    address this community only and solve the urgent routing and
  1246.    coordination problems.  Contributions from different experts have
  1247.    made it more flexible and therefore hopefully useful for other MHS
  1248.    communities.
  1249.  
  1250. Appendix A1:  The COMMUNITY document
  1251.  
  1252.   Community: COSINE-MHS
  1253.   # The COSINE-MHS service is a MHS community formed by the European
  1254.   # academic and research networks with additional contacts in all
  1255.   # other continents.
  1256.   #
  1257.   # The coordination is done by the COSINE-MHS project team.
  1258.   #
  1259.   Update: FORMAT=V3; DATE=921218; START=930201
  1260.   #
  1261.   Address: S=Project-Team; O=SWITCH; P=SWITCH; A=ARCOM; C=CH;
  1262.   #
  1263.   Phone: +41 1-262-31-43
  1264.   Fax:   +41 1-261-81-88
  1265.   #
  1266.   Mail:  SWITCH Head Office /
  1267.          MHS Coordination Service /
  1268.          Limmatquai 138 /
  1269.          CH-8001 Zurich /
  1270.          Switzerland
  1271.   #
  1272.   Reachable: 09:00-12:00; 14:00-17:30; UTC+1
  1273.   #
  1274.   Mail-server: S=mhs-server; O=switch; OU1=nic;
  1275.                P=SWITCH; A=ARCOM; C=CH;
  1276.   FTP-server:  nic.switch.ch; cosine; user@domain
  1277.   #
  1278.   Macro: Int-X25(80)        TELEX+00728722+X.25(80)+01+
  1279.   Macro: Internet-RFC-1006  TELEX+00728722+RFC-1006+03+
  1280.   Macro: IXI                TELEX+00728722+X.25(80)+06+
  1281.   #
  1282.   Mandatory-Service: Public-X.25/X.25/TP0
  1283.   # The public X.25 network.  X.25 is supported in most X.400
  1284.   # applications and mandatory in X.400 anyhow.
  1285.   #
  1286.   Mandatory-Service: Internet/TCP/RFC1006
  1287.  
  1288.  
  1289.  
  1290. Eppenberger                                                    [Page 23]
  1291.  
  1292. RFC 1465        Routing Coordination for X.400 Services         May 1993
  1293.  
  1294.  
  1295.   # The Internet, standing for the global TCP/IP network of the
  1296.   # research and development community
  1297.   # RFC1006 is considered a solution to ease migration to OSI. It will
  1298.   # be replaced by TP4/CLNS as soon as a reliable service is
  1299.   # available.
  1300.   #
  1301.   Optional-Service: Int-CLNS/CLNS/TP4
  1302.   # The RARE Connectionless pilot service.  Current participants are
  1303.   # NORDUnet, SURFnet, CERN, NSFnet and SWITCH.
  1304.   #
  1305.   Optional-Service: EMPB-X.25/X.25/TP0
  1306.   # The International X.25 Infrastructure covering most countries in
  1307.   # Europe.  The absence of volume tariffs make it a preferred choice.
  1308.  
  1309. Appendix A2:  Example of a RELAY-MTA document
  1310.  
  1311.   Community: COSINE-MHS
  1312.   #
  1313.   Update: FORMAT=V3; DATE=921218; START=930201
  1314.   #
  1315.   RELAY-MTA: P=SWITCH; A=ARCOM; C=CH; MTAname=chx400.switch.ch
  1316.   #
  1317.   Status: primary
  1318.   #
  1319.   Password: none
  1320.   RTS-dialog-mode: MONOLOGUE
  1321.   #
  1322.   Called-address:  Public-X.25/X.25/TP0;
  1323.                    "591"/Int-X25(80)=22847971014520+CUDF+03010100;
  1324.                    MTS-TP-84
  1325.   Calling-address: Public-X.25/X.25/TP0;
  1326.                    Int-X25(80)=22847971014520;
  1327.   #
  1328.   Called-address:  Internet/TCP/RFC1006;
  1329.                    "591"/Internet-RFC-1006=chx400.switch.ch;
  1330.                    MTS-TP-84
  1331.   Calling-address: Internet/TCP/RFC1006;
  1332.                    Internet-RFC-1006=chx400.switch.ch
  1333.   #
  1334.   Called-address:  EMPB-X.25/X.25/TP0;
  1335.                    "591"/IXI=20432840100520+CUDF+03010100;
  1336.                    MTS-TP-84
  1337.   Calling-address: EMPB-X.25/X.25/TP0;
  1338.                    IXI=20432840100520;
  1339.   #
  1340.   Calling-address: Int-CLNS/CLNS/TP4;
  1341.                    "591"/NS+39756F11111111010000014560AA00040005E100;
  1342.                    MTS-TP-84
  1343.  
  1344.  
  1345.  
  1346. Eppenberger                                                    [Page 24]
  1347.  
  1348. RFC 1465        Routing Coordination for X.400 Services         May 1993
  1349.  
  1350.  
  1351.   Called-address:  DCC+756+x11111111010000014560AA00040005E100
  1352.   #
  1353.   # For X.400(88) over CLNS
  1354.   #
  1355.   Calling-address: Int-CLNS/CLNS/TP4;
  1356.                    "592"/NS+39756F11111111010000014560AA00040005E100;
  1357.                    MTS-T
  1358.   Called-address:  DCC+756+x11111111010000014560AA00040005E100
  1359.   #
  1360.   System: HW=SUN 4/690MP; OS=SunOS 4.1.1; SW=PP-6.0
  1361.   #
  1362.   LocalDomain: O=switch; OU1=chx400; P=switch; A=arcom; C=ch;
  1363.   #
  1364.   EchoServer:  S=echo; O=switch; OU1=chx400; P=switch; A=arcom; C=ch;
  1365.   #
  1366.   Administrator: CN=Felix Kugler, O=SWITCH, C=CH
  1367.   Administrator: CN=Christoph Graf, O=SWITCH, C=CH
  1368.  
  1369. Appendix A3:  Example of a DOMAIN document
  1370.  
  1371.   Community: COSINE-MHS
  1372.   #
  1373.   Update: FORMAT=V3; DATE=921218; START=930201
  1374.   ##
  1375.   Domain: *     P=SWITCH; A=ARCOM; C=CH;
  1376.   Domain: *     P=SANDOZ; A=ARCOM; C=CH;
  1377.   Domain: *        P=ABB; A=ARCOM; C=CH;
  1378.   Domain: *        P=UBS; A=ARCOM; C=CH;
  1379.   Domain: *      P=ISREC; A=ARCOM; C=CH;
  1380.   Domain: *    P=ALCATEL; A=ARCOM; C=CH;
  1381.   Domain: *        P=ITU; A=ARCOM; C=CH;
  1382.   Domain: * P=OSILABMAIL; A=ARCOM; C=CH;
  1383.   Domain: *        P=WHO; A=ARCOM; C=CH;
  1384.   Domain: *       P=CERN; A=ARCOM; C=CH;
  1385.   Domain: *   P=CERBERUS; A=ARCOM; C=CH;
  1386.   #
  1387.   Administrator: CN=Christoph Graf, O=SWITCH, C=CH
  1388.   Administrator: S=postmaster; O=SWITCH; P=SWITCH; A=ARCOM; C=CH;
  1389.   #
  1390.   RELAY-MTA: P=SWITCH; A=ARCOM; C=CH; MTAname=chx400.switch.ch; 0
  1391.   #
  1392.   RELAY-MTA: P=SWITCH; A=ARCOM; C=CH; MTAname=vms.switch; 10
  1393.  
  1394. Appendix A4:  Example of a PERSON document
  1395.  
  1396.   Community: COSINE-MHS
  1397.   #
  1398.   Update: FORMAT=V3; DATE=921218; START=930201
  1399.  
  1400.  
  1401.  
  1402. Eppenberger                                                    [Page 25]
  1403.  
  1404. RFC 1465        Routing Coordination for X.400 Services         May 1993
  1405.  
  1406.  
  1407.   #
  1408.   Key: CN=Christoph Graf, O=SWITCH, C=CH
  1409.   #
  1410.   Name:    Christoph Graf
  1411.   #
  1412.   Address: S=Graf; O=SWITCH; P=SWITCH; A=ARCOM; C=CH;
  1413.   RFC822:  Graf@switch.ch
  1414.   #
  1415.   Phone:   +41 1 2565454
  1416.   Fax:     +41 1 2618133
  1417.   #
  1418.   Mail:    SWITCH Head Office /
  1419.            Christoph Graf /
  1420.            Limmatquai 138 /
  1421.            CH-8001 Zurich /
  1422.            Switzerland
  1423.   #
  1424.   Reachable: 09:00-12:00; 14:00-17:30; UTC+0100
  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. Eppenberger                                                    [Page 26]
  1459.  
  1460. RFC 1465        Routing Coordination for X.400 Services         May 1993
  1461.  
  1462.  
  1463. Appendix B:  BNF Definitions
  1464.  
  1465.       <called-connection> ::= "Called-address: " \
  1466.                             <Service-type> "; " \
  1467.                             <P-address> "; " <MTS> \
  1468.                             ["; " <Service-priority>] <CR>
  1469.  
  1470.       <calling-connection> ::= "Calling-address: " \
  1471.                             <Service-type> "; " \
  1472.                             <P-address> <CR>
  1473.  
  1474.       <checkpoint-size> ::= "RTS-checkpoint-size: " \
  1475.                             'checkpoint size' <CR>
  1476.  
  1477.       <COMMUNITY-document> ::= <Community-Identifier> \
  1478.                             <Update-info> \
  1479.                             <COMMUNITY-document-body>
  1480.  
  1481.       <COMMUNITY-document-body> ::= <Coordination> \
  1482.                             [{<Macro-definition>}] \
  1483.                             {<Connections>}
  1484.  
  1485.       <Community-Identifier> ::= "Community: " \
  1486.                             ('community name' | <DirectoryName>) <CR>
  1487.  
  1488.       <connection-info> ::= <password> <RTS> \
  1489.                             {<called-connection><calling-connection>}\
  1490.                             [<system>] \
  1491.                             [<local-domain>] \
  1492.                             [<echo-server>]
  1493.  
  1494.       <Connections> ::= {<mandatory-service>} \
  1495.                             {[<optional-service>]}
  1496.  
  1497.       <contact-info> ::= {"Administrator: " <UniquePersonKey> <CR>}
  1498.  
  1499.       <Coordination> ::= <EMail> <Phone> <FAX> \
  1500.                             <Mail> <Operation> <File-server>
  1501.  
  1502.       <Country-Code> ::= 'Two Character Country Code ISO-3166'
  1503.  
  1504.       <dialog-mode> ::= "RTS-dialog-mode: " \
  1505.                             ("TWA" | "MONOLOGUE") <CR>
  1506.  
  1507.       <DirectoryName> ::= 'Distinguished Name'
  1508.  
  1509.       <DOMAIN-document> ::= <Community-Identifier> \
  1510.                             <Update-info> \
  1511.  
  1512.  
  1513.  
  1514. Eppenberger                                                    [Page 27]
  1515.  
  1516. RFC 1465        Routing Coordination for X.400 Services         May 1993
  1517.  
  1518.  
  1519.                             <DOMAIN-document-body>
  1520.  
  1521.       <DOMAIN-document-body>::= {<Domain-entry>} <responsible> \
  1522.                             {<Relay>}
  1523.  
  1524.       <Domain-entry> ::= "Domain: " <OR-matching> <MHS-subtree> <CR>
  1525.  
  1526.       <echo-server> ::= "EchoServer: " <X.400 address> <CR>
  1527.  
  1528.       <EMail> ::= "Address: " <X.400 address> <CR>
  1529.  
  1530.       <email-server> ::= "Mail-server: "<X.400 address> <CR>
  1531.  
  1532.       <extension> ::= 'local extension'
  1533.  
  1534.       <Fax> ::= "Fax: " <tel-no-list> <CR>
  1535.  
  1536.       <File-server> ::= <email-server> [{<FTP-server>}] \
  1537.                             [{<FTAM-server>]}
  1538.  
  1539.       <FTAM-server> ::= "FTAM-server: " <P-address> "; "\
  1540.                             'account-name' ["; " 'password'] \
  1541.                             ["; X.500 " <DirectoryName>] <CR>
  1542.  
  1543.       <FTP-server> ::= "FTP-server: " 'domain name' "; " \
  1544.                             'account-name' ["; " 'password'] <CR>
  1545.  
  1546.       <int-pref> ::= 'international prefix'
  1547.  
  1548.       <local-domain> ::= "LocalDomain: " <MHS-subtree> <CR>
  1549.  
  1550.       <Macro-definition> ::= "Macro: " 'Macro name' " " \
  1551.                             'Macro value' <CR>
  1552.  
  1553.       <Mail> ::= "Mail: " 'postal address information' <CR>
  1554.  
  1555.       <mandatory-service> ::= "Mandatory-Service: " \
  1556.                             <Service-type> <CR>
  1557.  
  1558.       <MHS-subtree> ::= ["O=" 'Organization-name' "; "] \
  1559.                             ["OU1="'OrganizationalUnit'"; "\
  1560.                             ["OU2=" 'OrganizationalUnit' "; " \
  1561.                             ["OU3=" 'OrganizationalUnit' "; " \
  1562.                             ["OU4=" 'OrganizationalUnit' "; "]]]] \
  1563.                             ["P=" 'PRMDname' "; "] \
  1564.                             "A=" 'ADMDname' "; " \
  1565.                             "C=" <Country-Code> ";"
  1566.  
  1567.  
  1568.  
  1569.  
  1570. Eppenberger                                                    [Page 28]
  1571.  
  1572. RFC 1465        Routing Coordination for X.400 Services         May 1993
  1573.  
  1574.  
  1575.       <MTS> ::= "MTS-T" | "MTS-TP" | "MTS-TP-84"
  1576.  
  1577.       <Name>  ::= "Name: " 'name of person' <CR>
  1578.  
  1579.       <national number> ::= 'national telephone number'
  1580.  
  1581.       <Network-name> ::= 'Name of a network'
  1582.  
  1583.       <Network-service> ::= 'Name of a network service'
  1584.  
  1585.       <Operation> ::= "Reachable: "  {<time> "-" <time> "; "} \
  1586.                             <Time-zone> <CR>
  1587.  
  1588.       <optional-service> ::= "Optional-Service: " \
  1589.                             <Service-type> <CR>
  1590.  
  1591.       <OR-matching> ::=  ( "* " | "= " )
  1592.  
  1593.       <P-address> ::= 'String encoded Presentation Address'
  1594.  
  1595.       <password> ::= "Password: " \
  1596.                             ("secret" | "none" | \
  1597.                             "value=\"" 'password' "\"") <CR>
  1598.  
  1599.       <PERSON-document> ::= <Community-Identifier> \
  1600.                             <Update-info> \
  1601.                             <PERSON-document-identifier> \
  1602.                             <PERSON-document-body>
  1603.  
  1604.       <PERSON-document-identifier> ::= "Key: " <UniquePersonKey> <CR>
  1605.  
  1606.       <PERSON-document-body>::= <Name> {<EMail>} {<RFC822>} \
  1607.  
  1608.       <Phone> ::= "Phone: " <tel-no-list> <CR>
  1609.  
  1610.       <Relay> ::=         "Relay: " \
  1611.                             'UniqueRELAY-MTAkey' "; " \
  1612.                             <RELAY-MTA-Priority> <CR>
  1613.  
  1614.       <RELAY-MTA-document> ::= <Community-Identifier> \
  1615.                             <Update-info> \
  1616.                             <RELAY-MTA-document-Identifier> \
  1617.                             <RELAY-MTA-document-body>
  1618.  
  1619.       <RELAY-MTA-document-body> ::= <Status> <connection-info> \
  1620.                             <contact-info>
  1621.  
  1622.       <RELAY-MTA-document-Identifier> ::= \
  1623.  
  1624.  
  1625.  
  1626. Eppenberger                                                    [Page 29]
  1627.  
  1628. RFC 1465        Routing Coordination for X.400 Services         May 1993
  1629.  
  1630.  
  1631.                             "RELAY-MTA: " <UniqueRELAY-MTAkey> <CR>
  1632.  
  1633.       <RELAY-MTA-Priority> ::= <Integer 0..99>
  1634.  
  1635.       <responsible> ::= {"Administrator: " <UniquePersonKey> <CR>}
  1636.  
  1637.       <RFC822> ::= "RFC822: " <RFC-822-address> <CR>
  1638.  
  1639.       <RTS> ::= <dialog-mode> \
  1640.                             [<checkpoint-size> <window-size>]
  1641.  
  1642.       <Service-priority> ::= 'Integer 0..99'
  1643.  
  1644.       <Service-type> ::= <Network-name> "/" \
  1645.                             <Network-service> "/" \
  1646.                             <Transport-Protocol>
  1647.  
  1648.       <Status> ::= "Status: " ("primary" | "secondary") <CR>
  1649.  
  1650.       <system> ::= "System: HW=" 'computer type' "; " \
  1651.                             "OS=" 'operating system' "; " \
  1652.                             "SW=" 'MHS  software' <CR>
  1653.  
  1654.       <tel-no-list> ::= <tel-number> [{"; " <tel-number>}]
  1655.  
  1656.       <tel-number> ::=  {"+" <int-pref> " " <national number> \
  1657.                             [" x" <extension>]}
  1658.  
  1659.       <time> ::= 'hh:mm'
  1660.  
  1661.       <Time-zone> ::= ("UTC+" | "UTC-") 'hhmm'
  1662.  
  1663.       <Transport-Protocol> ::= 'Name of a transport protocol'
  1664.  
  1665.       <UniquePersonKey> ::= (<X.400 address> | <DirectoryName> )
  1666.  
  1667.       <UniqueRELAY-MTAkey> ::= (([ "P=" 'PRMDname' "; " ] \
  1668.                             ["A=" 'ADMDname' "; " ] \
  1669.                             "C=" <Country-Code> "; " \
  1670.                             "MTAname=" 'MTAname')
  1671.                             | <DirectoryName> )
  1672.  
  1673.       <Update-info> ::= "Update: FORMAT=V3; DATE=" 'yymmdd' \
  1674.                             "; START=" 'yymmdd' \
  1675.                             ["; END=" 'yymmdd'] <CR>
  1676.  
  1677.       <window-size> ::= "RTS-window-size: " \
  1678.                             'window size' <CR>
  1679.  
  1680.  
  1681.  
  1682. Eppenberger                                                    [Page 30]
  1683.  
  1684. RFC 1465        Routing Coordination for X.400 Services         May 1993
  1685.  
  1686.  
  1687.  
  1688.       <X.400 address> ::= 'OR address, ISO 10021-2 Annex F'
  1689.  
  1690.       <X.400 routing coordination document set> ::= \
  1691.                             <COMMUNITY-document> \
  1692.                             { <RELAY-MTA-document> } \
  1693.                             { <DOMAIN-document> } \
  1694.                             { <PERSON-document> }
  1695.  
  1696. Security Considerations
  1697.  
  1698.    Security issues are not discussed in this memo.
  1699.  
  1700. Author's Address
  1701.  
  1702.    Urs Eppenberger
  1703.    SWITCH Head Office
  1704.    Limmatquai 138
  1705.    CH-8001 Zurich
  1706.    Switzerland
  1707.  
  1708.    Phone: +41 1 261 8112
  1709.    Fax:   +41 1 261 8133
  1710.  
  1711.    EMail: Eppenberger@switch.ch
  1712.           S=Eppenberger; O=SWITCH; P=SWITCH; A=ARCOM; C=CH;
  1713.  
  1714.    Comments to the document may also be sent to the distribution list
  1715.    wg-msg@rare.nl of the RARE Working Group on Mail and Messaging.
  1716.  
  1717.  
  1718.  
  1719.  
  1720.  
  1721.  
  1722.  
  1723.  
  1724.  
  1725.  
  1726.  
  1727.  
  1728.  
  1729.  
  1730.  
  1731.  
  1732.  
  1733.  
  1734.  
  1735.  
  1736.  
  1737.  
  1738. Eppenberger                                                    [Page 31]
  1739.