[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 02 RFC 1465

X400 Operations Group                                   U. Eppenberger
Internet Draft                                                  SWITCH
                                                      11 November 1992
                                                     Expires: May 1993

              Routing coordination for X.400 MHS services
         within a multi protocol / multi network environment

Status of this Memo

    This document is an Internet Draft.  Internet Drafts are working
  documents of the Internet Engineering Task Force (IETF), its Areas,
  and its Working Groups. Note that other groups may also distribute
  working documents as Internet Drafts).

    Internet Drafts are draft documents valid for a maximum of six
  months. Internet Drafts may be updated, replaced, or obsoleted by
  other documents at any time.  It is not appropriate to use Internet
  Drafts as reference material or to cite them other than as a
  "working draft" or "work in progress."

    Please check the I-D abstract listing contained in each Internet
  Draft directory to learn the current status of this or any other
  Internet Draft.

    It is intended that this document will be submitted to the IESG
  for consideration as a experimental standard.  Distribution of this
  document is unlimited.

1 Introduction

    The usage of the X.400 Message Handling System (MHS) is growing
  rapidly, especially 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
  however, 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 how these problems can be solved in the
  short term. 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

Eppenberger                              Expires: May 1993   [Page  1]

INTERNET-DRAFT  Routing Coordination for X.400 Services  November 1992

  information. The format has been designed to allow the information
  to be stored in a X.500 directory service while managers without
  directory service access may still use a table based approach.

    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.

2 Terminology

  MHS community

      One or more MHS domains form together an MHS community. Mail
    exchange between these MHS domains is defined by the coordination
    procedures within this document. An example of an MHS community is
    the global X.400 MHS service.

  MHS domain

      One or more MHS subtrees form together 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


      Well known Entry Point, an X.400 MTA serving one or several MHS
    domains. (Note that this term is used here in a different way than
    in the early X.400ies (1987/88), where WEP has been used as the
    term for an X.400 MTA serving a whole country.)


      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.

Eppenberger                              Expires: May 1993   [Page  2]

INTERNET-DRAFT  Routing Coordination for X.400 Services  November 1992

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 IXI    1,4   RARE-IXI
      RARE connectionless pilot                2     RARE-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

    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.

4 Outline of the proposal

    This proposal offers a solution for describing information about
  X.400 message routing within an MHS community in WEP and DOMAIN
  documents. Basic information on the MHS community is documented in
  the corresponding COMMUNITY document. All contact persons and WEP
  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.

Eppenberger                              Expires: May 1993   [Page  3]

INTERNET-DRAFT  Routing Coordination for X.400 Services  November 1992

  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 WEP and DOMAIN documents. An MHS community must agree
    on its own set of mandatory and optional networks and stacks.

  4.2 The WEP document

      Every MHS domain in the community may designate one or more MTAs
    as WEPs. These WEPs accept incoming connections from the WEPs of
    the other MHS domains and in return are allowed to send messages
    to these WEPs. A WEP is documented with all the needed connection
    information in the corresponding WEP 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 WEPs
    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 WEPs may
    be added, generally with higher priority, to allow more precise

      An MHS domain may also decide not to operate a WEP. It will then
    only need agreements with one or more WEPs from other MHS domains
    which will relay for this domain. The domain itself, however, must
    always create a DOMAIN document.

      The structure of the DOMAIN document is very straightforward. It
    starts of 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 relaying WEP(s) are
    listed with appropriate priorities.

  4.4 The PERSON document

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

  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

Eppenberger                              Expires: May 1993   [Page  4]

INTERNET-DRAFT  Routing Coordination for X.400 Services  November 1992

    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 WEPs joining the service are tested and support is given to
      create the WEP document.

    - New MHS domains joining the MHS community get assistance to set
      up WEP(s) and find appropriate relaying WEP(s) and to create
      DOMAIN documents.

    - Updated documents are announced to the WEP managers.

    - All the WEP, 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 communites 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 WEPs. The format of the documents has
      especially been choosen to enable the use of automated tools.

  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 kind of mail relays are defined, the primary WEPs and the
    secondary WEPs. All primary and secondary WEPs allow incoming
    connections from each other. The primary WEPs can decide if they
    also use more precise routing and send to the secondary WEPs too.
    A secondary WEP must connect to at least one primary WEP.

      The WEP managers must be aware that a large number of WEPs in an
    MHS community may require significant operational recources to
    keep the local routing tables up-to-date and to constantly monitor
    the correct functioning of the connections.

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

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

