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)
|
|
Author |
|
Urs Eppenberger
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
html
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