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

Document Type RFC - Experimental (May 1993; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf htmlized bibtex
Stream WG state WG Document
Document shepherd No shepherd assigned
IESG IESG state RFC 1465 (Experimental)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                     U. Eppenberger
Request for Comments: 1465                                        SWITCH
                                                                May 1993

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

Status of this Memo

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

1. Introduction

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

   - Where do I route new X.400 addresses and

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

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

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

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

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

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

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

2. Terminology

   MHS community

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

   MHS domain

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

   MHS subtree

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

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

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

   RELAY-MTA

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

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

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

   COSINE-MHS

      The COSINE-MHS community is mainly formed by European X.400
      service providers from the academic and research area, each of
      which is a member of RARE.  The COSINE-MHS community is used in
Show full document text