Eppenberger                              Expires: May 1993   [Page  5]

INTERNET-DRAFT  Routing Coordination for X.400 Services  November 1992

      An MHS community should also define procedures for new WEPs 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 support this by allowing mandatory and
    optional WEPs. All WEPs accept incoming connections from each
    other. Sending messages can be done by using the mandatory WEPs
    only. This allows new WEPs to join the community as optional and
    to get mandatory status when traffic flow increases.

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

    []   means optional

    {}   means repeated one or more times

    ()...is used to group choices

    '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. The format and semantics should be clear from the names
    of the expressions and the comments given. Expressions without
    more detailed definition are marked with single quotes '.

      Since the documents should still be 'human readable', it is
    possible to use multiple spaces wherever at least one space is
    required. Please note that for some field values the number of
    spaces is significant.

      Comments may be placed anywhere in the document but only on
    separate 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.

      If the information on a line in a document exceeds 80
    characters, it is suggested to do line wrapping according RFC822:
    Wrap the line at any convenient place, generally at a white space,
    then continue on the second line with leading white space.

      Some field values are case sensitive (TSAP, Password). In order
    to handle this issue in a consistent way all keys and values must
    use the same case as the BNF definitions.

Eppenberger                              Expires: May 1993   [Page  6]

INTERNET-DRAFT  Routing Coordination for X.400 Services  November 1992

  5.1 Basic Definitions

      <X.400 routing coordination document set> ::= \
                            <COMMUNITY-document> \
                            { <WEP-document> } \
                            { <DOMAIN-document> } \
                            { <PERSON-document> }
                A set of one COMMUNITY document and several WEP, DOMAIN
                and PERSON documents belong together.

      <DirectoryName> ::= 'Distinguished Name'
                The string representation of a Distinguished Name is
                defined in the IETF OSI-DS document 23. It is still an
                Internet Draft, but the latest version is very likely
                to be accepted at the Nov '92 IETF meeting. 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. However
                the same information must also be present in a document
                as long as not all managers in the same community have
                directory access.

      <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

      <UniqueWEPkey> ::= ([ "P=" 'PRMDname' "; " ] \
                            ["A=" 'ADMDname' "; " ] \
                            "C=" <Country-Code> "; " \
                            "MTAname=" 'MTAname'
                            | <DirectoryName> )
                A unique key is needed to identify the WEP. In addition
                to the MTA name itself, it is proposed to use OR
                address attributes of the management domain where the
                WEP 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 needed 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

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

Eppenberger                              Expires: May 1993   [Page  7]

INTERNET-DRAFT  Routing Coordination for X.400 Services  November 1992

      <X.400 address> ::= 'OR address, ISO 10021-2 Annex F'
                See Appendix B for a brief description of this format.
                It has been used consequently all over the document.
                This explains also the syntax of the <UniqueWEPkey> and
                the <MHS-subtree>.

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

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

      <tel-number> ::=  {"+" <int-pref> " " [<area> " "] \

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

      <area> ::= 'area code'

      <local-tel-no> ::= 'local telefone number'

      <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. Especially if the community
                spans several countries it does make sense to give the
                full address including the country.
                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

      <Update-info> ::= "Update: DATE=" 'yymmdd' \
                            ["; START=" 'yymmdd'] \
                            ["; END=" 'yymmdd'] 'CR'
                The date of the last update of a document is given in
                the form 'yymmdd'.
                An optional start date can 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. WEP managers get more time to prepare
                their systems.)
                An end date is used to set an expiration date for the

Eppenberger                              Expires: May 1993   [Page  8]

