As per Relevance of the word services, we have this rfc below:










Network Working Group D.
Request for Comments: 1465
May 1993


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

Status of this

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

1.

The usage of the X.400 Message Handling System (MHS) is
rapidly, especially in the commercial world but much interest
also be found in the academic and research community. New
and new addresses come into use each and every day. The
technology for different X.400 networks can vary depending on
transport network and the X.400 MHS implementations used. As a
number of X.400 implementations now support multiple stacks,
offers the chance of implementing a world wide message
service using the same electronic mail standard and, therefore
without the need of gateways with service reduction and without
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

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

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

The routing structure proposed can be applied to a global MHS



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
organisation

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

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

2.

MHS

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

MHS

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

MHS

An MHS subtree consists of the total of the mailboxes
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
mailboxes with O=SWITCH; P=SWITCH; A=ARCOM; C=CH; in the
address

RELAY-

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



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
clearly the functionality of the MTA

COSINE-

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

3.

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

Stack 1 Stack 2 Stack 3 Stack 4

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

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

Network Stack

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

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

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

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



Eppenberger [Page 3]

RFC 1465 Routing Coordination for X.400 Services May 1993


4. Outline of the

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

4.1 The COMMUNITY

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

4.2 The RELAY-MTA

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

4.3 The DOMAIN

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

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



Eppenberger [Page 4]

RFC 1465 Routing Coordination for X.400 Services May 1993


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

4.4 The PERSON

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

4.5

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

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

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

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

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

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

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



Eppenberger [Page 5]

RFC 1465 Routing Coordination for X.400 Services May 1993


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

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

4.6

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

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

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

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

5. The

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


| means

\ is used for continuation of a definition over several



Eppenberger [Page 6]

RFC 1465 Routing Coordination for X.400 Services May 1993



[] means

{} means repeated one or more

() is used to group

\" is used for double quotes in a text

is a Carriage Return and means that the next section
on its own line

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

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

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

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

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

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

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

coordination document set> ::= \
<COMMUNITY-document> \
{ document> } \
{ document> } \
{ document> }




Eppenberger [Page 7]

RFC 1465 Routing Coordination for X.400 Services May 1993


5.1 Common

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

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

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

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

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

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



Eppenberger [Page 8]

RFC 1465 Routing Coordination for X.400 Services May 1993


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

::= "Address: "
::= [{"; " }]

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

::= 'international prefix

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

<extension> ::= 'local extension

::= "Phone: " One or more phone

::= "Fax: " One or more FAX

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


::= "Update: FORMAT=V3; DATE=" 'yymmdd' \
"; START=" 'yymmdd' \
["; END=" 'yymmdd'] The contains also the format identifier



Eppenberger [Page 9]

RFC 1465 Routing Coordination for X.400 Services May 1993


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

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

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

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

::= 'Name of a network service
Examples: X.25, CONS, CLNS,

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

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



Eppenberger [Page 10]

RFC 1465 Routing Coordination for X.400 Services May 1993


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

::= ["O=" 'Organization-name' "; "] \
["OU1="'OrganizationalUnit'"; "\
["OU2=" 'OrganizationalUnit' "; " \
["OU3=" 'OrganizationalUnit' "; " \
["OU4=" 'OrganizationalUnit' "; "]]]] \
["P=" 'PRMDname' "; "] \
"A=" 'ADMDname' "; " \
"C=" ";"

<Operation> ::= "Reachable: " {



if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.



RFC documents can be found at I.E.T.F.



Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX






Spectrum