INTERNET-DRAFT  Routing Coordination for X.400 Services  November 1992

      <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> "/" \

      <Network-name> ::= 'Name of a network'
                The network-name string identifies a network. A well
                known key word should be choosen. (No '/' character is
                Examples: Public-X.25, Internet, RARE-IXI, RARE-CLNS,

      <Network-service> ::= "X.25" | "CONS" | "CLNS" | "TCP"
                One of the four values identifies the 'network service'
                used. (TCP is considered a network service together
                with RFC1006)

      <Transport-Protocol> ::= "TP0" | "TP2" | "TP4" | "RFC1006"

                The service type consists of a string with three parts
                concatenated with a "/": Network-name/Network-
                Since network and stack information forms one string,
                it identifies in an easy way a connection possibility
                between two WEPs. The COMMUNITY document defines the
                strings to be used in the WEP and DOMAIN documents.
                Some examples:
                (It is probably important to mention here that this
                string has nothing to do with the format of a
                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 beeing 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. As soon as all systems have an NSAP and are
                connected to a global OSI network, this problem will

Eppenberger                              Expires: May 1993   [Page  9]

INTERNET-DRAFT  Routing Coordination for X.400 Services  November 1992

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

  5.2 The COMMUNITY document

      <COMMUNITY-document> ::= <Community-Identifier> \
                            <Update-info> \
                The first line of the COMMUNITY document specifies the
                <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> \

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

      <File-server> ::= <email-server> [{<FTP-server>}] \
                All documents must be available at least to the
                managers of the MHS domains and the WEPs 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

Eppenberger                              Expires: May 1993   [Page 10]

INTERNET-DRAFT  Routing Coordination for X.400 Services  November 1992

      <FTAM-server> ::= "FTAM-server: " \
                            ('P-address' | <DirectoryName>) "; " \
                            <account-name> ["; " 'password'] 'CR'
                The account name is often case sensitive. Some FTAM
                server offer anonymous access with the account-name
                ANON. Documenting a FTAM server with a Distinguished
                Name is only allowed if the server is registered in the

      <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 communities must be
                defined in the community document. It is recommended to
                use the proposed macros in RFC1278 and add new ones if
                Macro: Int-X25(80)        TELEX+00728722+X25(80)+01+
                Macro: Janet-X25(80)      TELEX+00728722+X25(80)+02+
                Macro: Internet-RFC-1006  TELEX+00728722+RFC-1006+03+

      <Connections> ::= {<mandatory-service>} \
                At least one service type is mandatory.

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

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

  5.3 The WEP document

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

      <WEP-document-Identifier> ::= "WEP:  <UniqueWEPkey> 'CR'

      <WEP-document-body> ::= <Status> <connection-info> \

      <Status> ::= "Status: " ("primary" | "secondary")
                This defines if the WEP has 'primary' or 'secondary'
                status. See section 4.3 and 6 for more information.

Eppenberger                              Expires: May 1993   [Page 11]

INTERNET-DRAFT  Routing Coordination for X.400 Services  November 1992

      <connection-info> ::= <password> <RTS> \
                            [<system>] \
                            [<local-domain>] \
                More than one set of connection information may be
                present for WEPs supporting several networks and
                protocol stacks.

      <password> ::= "Password: " \
                            ("***secret***" | "***none***" |
                            'password') 'CR'
                If the keyword ***none*** is present, then no password
                is used.
                If the keyword ***secret*** is present, then the
                connection needs a password which is not made publicly
                available. The community might for example decide to
                keep a list of the passwords at the central
                coordination point. The list is then faxed to the WEP
                If any other string is present, then this is the
                password to be used for the connection.

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

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

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

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

      <called-connection> ::= "Called-address: " \
                            <Service-type> "; " \
                            <P-address> "; " <MTS> '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

Eppenberger                              Expires: May 1993   [Page 12]

INTERNET-DRAFT  Routing Coordination for X.400 Services  November 1992

      <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 WEP document.
                (Note: a calling X.121 address might change if the X.25
                switch is reconfigured. This will stop a WEP from
                connecting to other WEPs using address validation
                without having changed anything at the higher layers!)

      <system> ::= "System: COM=" 'computer type' "; " \
                            "OPS=" 'operating system' "; " \
                            "MHS=" '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. Such an address should be routed through
                the WEP or even end up on the WEP. This is not a
                routing definition! The LocalDomain attributes might be
                used together with S=nosuchuser to do connectivity and
                availability tests.

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

      <contact-info> ::= {"Administrator: " <UniquePersonKey> 'CR'}
                The contact details for the WEP 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-entry>}  <responsible> \

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

Eppenberger                              Expires: May 1993   [Page 13]

INTERNET-DRAFT  Routing Coordination for X.400 Services  November 1992

      <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 OU*,
                O, P, A and C only.)
                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).

                Note that it is not allowed to have equal <MHS-subtree>
                lines in different DOMAIN documents belonging to the
                same MHS community. An MHS subtree can only appear in
                one DOMAIN document.

      <responsible> ::= {"Administrator: " <UniquePersonKey> 'CR'}
                This is the person responsible for the listed domains.
                His task is to get the agreement of the relaying WEPs
                and keep the DOMAIN document up-to-date. This person is
                the only one authorized to make changes to this

      <relay-WEP> ::=         "WEP: " \
                            'UniqueWEPkey' "; " \
                            <Default-Priority> "; " \
                            <Delay> 'CR' \
                            [ { "Net: " <Service-type> "; " \
                            <Priority> 'CR' } ]
                A WEP has a  default priority and a delay field. The
                priority is used to define the sequence in which
                different WEPs may be tried in case of failure.
                The delay defines how long a sending WEP needs to wait
                until it is allowed to select this WEP in case the
                connection to the preferred WEP has failed.
                It is also possible to set different priorities on each
                network type. This may be chosen, for example, to
                distribute the load amongst different networks
                according to their available bandwith.

      <Default-Priority> ::= <Number 0..infinite>

      <Priority> ::= <Number 0..infinite>

Eppenberger                              Expires: May 1993   [Page 14]

INTERNET-DRAFT  Routing Coordination for X.400 Services  November 1992

      <Delay> ::= <Minutes 0..infinite>
                The exact meaning of these values and how they should
                be used is explained in the next section.

  5.5 The PERSON document

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

      <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.

      <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
                also the reason why it is possible to provide multiple
                OR and RFC822 addresses. The first one is considered
                the primary one.

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

      <time> ::= 'hh:mm'

      <Time-zone> ::= ("UTC+" | "UTC-") 'hours'
                The operation information is needed to know the time a
                WEP manager is reachable. This information is
                especially important for communities spanning several
                time zones.
                The Reachable: entry may be followed by a comment line
                indicating when Daylight Saving Time is in effect. This
                is especially reasonable for MHS communities spanning
                several continents.

Eppenberger                              Expires: May 1993   [Page 15]

INTERNET-DRAFT  Routing Coordination for X.400 Services  November 1992

6 Routing rules

    ** 1 **

    Every WEP must accept connections on its documented service types
  (network and protocol stacks) from all other WEPs in the MHS

    The relaying of the messages between the MHS domains is done using
  the WEP infrastructure. All WEPs with authorization mechanisms must
  guarantee that all incoming connections from the other WEPs are

    ** 2 **

    Every WEP must accept messages originating in any of the MHS
  domains of the MHS community to which it belongs.

    All the users within the MHS community have the right to send
  messages to each other. The general agreement is that the WEP
  infrastructure is used. More direct connections based on bilateral
  agreements are fully accepted.

    ** 3 **

    Every WEP must forward messages to the recipients listed in the
  DOMAIN document.

    The responsible person for an MHS domain must get an agreement
  from the relaying WEPs prior to publishing the DOMAIN document.

      The result of the first three rules is that messages sent from
  one MHS domain to another of the same community are replyable.

    ** 4 **

    A message arriving at a WEP must either be sent to the next WEP
  based on the DOMAIN documents of the MHS community or it is sent to
  an MTA closer to the destination based on local know-how. The
  following algorithm must be used when relaying a message to the next

  1 Match the Recipient address in the message with the longest
    fitting MHS subtree from the DOMAIN documents. (The value on the
    line starting with the key "Domain:".) Also get the list of WEPs
    relaying to this MHS subtree.

    If your own WEP appears in this list, this indicates one of the

Eppenberger                              Expires: May 1993   [Page 16]

INTERNET-DRAFT  Routing Coordination for X.400 Services  November 1992

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

    - Your WEP 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 WEPs for the obtained MHS subtree select those
    that can be reached directly. (Based on the information in the WEP
    documents beginning with "Called:".)

  3 Now decide if you want to send to secondary WEPs too. If you
    decide to use primary WEPs only for your routing, then delete all
    secondary WEPs from the list.

  4 Select from this reduced set of WEPs the one with the highest
    default priority. If there is more than one WEP having the same
    priority, then select a WEP at random. If your own WEP appears in
    that list then you are not allowed to send to a WEP with lower or
    equal priority.

  5 If there are no other lines indicating which service type to use,
    you are free to choose the service type for connecting to the WEP.
    However, if there are specific priorities set then select the
    network with the highest priority.

  6 If the connection fails then try other connections in the sequence
    of descending priority.

  7 If no connection works for the selected WEP, then check in the
    list for the one with the same priority, if possible, or else
    select one with the next lower priority. Retry establishing the
    connection to the first WEP until the number of minutes indicated
    in the delay field for the second WEP has passed, then switch to
    the second WEP. Go to step 5 to proceed with the selection of the
    connection type.

  6.1 How to use priorities

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

Eppenberger                              Expires: May 1993   [Page 17]

INTERNET-DRAFT  Routing Coordination for X.400 Services  November 1992

      Community: REMOTEmail

      +-------+    X.25     +-------+ (                           )
      | WEP A +-------------+ WEP B +-(C=CH;ADMD=ARCOM;PRMD=REMOTE)
      +-------+             +-------+ (___________________________)
               \           /
         TCP/IP \         /X.25
                 | WEP-C |

      WEP-A needs to relay a message for C=CH;ADMD=ARCOM;PRMD=REMOTE.
    Rule **4** is evaluated step by step:

        1 WEP-B and WEP-C are possible destinations

        2 WEP-B and WEP-C are reachable from WEP-A

        3 WEP-B is a primary WEP (not relevant in this example)

        4 WEP-B has the highest priority.

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

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

      Note that forcing other WEPs to use a specific stack should be
    avoided wherever possible by offering WEPs 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

Eppenberger                              Expires: May 1993   [Page 18]

INTERNET-DRAFT  Routing Coordination for X.400 Services  November 1992

  6.2 How to use delays

      Two WEPs offer real backup connectivity for the MHS domain
    C=CH;ADMD=ARCOM;PRMD=REMOTE. It is therefore possible to set the
    delay to zero for both WEPs. WEP-B will be the preferred one since
    it has the higher priority. If the connection to WEP-B fails, a
    sending WEP may immediately try to connect to WEP-C.

      Community: REMOTEmail

      +-------+             +-------+ (                           )
      | WEP-A +-------------+ WEP-B +-(C=CH;ADMD=ARCOM;PRMD=REMOTE)
      +-------+             +-------+ (___________________________)
               \                     /
                \           +-------+
                 -----------+ WEP-C |

      The next case is the same as in section 6.1. By setting the
    delay to 120 minutes for WEP-C the sending WEP retries
    establishing a connection for two hours until it is allowed to
    send messages to WEP-C.

      Community: REMOTEmail
      +-------+    X.25     +-------+ (                           )
      | WEP A +-------------+ WEP B +-(C=CH;ADMD=ARCOM;PRMD=REMOTE)
      +-------+             +-------+ (___________________________)
               \           /
         TCP/IP \         /X.25
                 | WEP C |

      Here it is important to have a high delay entry for WEP-C. Else
    it would act as a remote spooling system for WEP-B, storing all
    the messages sent to the MHS domain by the rest of the MHS
    community! A high delay entry forces the sending WEPs to spool the
    messages themselves which distributes the usage of resources.

      In the case where WEP-C acts as a relay server for the TCP/IP
    stack which is not supported by WEP-B it does not harm the service
    to have a high related delay entry. A sending WEP with only this
    stack will select WEP-C anyhow because it is the WEP with the
    highest priority it can reach directly.

Eppenberger                              Expires: May 1993   [Page 19]

INTERNET-DRAFT  Routing Coordination for X.400 Services  November 1992

  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 WEPs 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 subdomains and
    document them separately with a set of WEPs with different

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

      Community: REMOTEmail
          _               ___________________________
           )  +-------+  (                           )
           )--+ WEP-B +--(C=CH;ADMD=ARCOM;PRMD=REMOTE)
           )  +-------+  (___________________________)
           )            /
           )  +-------+/
           )--+ WEP-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 both WEPs serve as backup WEPs.

      Community: REMOTEmail

      Community: REMOTEmail
          _               ___________________________
           )  +-------+  (                           )
           )--+ WEP-B +--(C=CH;ADMD=ARCOM;PRMD=REMOTE)
           )  +-------+  (___________________________)
           )           \/
           )           /\ _____________________________________
           )  +-------+  (                                     )
           )--+ WEP-C |--(C=CH;ADMD=ARCOM;PRMD=REMOTE;O=Big-Org)
          _)  +-------+  (_____________________________________)

Eppenberger                              Expires: May 1993   [Page 20]

INTERNET-DRAFT  Routing Coordination for X.400 Services  November 1992

      A third example shows a similar load sharing agreement as the
    previous one but it uses different delay values since WEP-B
    doesn't have direct connectivity to the MHS domain

      Community: REMOTEmail

      Community: REMOTEmail
            _               ___________________________
             )  +-------+  (                           )
             )--+ WEP-B +--(C=CH;ADMD=ARCOM;PRMD=REMOTE)
             )  +---+---+  (___________________________)
             )      |     /
             )      |    /  _____________________________________
             )  +---+---+  (                                     )
             )--+ WEP-C |--(C=CH;ADMD=ARCOM;PRMD=REMOTE;O=Big-Org)
            _)  +-------+  (_____________________________________)

7 Open issues

    Currently there are about 30 WEPs within the COSINE-MHS service. A
  rough guess is that a network with about 50 WEPs is still
  manageable. If there are more MTAs applying for WEP 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-WEPs should form a
  backbone, documented within a specific MHS community.

    Since the WEP 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)WEP. The rules in chapter 6 could
  be modified to select X.400(88) systems first if the sending WEP is
  an (88) system itself. The issue of how to establish an X.400(88)
  WEP infrastructure within an MHS community is for further study.

Security Considerations

    Security considerations are not discussed in this memo.

Eppenberger                              Expires: May 1993   [Page 21]

INTERNET-DRAFT  Routing Coordination for X.400 Services  November 1992

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 uses
  X.400 since several years. This proposal has initially been written
  to address this community only and solve the urgent routing and
  coordination problems. Contributions from different experts made it
  more flexible and therefore hopefully useful for other MHS

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: DATE=921111; START=930201
  Address: S=Project-Team; OU=COSINE-MHS; O=SWITCH; P=SWITCH
           A=ARCOM; C=CH;
  Phone: +41 1 2623143
  FAX: +41 1 2623151
  Mail: SWITCH Head Office/COSINE-MHS Project Team/
        Limmatquai 138/ CH-8001 Zurich/Switzerland
               P=SWITCH; A=ARCOM; C=CH;
  FTP-server:  nic.switch.ch; cosine-mhs; 'your email address'
  Macro: Int-X25(80)        TELEX+00728722+X25(80)+01+
  Macro: Internet-RFC-1006  TELEX+00728722+RFC-1006+03+
  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
  # 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: RARE-CLNS/CLNS/TP4
  # The RARE Connectionless pilot service. Current participants are
  # NORDUnet, SURFnet, CERN, NSFnet and SWITCH.
  Optional-Service: RARE-IXI/X.25/TP0
  # The International X.25 Infrastructure covering most countries in
  # Europe. The absence of volume tariffs make it a preferred choice.

Eppenberger                              Expires: May 1993   [Page 22]

INTERNET-DRAFT  Routing Coordination for X.400 Services  November 1992

Appendix A2 Example of a WEP document

  Community: COSINE-MHS
  Update: DATE=921111; START=930201
  WEP: P=SWITCH; A=ARCOM; C=CH; MTAname=vms.switch
  Status:          primary

  Password:        ***none***
  RTS-dialog-mode: TWA
  Called-address:  Public-X.25/X.25/TP0;
                   Int-X25(80)=22847971014110; MTS-TP-84
  Calling-address: Public-X.25/X.25/TP0;
  Called-address:  Internet/TCP/RFC1006;
                   Internet-RFC-1006=; MTS-TP-84
  Calling-address: Internet/TCP/RFC1006;
  System: COM=DEC VAX4000-300; OPS=VMS 5.4; MHS=DFN-EAN V2.2+
  LocalDomain: O=switch; P=switch; A=arcom; C=ch;
  EchoServer:  S=echo; O=switch; P=switch; A=arcom; C=ch;
  Administrator: CN=Christoph Graf, O=SWITCH, C=CH
  Administrator: CN=Urs Eppenberger, O=SWITCH, C=CH

Eppenberger                              Expires: May 1993   [Page 23]

INTERNET-DRAFT  Routing Coordination for X.400 Services  November 1992

Appendix A3 Example of a DOMAIN document

  Community: COSINE-MHS
  Update: DATE=921111; 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=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;
  WEP: P=SWITCH; A=ARCOM; C=CH; MTAname=vms.switch; 20; 0
  Net: Internet/TCP/RFC1006; 9
  Net: Public-X.25/X.25/TP0; 8
  WEP: P=SWITCH; A=ARCOM; C=CH; MTAname=chx400.switch.ch; 10; 10
  Net: Internet/TCP/RFC1006; 20
  Net: Public-X.25/X.25/TP0; 10

Appendix A4 Example of a PERSON document

  Community: COSINE-MHS
  Update: DATE=921111; START=930201
  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/
  Reachable: 09:00-12:00; 14:00-17:30; UTC-1

Eppenberger                              Expires: May 1993   [Page 24]

INTERNET-DRAFT  Routing Coordination for X.400 Services  November 1992

Appendix B  OR Address Representation

    This Appendix defines the OR address representation to be used
  throughout the documents.It is based on the following CCITT

      Annex to CCITT Rec. F.401 and ISO/IEC 10021-2

    and on a document written by Paul-Andre Pays which defines a
  subset of the CCITT recommendation to limit the options and
  automatic processable addresses. The definitions for the routing
  documents is even more strict than proposed by P-A Pays which allows
  for easier parsing tools.

    Only printable string is allowed for values of OR attributes in
  the routing documents.

    O/R addresses in labelled format consist of delimited pairs of
  labels and values in the syntax <label>"="<value>;.  The labels for
  each attribute are specified in Tables T-1 and T-2.  The label and
  its value must be separated by the character "=". The value is case

    The ADMD attribute must always be present even if its value
  consists only of a single space.

    The label for a DDA consists of "DDA:" followed by the DDA type.
  If an address includes more than one DDA of the same type, it is
  assumed that the DDAs are intended to be processed in the sequence
  in which they are represented. If the value of a DDA type includes
  the character "=", this should be represented by "==".

    Label/value pairs appear in sequence on a line, they should be
  delimited by ";". (The ";" character is not in the set of printable
  strings which makes it an excellent choice as delimiter. No escaping
  is needed as for the '=' character.)

    Each ';' must be followed by white space.

    The sequence of attributes must be the one given in the tables T-1
  and T-2.

Eppenberger                              Expires: May 1993   [Page 25]

INTERNET-DRAFT  Routing Coordination for X.400 Services  November 1992

      Attribute Type                              Label

      X.121 Network Address                       X.121
      E.164 Network Address                       E.164
      PSAP Network Address                        PSAP
      User Agent Numeric ID                       N-ID
      Terminal Identifier                         T-ID

      Terminal Type                               T-TY
      Domain Defined Attribute                    DDA:<type>

      where the notation <type> identifies the type of domain defined

      There are currently six terminal types, and if international
      consistency is required the following specific abbreviations
      should be used to represent the values for these types: tlx,
      ttx, g3fax, g4fax, ia5 and vtx.

    Table T-1.  Other Attributes

      Attribute Type                              Label

      Given Name                                  G
      Initials                                    I
      Surname                                     S
      Generation Qualifier                        Q
      Common Name                                 CN
      Organisation                                O
      Organisational Unit 1                       OU1
      Organisational Unit 2                       OU2
      Organisational Unit 3                       OU3
      Organisational Unit 4                       OU4
      Private Management Domain Name              P
      Administration Management Domain Name       A
      Country                                     C

    Table T-2.  Standard Attributes of the Mnemonic Address Form


      G=john; S=smith; O=a bank ltd; P=abl; A=snomail; C=aq;
      G=Daniel; S=terrer; P=inria; A=atlas; C=FR;
      S=terrer; OU1=mirsa; P=inria; A=atlas; C=FR;
      DDA:RFC-822=we(a)sell-it.com; P=internet; A= ; C=fi;

Eppenberger                              Expires: May 1993   [Page 26]

INTERNET-DRAFT  Routing Coordination for X.400 Services  November 1992

Author's Address

  Urs Eppenberger
  SWITCH Head Office
  Limmatquai 138
  CH-8001 Zurich

  Phone: +41 1 261 8112

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

Eppenberger                              Expires: May 1993   [Page 27]

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/