draft-ietf-x400ops-mhs-service-02.txt   rfc1465.txt 
X400 Operations Group U. Eppenberger Network Working Group U. Eppenberger
Internet Draft SWITCH Request for Comments: 1465 SWITCH
11 November 1992 May 1993
Expires: May 1993
Routing coordination for X.400 MHS services Routing Coordination for X.400 MHS Services
within a multi protocol / multi network environment Within a Multi Protocol / Multi Network Environment
Table Format V3 for Static Routing
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This memo defines an Experimental Protocol for the Internet
documents of the Internet Engineering Task Force (IETF), its Areas, community. Discussion and suggestions for improvement are requested.
and its Working Groups. Note that other groups may also distribute Please refer to the current edition of the "IAB Official Protocol
working documents as Internet Drafts). Standards" for the standardization state and status of this protocol.
Distribution of this memo is unlimited.
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 1. Introduction
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 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:
The usage of the X.400 Message Handling System (MHS) is growing - Where do I route new X.400 addresses and
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.
- How do I connect to a MHS domain that uses an underlying This document proposes short term solutions to these problems. It
technology that I do not support. 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.
This document proposes how these problems can be solved in the The routing structure proposed can be applied to a global MHS service
short term. It proposes a strategy for maintaining and distributing but may also be used at a national level or even within an
routing information and shows how messages can travel over different organisation.
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] Many experts from IETF X.400-Operations Group and RARE Working Group
information. The format has been designed to allow the information 1 on Message Handling Systems have read drafts of this document and
to be stored in a X.500 directory service while managers without contributed ideas and solutions. I would especially like to thank
directory service access may still use a table based approach. Harald Alvestrand, Erik Huizer, Marko Kaittola, Allan Cargille and
Paul-Andre Pays.
Many experts from IETF X.400-Operations Group and RARE Working This is the third version of a table format. The first one was in
Group 1 on Message Handling Systems have read drafts of this use within COSINE-MHS for about two years. A second version with
document and contributed ideas and solutions. I would especially major enhancements was then proposed which has been in use for the
like to thank Harald Alvestrand, Erik Huizer, Marko Kaittola, Allan past year. The third version will probably be the last one before it
Cargille and Paul-Andre Pays. will be possible to switch to dynamic, directory service based
routing.
2 Terminology 2. Terminology
MHS community MHS community
One or more MHS domains form together an MHS community. Mail One or more MHS domains form an MHS community. Mail exchange
exchange between these MHS domains is defined by the coordination between these MHS domains is defined by the coordination
procedures within this document. An example of an MHS community is procedures within this document. Examples of such communities are
the global X.400 MHS service. the Global Open MHS service GO-MHS and the COSINE-MHS service.
MHS domain MHS domain
One or more MHS subtrees form together an MHS domain. This is a One or more MHS subtrees form an MHS domain. This is a purely
purely administrative grouping of MHS subtrees. It is helpful, if administrative grouping of MHS subtrees. It is helpful, if
someone is responsible for several MHS subtrees, to refer to an someone is responsible for several MHS subtrees, to refer to an
MHS domain instead of listing all the subtrees. MHS domain instead of listing all the subtrees.
MHS subtree MHS subtree
An MHS subtree consists of the total of the mailboxes An MHS subtree consists of the total of the mailboxes addressable
addressable within a subtree of the X.400 OR address space. within a subtree of the X.400 OR address space.
Example: O=SWITCH; P=SWITCH; A=ARCOM; C=CH; Example: O=SWITCH; P=SWITCH; A=ARCOM; C=CH;
MHS domain of SWITCH in Switzerland, consisting of all MHS domain of SWITCH in Switzerland, consisting of all
mailboxes with O=SWITCH; P=SWITCH; A=ARCOM; C=CH; in the OR mailboxes with O=SWITCH; P=SWITCH; A=ARCOM; C=CH; in the OR
address. address.
WEP RELAY-MTA
Well known Entry Point, an X.400 MTA serving one or several MHS An X.400 MTA serving one or several MHS domains. Note that the
domains. (Note that this term is used here in a different way than term WEP -Well Known Entry Point- has been used since the early
in the early X.400ies (1987/88), where WEP has been used as the X.400ies (1987/88) until now, giving the wrong impression of a
term for an X.400 MTA serving a whole country.) 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 COSINE-MHS
The COSINE-MHS community is mainly formed by European X.400 The COSINE-MHS community is mainly formed by European X.400
service providers from the academic and research area, each of service providers from the academic and research area, each of
which is a member of RARE. The COSINE-MHS community is used in the which is a member of RARE. The COSINE-MHS community is used in
annex as an example for the usage of this document in a the annex as an example for the usage of this document in a
multinational environment. multinational environment.
Eppenberger Expires: May 1993 [Page 2] 3. Requirements
3 Requirements
X.400 MTAs can communicate using different transport and network X.400 MTAs can communicate using different transport and network
protocol stacks. For this document the stacks used in a WAN protocol stacks. For this document the stacks used in a WAN
environment need to be considered: environment need to be considered:
Stack 1 Stack 2 Stack 3 Stack 4 Stack 1 Stack 2 Stack 3 Stack 4
Transport Layer 4 TP0 TP4 RFC1006 TP0 Transport Layer 4 TP0 TP4 RFC1006 TP0
Networkservice 1-3 X.25 CLNS TCP/IP CONS Networkservice 1-3 X.25 CLNS TCP/IP CONS
A common protocol stack is not the only requirement to enable A common protocol stack is not the only requirement to enable
communication between two MTAs. The networks to which the MTAs communication between two MTAs. The networks to which the MTAs
belong need to be interconnected. Some well known networks are belong need to be interconnected. Some well known networks are
listed together with the stacks they use. listed together with the stacks they use.
Network Stack Abbreviation Network Stack Abbreviation
Public Switched Packet Data Networks 1 Public-X.25 Public Switched Packet Data Networks 1 Public-X.25
International X.25 Infrastructure IXI 1,4 RARE-IXI International X.25 Infrastructure EMPB 1,4 EMPB-X.25
RARE connectionless pilot 2 RARE-CLNS US and European connectionless pilot 2 Int-CLNS
Internet 2,3 Internet Internet 2,3 Internet
Note that several stacks may be supported over a single network. Note that several stacks may be supported over a single network.
However communication between MTAs is only possible if the MTAs However communication between MTAs is only possible if the MTAs share
share at least a common stack AND a common network. 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
available.
Furthermore it is not generally allowed to connect to any MTA even Unlike SMTP/TCP/IP systems, there is no directory service available
on the same network without being registered on the destination MTA. which would allow an MTA to look up the next MTA to which it should
These restrictions require a large coordination effort and carefully submit a message. Routing within X.400 will continue to be table
configured and updated systems. based until a solution using X.500 directory services is available.
4 Outline of the proposal 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.
This proposal offers a solution for describing information about 4. Outline of the proposal
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] This proposal offers a solution for describing information about
4.1 The COMMUNITY document X.400 message routing within an MHS community in RELAY-MTA and DOMAIN
documents. Basic information on the MHS community is documented in
the corresponding COMMUNITY document. All contact persons and
RELAY-MTA 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.
For each MHS community there exists one single COMMUNITY 4.1 The COMMUNITY document
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 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 RELAY-MTA and DOMAIN
documents. An MHS community must agree on its own set of mandatory
and optional networks and stacks.
Every MHS domain in the community may designate one or more MTAs 4.2 The RELAY-MTA document
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 Every MHS domain in the community may designate one or more MTAs as
RELAY-MTAs. These RELAY-MTAs accept incoming connections from the
RELAY-MTAs of the other MHS domains and in return are allowed to send
messages to these RELAY-MTAs. A RELAY-MTA is documented with all the
necessary connection information in the corresponding RELAY-MTA
document.
An MHS domain has a responsible person who sets up the routing 4.3 The DOMAIN document
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
routing.
An MHS domain may also decide not to operate a WEP. It will then An MHS domain has a responsible person who sets up the routing
only need agreements with one or more WEPs from other MHS domains entries for the domain in the DOMAIN document. The primary RELAY-
which will relay for this domain. The domain itself, however, must MTAs listed in the DOMAIN document as serving this MHS domain must,
always create a DOMAIN document. TOGETHER, offer at least connectivity to all networks and stacks
listed as mandatory in the COMMUNITY document. Optional RELAY-MTAs
may be added, generally with higher priority, to allow more precise
routing.
The structure of the DOMAIN document is very straightforward. It An MHS domain may also decide not to operate a RELAY-MTA. It will
starts of with one or more MHS subtrees, each on its own line. then only need agreements with one or more RELAY-MTAs from other MHS
After the domains follows a line indicating the responsible person services which will relay for this domain. The domain itself,
for the MHS subtrees mentioned. Finally the relaying WEP(s) are however, must either create its own DOMAIN document or document its
listed with appropriate priorities. MHS subtrees jointly with another MHS domain.
4.4 The PERSON document The structure of the DOMAIN document is very straightforward. It
starts off 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 responsible RELAY-MTA(s)
are listed with appropriate priorities.
All administrators and responsible persons are documented in 4.4 The PERSON document
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
address.
4.5 Coordination All administrators and responsible persons are documented in PERSON
documents. The RELAY-MTA and DOMAIN documents contain just keys
pointing to a PERSON document. If such a person can already be found
in an X.500 directory service, then the key consists of a
Distinguished Name, else the key is just its OR address.
This approach requires an identified coordination point. It is 4.5 Coordination
up to the MHS community to decide on the level of coordination and
Eppenberger Expires: May 1993 [Page 4] This approach requires an identified coordination point. It is up to
support to be provided and on the funding mechanisms for such the MHS community to decide on the level of coordination and support
activities. Basic information can be found in the COMMUNITY to be provided and on the funding mechanisms for such activities.
document. The following list of support activities is considered Basic information can be found in the COMMUNITY document. The
mandatory for an operational service: following list of support activities is considered mandatory for an
operational service:
- New WEPs joining the service are tested and support is given to - New RELAY-MTAs joining the service are tested and support is
create the WEP document. given to create the RELAY-MTA document.
- New MHS domains joining the MHS community get assistance to set - New MHS domains joining the MHS community get assistance to set
up WEP(s) and find appropriate relaying WEP(s) and to create up RELAY-MTA(s) and/or find appropriate RELAY-MTA(s) and to
DOMAIN documents. create DOMAIN documents.
- Updated documents are announced to the WEP managers. - Updated documents are announced to the RELAY-MTA managers and
responsible persons for the DOMAIN documents unless automatic
distribution is used.
- All the WEP, DOMAIN and PERSON documents are made available on a - All the RELAY-MTA, DOMAIN and PERSON documents are made
file server together with the COMMUNITY document. The file available on a file server together with the COMMUNITY document.
server must at least be reachable via email. MHS communites with The file server must at least be reachable via email. MHS
a big number of documents may consider additional access methods communities with a big number of documents may consider
like ftp and FTAM. additional access methods like ftp and FTAM.
- Tools should be made available to manage routing tables for the - Tools should be made available to manage routing tables for the
X.400 software used on the WEPs. The format of the documents has X.400 software used on the RELAY-MTAs or to fill in and check
especially been choosen to enable the use of automated tools. the documents. The format of the documents has specifically
been chosen to enable the use of automated tools.
4.6 Routing The RELAY-MTA managers must be aware that a large number of RELAY-
MTAs in an MHS community may require significant operational
resources to keep the local routing tables up-to-date and to
constantly monitor the correct functioning of the connections. On
the other hand more than one RELAY-MTA with a good connectivity to an
MHS domain improves the overall robustness of the domain and thus the
QOS.
The proposal addresses MHS communities spanning several MHS communities may decide on additional mandatory requirements for
organisations. But it may also be used to manage routing within a the operation of a RELAY-MTA. These may include a hot line, echo
single organisation or even a global MHS community. services, exchange of statistics, response time to problem reports,
uptime of the RELAY-MTA, etc. This will ensure a certain quality of
service for the end users.
Two kind of mail relays are defined, the primary WEPs and the 4.6 Routing
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 The proposal addresses MHS communities spanning several
MHS community may require significant operational recources to organisations. But it may also be used to manage routing within a
keep the local routing tables up-to-date and to constantly monitor single organisation or even a global MHS community.
the correct functioning of the connections.
MHS communities may decide on additional mandatory requirements Two kinds of mail relays are defined, the primary RELAY-MTAs and the
for the operation of a WEP. These may include a hot line, echo secondary RELAY-MTAs. A primary or secondary RELAY-MTA must allow
services, exchange of statistics, response time to problem incoming connections from all other primary and secondary RELAY-MTAs
reports, uptime of the WEP, etc. This will ensure a certain with a common stack. Primary RELAY-MTAs must be able to connect to
quality of service for the end users. all other primary RELAY-MTAs which share a common stack. A secondary
RELAY-MTA must connect to at least one primary RELAY-MTA.
Each MHS community must define update procedures for the routing Each MHS community must define update procedures for the routing
based on the documentation. Automated update has to be studied based on the documentation. Automated update has to be studied
carefully. carefully.
Eppenberger Expires: May 1993 [Page 5] An MHS community should also define procedures for new RELAY-MTAs and
An MHS community should also define procedures for new WEPs and MHS domains joining the service. Since the usage of X.400 is growing
MHS domains joining the service. Since the usage of X.400 is rapidly a flexible but well coordinated way of integrating new
growing rapidly a flexible but well coordinated way of integrating members into an MHS community is needed. The proposed documentation
new members into an MHS community is needed. The proposed format supports this by allowing primary and secondary RELAY-MTAs.
documentation format support this by allowing mandatory and All RELAY-MTAs accept incoming connections from each other. Sending
optional WEPs. All WEPs accept incoming connections from each messages can be done by using the primary RELAY-MTAs only. This
other. Sending messages can be done by using the mandatory WEPs allows new RELAY-MTAs to join the community as secondary and to get
only. This allows new WEPs to join the community as optional and primary status when traffic flow increases. Secondary RELAY-MTAs may
to get mandatory status when traffic flow increases. also require a longer testing period.
5 The documents 5. The documents
The definition is given in BNF-like syntax. The following The definition is given in BNF-like syntax. The following
conventions are used: conventions are used:
| means choice | means choice
\ is used for continuation of a definition over several lines \ is used for continuation of a definition over several lines
[] means optional [] means optional
{} means repeated one or more times {} means repeated one or more times
()...is used to group choices () is used to group choices
'CR' is a Carriage Return and means that the next section starts \" is used for double quotes in a text string
on its own line.
The definition is complete only to a certain level of detail. <CR> is a Carriage Return and means that the next section starts
Below this level, all expressions are to be replaced with text on its own line.
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 The definition is complete only to a certain level of detail. Below
possible to use multiple spaces wherever at least one space is this level, all expressions are to be replaced with text strings.
required. Please note that for some field values the number of Expressions without more detailed definition are marked with single
spaces is significant. quotes '. The format and semantics should be clear from the names of
the expressions and the comments given.
Comments may be placed anywhere in the document but only on Wherever the BNF definition requires a single blank, multiple blanks
separate lines. Such a comment line must either start with a '#' may be used to increase the readability. Please note that for some
sign followed by white space and the comment or consist of a field values the number of spaces is significant.
single '#' on a single line.
If the information on a line in a document exceeds 80 Lines exceeding 80 characters should be wrapped at any convenient
characters, it is suggested to do line wrapping according RFC822: blank except at blanks which are significant. The line is continued
Wrap the line at any convenient place, generally at a white space, with at least one leading blank.
then continue on the second line with leading white space.
Some field values are case sensitive (TSAP, Password). In order Comments may be placed anywhere in the document but only on separate
to handle this issue in a consistent way all keys and values must lines and without splitting wrapped lines. Such a comment line must
use the same case as the BNF definitions. either start with a '#' sign followed by white space and the comment
or consist of a single '#' on a single line.
Eppenberger Expires: May 1993 [Page 6] The documents must follow the case of the strings defined in BNF.
5.1 Basic Definitions Note that some values, especially connection parameters like TSEL or
MTA password are case dependant too.
The BNF definitions are ordered top-down. See Appendix B for an
alphabetically sorted list.
A set of one COMMUNITY document and several RELAY-MTA, DOMAIN and
PERSON documents belong together. The detailed definitions can be
found in the following chapters.
<X.400 routing coordination document set> ::= \ <X.400 routing coordination document set> ::= \
<COMMUNITY-document> \ <COMMUNITY-document> \
{ <WEP-document> } \ { <RELAY-MTA-document> } \
{ <DOMAIN-document> } \ { <DOMAIN-document> } \
{ <PERSON-document> } { <PERSON-document> }
A set of one COMMUNITY document and several WEP, DOMAIN
and PERSON documents belong together. 5.1 Common Definitions
<DirectoryName> ::= 'Distinguished Name' <DirectoryName> ::= 'Distinguished Name'
The string representation of a Distinguished Name is The string representation of a Distinguished Name is
defined in the IETF OSI-DS document 23. It is still an defined in the RFCxxxx. If a Distinguished Name is
Internet Draft, but the latest version is very likely used as a key in the documents, then the information
to be accepted at the Nov '92 IETF meeting. If a can be fetched from the directory instead of checking
Distinguished Name is used as a key in the documents, the appropriate document. But as long as not all
then the information can be fetched from the directory managers in the same community have directory access,
instead of checking the appropriate document. However the same information must also be present in a
the same information must also be present in a document document. Note that Distinguished Names in the context
as long as not all managers in the same community have of the routing documents are just used as key strings
directory access. to point to other documents.
<Community-Identifier> ::= "Community: " \ <Community-Identifier> ::= "Community: " \
('community name' | <DirectoryName>) 'CR' ('community name' | <DirectoryName>) <CR>
The 'community name' is a string identifying the MHS The 'community name' is a string identifying the MHS
community to be used in the first line of all community to be used in the first line of all
documents. documents.
<UniqueWEPkey> ::= ([ "P=" 'PRMDname' "; " ] \ <UniqueRELAY-MTAkey> ::= (([ "P=" 'PRMDname' "; " ] \
["A=" 'ADMDname' "; " ] \ ["A=" 'ADMDname' "; " ] \
"C=" <Country-Code> "; " \ "C=" <Country-Code> "; " \
"MTAname=" 'MTAname' "MTAname=" 'MTAname')
| <DirectoryName> ) | <DirectoryName> )
A unique key is needed to identify the WEP. In addition A unique key is needed to identify the RELAY-MTA. In
to the MTA name itself, it is proposed to use OR addition to the MTA name itself, it is proposed to use
address attributes of the management domain where the OR address attributes of the management domain where
WEP resides. ADMD and PRMD fields are both optional and the RELAY-MTA resides. ADMD and PRMD fields are both
may be used to guarantee uniqueness of the key. The optional and may be used to guarantee uniqueness of the
values used are irrelevant. Even non-printable key. The values used are irrelevant. Even non-
characters like @ or ! are acceptable. The result is printable characters like @ or ! are acceptable. The
not an address but a key string. A Distinguished Name result is not an address but a key string. A
may be used instead. Distinguished Name may be used instead.
<UniquePersonKey> ::= (<X.400 address> | <DirectoryName> ) <UniquePersonKey> ::= (<X.400 address> | <DirectoryName> )
A unique key is needed to make the links from the A unique key is necessary to make the links from the
documents where a responsible person or an documents where a responsible person or an
administrator is needed to the PERSON documents. It is administrator is needed, to the PERSON documents. It
either the OR address of the person or a Distinguished is either the OR address of the person or a
Name (if the person is already registered in the Distinguished Name (if the person is already registered
directory). in the directory).
<Country-Code> ::= 'Two Character Country Code ISO-3166' <Country-Code> ::= 'Two Character Country Code ISO-3166'
Eppenberger Expires: May 1993 [Page 7]
<X.400 address> ::= 'OR address, ISO 10021-2 Annex F' <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. It has been used consequently all over the document.
This explains also the syntax of the <UniqueWEPkey> and This explains also the syntax of the
the <MHS-subtree>. <UniqueRELAY-MTAkey> and the <MHS-subtree>. 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;
<EMail> ::= "Address: " <X.400 address> 'CR' <EMail> ::= "Address: " <X.400 address> <CR>
<tel-no-list> ::= <tel-number> [{"; " <tel-number>}] <tel-no-list> ::= <tel-number> [{"; " <tel-number>}]
<tel-number> ::= {"+" <int-pref> " " [<area> " "] \ <tel-number> ::= {"+" <int-pref> " " <national number> \
<local-tel-no>} [" x" <extension>]}
This syntax follows the attribute syntax of the X.500
directory based on CCITT E.123.
<int-pref> ::= 'international prefix' <int-pref> ::= 'international prefix'
<area> ::= 'area code' <national number> ::= 'national telephone number'
A national number may be written with spaces and
hyphens to group the figures.
<local-tel-no> ::= 'local telefone number' <extension> ::= 'local extension'
<Phone> ::= "Phone: " <tel-no-list> 'CR' <Phone> ::= "Phone: " <tel-no-list> <CR>
One or more phone numbers One or more phone numbers
<Fax> ::= "Fax: " <tel-no-list> 'CR' <Fax> ::= "Fax: " <tel-no-list> <CR>
One or more FAX numbers One or more FAX numbers
<Mail> ::= "Mail: " 'postal address information' 'CR' <Mail> ::= "Mail: " 'postal address information' <CR>
The items of the postal address are separated by '/' The items of the postal address are separated by ' /'
wherever the next item goes onto the next line for a wherever the next item goes onto the next line for a
printed address label. Especially if the community printed address label. If the document is for an
spans several countries it does make sense to give the international community, the address should include the
full address including the country. person's country.
Example: Example:
Mail: SWITCH Head Office/Urs Eppenberger/ Mail: SWITCH Head Office / Urs Eppenberger /
Limmatquai 138/CH-8001 Zurich/Switzerland Limmatquai 138 / CH-8001 Zurich / Switzerland
results in the following mailing label: results in the following mailing label:
SWITCH Head Office SWITCH Head Office
Urs Eppenberger Urs Eppenberger
Limmatquai 138 Limmatquai 138
CH-8001 Zurich CH-8001 Zurich
Switzerland Switzerland
<Update-info> ::= "Update: DATE=" 'yymmdd' \ <Update-info> ::= "Update: FORMAT=V3; DATE=" 'yymmdd' \
["; START=" 'yymmdd'] \ "; START=" 'yymmdd' \
["; END=" 'yymmdd'] 'CR' ["; END=" 'yymmdd'] <CR>
The <Update-info> contains also the format identifier.
The date of the last update of a document is given in The date of the last update of a document is given in
the form 'yymmdd'. the form 'yymmdd'.
An optional start date can be set. A document can be A start date must be set. A document can be published
published this way before the information in it is this way before the information in it is valid. (This
valid. (This is especially useful in absence of is especially useful in absence of automated tools.
automated tools. WEP managers get more time to prepare RELAY-MTA managers get more time to prepare their
their systems.) systems.)
An end date is used to set an expiration date for the An end date is used to set an expiration date for the
document. document.
Eppenberger Expires: May 1993 [Page 8]
<P-address> ::= 'String encoded Presentation Address' <P-address> ::= 'String encoded Presentation Address'
The format of this string follows RFC1278, A string The format of this string follows RFC1278, A string
encoding of Presentation Address and RFC1277, Encoding encoding of Presentation Address and RFC1277, Encoding
Network Addresses to support operation over non-OSI Network Addresses to support operation over non-OSI
layers. See chapter 5.2 about the usage of macros in a layers. See chapter 5.2 about the usage of macros in a
Presentation Address. Presentation Address.
<Service-type> ::= <Network-name> "/" \ <Service-type> ::= <Network-name> "/" \
<Network-service> "/" \ <Network-service> "/" \
<Transport-Protocol> <Transport-Protocol>
The service type consists of a string with three parts
concatenated with a "/": Network-name/Network-
service/Transport-Protocol.
<Network-name> ::= 'Name of a network' <Network-name> ::= 'Name of a network'
The network-name string identifies a network. A well The network-name string identifies a network. A well
known key word should be choosen. (No '/' character is known key word should be chosen. (No '/' character is
allowed.) allowed.)
Examples: Public-X.25, Internet, RARE-IXI, RARE-CLNS, Examples: Public-X.25, Internet, EMPB-X.25, Int-CLNS,
WIN, WIN, Janet,
<Network-service> ::= "X.25" | "CONS" | "CLNS" | "TCP" <Network-service> ::= 'Name of a network service'
One of the four values identifies the 'network service' Examples: X.25, CONS, CLNS, TCP
used. (TCP is considered a network service together
with RFC1006)
<Transport-Protocol> ::= "TP0" | "TP2" | "TP4" | "RFC1006" <Transport-Protocol> ::= 'Name of a transport protocol'
Examples: TP0, TP2, TP4, RFC1006
The service type consists of a string with three parts
concatenated with a "/": Network-name/Network-
service/Transport-Protocol.
Since network and stack information forms one string, Since network and stack information forms one string,
it identifies in an easy way a connection possibility it identifies in an easy way a connection possibility
between two WEPs. The COMMUNITY document defines the between two RELAY-MTAs. The COMMUNITY document defines
strings to be used in the WEP and DOMAIN documents. the strings to be used in the RELAY-MTA and DOMAIN
Some examples: documents. Some examples:
Internet/TCP/RFC1006 Internet/TCP/RFC1006
Public-X.25/X.25/TP0 Public-X.25/X.25/TP0
RARE-IXI/CONS/TP0 RARE-IXI/CONS/TP0
RARE-CLNS/CLNS/TP4 RARE-CLNS/CLNS/TP4
(It is probably important to mention here that this (It is probably important to mention here that this
string has nothing to do with the format of a string has nothing to do with the format of a
presentation address as defined by Steve Hardcastle- presentation address as defined by Steve Hardcastle-
Kille in RFC1278. The problem of networks using the Kille in RFC1278. The problem of networks using the
same address structure (X.121 DTEs, 4 Byte Internet same address structure (X.121 DTEs, 4 Byte Internet
addresses) but not beeing connected is not addressed in addresses) but not being connected is not addressed in
RFC1278 but solved by using the proposed service RFC1278 but solved by using the proposed service
identifier above in addition to the presentation identifier above in addition to the presentation
address. As long as there are network islands, there is address. As long as there are network islands, there
no other way than the addition of an 'island'- is no other way than the addition of an 'island'-
identifier. As soon as all systems have an NSAP and are identifier.
connected to a global OSI network, this problem will
disappear.)
Eppenberger Expires: May 1993 [Page 9] <MHS-subtree> ::= ["O=" 'Organization-name' "; "] \
<MHS-subtree> ::= ["OU4=" 'OrganizationalUnit-name' "; "] \ ["OU1="'OrganizationalUnit'"; "\
["OU3=" 'OrganizationalUnit-name' "; "] \ ["OU2=" 'OrganizationalUnit' "; " \
["OU2=" 'OrganizationalUnit-name' "; "] \ ["OU3=" 'OrganizationalUnit' "; " \
["OU1=" 'OrganizationalUnit-name' "; "] \ ["OU4=" 'OrganizationalUnit' "; "]]]] \
["O=" 'Organization-name' "; "] \
["P=" 'PRMDname' "; "] \ ["P=" 'PRMDname' "; "] \
"A=" 'ADMDname' "; " \ "A=" 'ADMDname' "; " \
"C=" <Country-Code> ";" "C=" <Country-Code> ";"
5.2 The COMMUNITY document <Operation> ::= "Reachable: " {<time> "-" <time> "; "} \
<Time-zone> <CR>
<time> ::= 'hh:mm'
<Time-zone> ::= ("UTC+" | "UTC-") 'hhmm'
The operation information is needed to know the time
someone is reachable. This information is important
for communities spanning several time zones.
'hhmm' is a four digit value, the first two digits
indicate hours, the second two digits indicate minutes.
Use "UTC+" for time zones east of Greenwich. A simple
formula helps to calculate the current time at the
remote place:
local-time - local-displacement + remote-displacement =
remote-time
18:00 - (UTC + 0100) + (UTC - 0800) = 09:00
The <Time-zone> entry may be followed by a comment line
indicating when Daylight Saving Time is in effect.
This is especially reasonable for MHS communities
spanning continents on the northern and southern
hemisphere.
5.2 The COMMUNITY document
<COMMUNITY-document> ::= <Community-Identifier> \ <COMMUNITY-document> ::= <Community-Identifier> \
<Update-info> \ <Update-info> \
<COMMUNITY-document-body> <COMMUNITY-document-body>
The first line of the COMMUNITY document specifies the The first line of the COMMUNITY document specifies the
<Community-Identifier> to be used in the header of all <Community-Identifier> to be used in the header of all
other documents belonging to the same community. It is other documents belonging to the same community. It is
recommended to add a few comment lines to describe the recommended to add a few comment lines to describe the
members of this MHS community. members of this MHS community.
<COMMUNITY-document-body> ::= <Coordination> \ <COMMUNITY-document-body> ::= <Coordination> \
{<Macro-definition>}{<Connections>} [{<Macro-definition>}] \
{<Connections>}
<Coordination> ::= <EMail> <Phone> <FAX> \ <Coordination> ::= <EMail> <Phone> <FAX> \
<Mail> <File-server> <Mail> <Operation> <File-server>
Set of contact information for the coordination point Set of contact information for the coordination point
<File-server> ::= <email-server> [{<FTP-server>}] \ <File-server> ::= <email-server> [{<FTP-server>}] \
[{<FTAM-server>]} [{<FTAM-server>}]
All documents must be available at least to the All documents must be available at least to the
managers of the MHS domains and the WEPs through an managers of the MHS domains and the RELAY-MTAs through
email server. If FTAM and FTP are also available, the an email server. If FTAM and FTP are also available,
generation of automated update tools is much easier. the generation of automated update tools is much
It is suggested to have a single server. If there is easier.
It is suggested to have a single server. If there is
only one, knowing a single X.400 OR address will allow only one, knowing a single X.400 OR address will allow
you to reach the server. However for FTP and FTAM more you to reach the server. However for FTP and FTAM more
system addresses may be possible depending on the system addresses may be possible depending on the
number of available network connections (or service number of available network connections (or service
types as they are called in this document). types as they are called in this document).
<email-server> ::= "Mail-server: "<X.400 address> 'CR' <email-server> ::= "Mail-server: "<X.400 address> <CR>
The email address of the file server. The email address of the file server.
<FTP-server> ::= "FTP-server: " 'domain name' "; " <FTP-server> ::= "FTP-server: " 'domain name' "; " \
'account-name' ["; " 'password'] 'CR' 'account-name' ["; " 'password'] <CR>
In addition to the domain name of the server, an In addition to the domain name of the server, an
account name and a password is given. In most cases account name and a password is given. In most cases
this will probably be something like "anonymous" and this will probably be something like "anonymous" and
"guest". "guest".
Some servers request the RFC822 address of the user.
This is documented by using the string 'user@domain' as
password entry. The meaning is not to use
'user@domain' literally as password while accessing the
server (even if this would generally work too since the
software often just checks the presence of an @ sign,)
but to use ones own RFC822 email address.
<FTAM-server> ::= "FTAM-server: " \ <FTAM-server> ::= "FTAM-server: " <P-address> "; "\
('P-address' | <DirectoryName>) "; " \ 'account-name' ["; " 'password'] \
<account-name> ["; " 'password'] 'CR' ["; X.500 " <DirectoryName>] <CR>
The account name is often case sensitive. Some FTAM The account name is often case sensitive. Some FTAM
server offer anonymous access with the account-name servers offer anonymous access with the account-name
ANON. Documenting a FTAM server with a Distinguished ANON. Documenting an FTAM server with a Distinguished
Name is only allowed if the server is registered in the Name is only allowed if the server is registered in the
directory. directory.
<Macro-definition> ::= "Macro: " 'Macro name' " " \ <Macro-definition> ::= "Macro: " 'Macro name' " " \
'Macro value' 'CR' 'Macro value' <CR>
Presentation addresses without the usage of macros are Presentation addresses without the usage of macros are
generally unreadable. RFC1278 suggests a few macros. generally unreadable. RFC1278 suggests a few macros.
All macros which are allowed in a communities must be All macros which are allowed in a community must be
defined in the community document. It is recommended to defined in the COMMUNITY document. It is recommended
use the proposed macros in RFC1278 and add new ones if to use the proposed macros in RFC1278 and add new ones
necessary: if necessary:
Macro: Int-X25(80) TELEX+00728722+X25(80)+01+ Macro: Int-X25(80) TELEX+00728722+X.25(80)+01+
Macro: Janet-X25(80) TELEX+00728722+X25(80)+02+ Macro: Janet-X25(80) TELEX+00728722+X.25(80)+02+
Macro: Internet-RFC-1006 TELEX+00728722+RFC-1006+03+ Macro: Internet-RFC-1006 TELEX+00728722+RFC-1006+03+
<Connections> ::= {<mandatory-service>} \ <Connections> ::= {<mandatory-service>} \
{[<optional-service>]} {[<optional-service>]}
At least one service type is mandatory. Note that at least one mandatory service type is
needed.
<mandatory-service> ::= "Mandatory-Service: " \ <mandatory-service> ::= "Mandatory-Service: " \
<Service-type> 'CR' <Service-type> <CR>
<optional-service> ::= "Optional-Service: " \ <optional-service> ::= "Optional-Service: " \
<Service-type> 'CR' <Service-type> <CR>
5.3 The WEP document 5.3 The RELAY-MTA document
<WEP-document> ::= <Community-Identifier> \ <RELAY-MTA-document> ::= <Community-Identifier> \
<Update-info> \ <Update-info> \
<WEP-document-Identifier> \ <RELAY-MTA-document-Identifier> \
<WEP-document-body> <RELAY-MTA-document-body>
A WEP document contains the full description of a A RELAY-MTA document contains the full description of a
single WEP. Only one community is allowed. Since some single RELAY-MTA. Only one community is allowed.
of the information is community dependent, it would not Since some of the information is community dependent,
be easily possible to have a single WEP document used it would not be easily possible to have a single
in different communities. RELAY-MTA document used in different communities.
<WEP-document-Identifier> ::= "WEP: <UniqueWEPkey> 'CR' <RELAY-MTA-document-Identifier> ::= \
"RELAY-MTA: " <UniqueRELAY-MTAkey> <CR>
<WEP-document-body> ::= <Status> <connection-info> \ <RELAY-MTA-document-body> ::= <Status> <connection-info> \
<contact-info> <contact-info>
<Status> ::= "Status: " ("primary" | "secondary") <Status> ::= "Status: " ("primary" | "secondary") <CR>
This defines if the WEP has 'primary' or 'secondary' This defines if the RELAY-MTA has 'primary' or
status. See section 4.3 and 6 for more information. 'secondary' status. See section 4.3 and 6 for more
information.
<connection-info> ::= <password> <RTS> \ <connection-info> ::= <password> <RTS> \
{<called-connection><calling-connection>} {<called-connection><calling-connection>}\
\
[<system>] \ [<system>] \
[<local-domain>] \ [<local-domain>] \
[<echo-server>] [<echo-server>]
More than one set of connection information may be More than one set of connection information may be
present for WEPs supporting several networks and present for RELAY-MTAs supporting several networks and
protocol stacks. protocol stacks.
<password> ::= "Password: " \ <password> ::= "Password: " \
("***secret***" | "***none***" | ("secret" | "none" | \
'password') 'CR' "value=\"" 'password' "\"") <CR>
If the keyword ***none*** is present, then no password If the keyword none is present, then no password is
is used. sent with the MTAname when this MTA initiates an RTS
If the keyword ***secret*** is present, then the connection or responds to an incoming connection.
connection needs a password which is not made publicly Password: none
available. The community might for example decide to
keep a list of the passwords at the central If the keyword secret is present, then the connection
coordination point. The list is then faxed to the WEP needs a password which is not made publicly available.
managers. (For example, a community might keep a list of the
If any other string is present, then this is the passwords at the central coordination point. The list
password to be used for the connection. would then be faxed to the RELAY-MTA managers.)
Password: secret
A password must be documented using the
value="password" notation. The double quotes around
the password are needed, consider the case of a single
blank as a password.
Password: value=" "
Password: value="nume-n-ine"
<RTS> ::= <dialog-mode> \ <RTS> ::= <dialog-mode> \
[<checkpoint-size> <window-size>] [<checkpoint-size> <window-size>]
<dialog-mode> ::= "RTS-dialog-mode: " \ <dialog-mode> ::= "RTS-dialog-mode: " \
("TWA" | "MONOLOGUE") 'CR' ("TWA" | "MONOLOGUE") <CR>
<ckeckpoint-size> ::= "RTS-checkpoint-size: " \ <checkpoint-size> ::= "RTS-checkpoint-size: " \
'checkpoint size' 'CR' 'checkpoint size' <CR>
<window-size> ::= "RTS-window-size: " \ <window-size> ::= "RTS-window-size: " \
'window size' 'CR' 'window size' <CR>
<called-connection> ::= "Called-address: " \ <called-connection> ::= "Called-address: " \
<Service-type> "; " \ <Service-type> "; " \
<P-address> "; " <MTS> 'CR' <P-address> "; " <MTS> \
["; " <Service-priority>] <CR>
<MTS> ::= "MTS-T" | "MTS-TP" | "MTS-TP-84" <MTS> ::= "MTS-T" | "MTS-TP" | "MTS-TP-84"
MTS-T: mts-transfer MTS-T: mts-transfer
MTS-TP: mts-transfer-protocol MTS-TP: mts-transfer-protocol
MTS-TP-84: mts-transfer-protocol-1984 MTS-TP-84: mts-transfer-protocol-1984
See ISO 10021-6, Section 3, chapter 11.1 for more See ISO 10021-6, Section 3, chapter 11.1 for more
details on this matter. X.400(84) systems only support details on this matter. X.400(84) systems only support
mts-transfer-protocol-1984. mts-transfer-protocol-1984.
<Service-priority> ::= 'Integer 0..99'
The lowest Integer corresponds to the highest priority
as in DNS. It is possible to set different priorities
for each service type. This may be chosen, for
example, to distribute the load amongst different
networks according to their available bandwidth.
<calling-connection> ::= "Calling-address: " \ <calling-connection> ::= "Calling-address: " \
<Service-type> "; " \ <Service-type> "; " \
<P-address> 'CR' <P-address> <CR>
Since called and calling network addresses may differ Since called and calling network addresses may differ
in certain configurations and some X.400 systems do in certain configurations and some X.400 systems do
validation on calling network addresses, it is validation on calling network addresses, it is
important to have this information in the WEP document. important to have this information in the RELAY-MTA
(Note: a calling X.121 address might change if the X.25 document. (Note: a calling X.121 address might change
switch is reconfigured. This will stop a WEP from if the X.25 switch is reconfigured. This will stop a
connecting to other WEPs using address validation RELAY-MTA from connecting to other RELAY-MTAs using
without having changed anything at the higher layers!) address validation without having changed anything at
the higher layers!)
<system> ::= "System: COM=" 'computer type' "; " \ <system> ::= "System: HW=" 'computer type' "; " \
"OPS=" 'operating system' "; " \ "OS=" 'operating system' "; " \
"MHS=" 'MHS software' 'CR' "SW=" 'MHS software' <CR>
It is optional to provide HW/SW information. It is optional to provide HW/SW information.
Experience,however, has shown that a number of Experience, however, has shown that a number of
communication problems were more easily identified and communication problems were more easily identified and
solved with this information present and up-to-date. solved with this information present and up-to-date.
<local-domain> ::= "LocalDomain: " <MHS-subtree> 'CR' <local-domain> ::= "LocalDomain: " <MHS-subtree> <CR>
This is a useful but optional extension to the This is a useful but optional extension to the
documentation. Such an address should be routed through documentation.
the WEP or even end up on the WEP. This is not a The <MHS-subtree> is local to the RELAY-MTA. The <MHS-
routing definition! The LocalDomain attributes might be subtree> attributes might be used together with
used together with S=nosuchuser to do connectivity and S=nosuchuser; to do connectivity and availability
availability tests. tests.
<echo-server> ::= "EchoServer: " <X.400 address> 'CR' <echo-server> ::= "EchoServer: " <X.400 address> <CR>
Some of the WEPs might offer an echo server Some of the RELAY-MTAs might offer an echo server
functionality. It does make sense to document this in functionality. It does make sense to document this in
the WEP document for test purpose. This field is the RELAY-MTA document for test purpose. This field is
optional. optional.
<contact-info> ::= {"Administrator: " <UniquePersonKey> 'CR'} <contact-info> ::= {"Administrator: " <UniquePersonKey> <CR>}
The contact details for the WEP administrator can be The contact details for the RELAY-MTA administrator can
found in the appropriate PERSON document. It is be found in the appropriate PERSON document. It is
possible to document a whole team using a distribution possible to document a whole team using a distribution
list if this is desired. It is generally better to list if this is desired. It is generally better to
document one or more 'real' persons. document one or more 'real' persons.
5.4 The DOMAIN document 5.4 The DOMAIN document
<DOMAIN-document> ::= <Community-Identifier> \ <DOMAIN-document> ::= <Community-Identifier> \
<Update-info> \ <Update-info> \
<DOMAIN-document-body> <DOMAIN-document-body>
<DOMAIN-document-body>::= {<Domain-entry>} <responsible> \ <DOMAIN-document-body>::= {<Domain-entry>} <responsible> \
{<relay-WEP>} {<Relay>}
<Domain-entry> ::= "Domain: " <OR-matching> <MHS-subtree> <CR>
Note that it is not allowed to have equal <Domain-
entry> lines in different DOMAIN documents belonging to
the same MHS community. A Domain-entry line can only
appear in one DOMAIN document.
<Domain-entry> ::= "Domain: " <OR-matching> <MHS-subtree> 'CR'
<OR-matching> ::= ( "* " | "= " ) <OR-matching> ::= ( "* " | "= " )
This qualifier defines how the following OR address This qualifier defines how the following OR address
attributes should be handled for the routing algorithm. attributes should be handled for the routing algorithm.
If a '*' is present, a destination address of a message If a '*' is present, a destination address of a message
is matched by the "Domain:" entry if at least the OR is matched by the "Domain:" entry if at least the OR
address attributes in the "Domain:" entry are equal to address attributes in the "Domain:" entry are equal to
the destination address. the destination address.
If a "=" is present, a destination address of a message If a "=" is present, a destination address of a message
is matched by the "Domain:" entry if there are exactly is matched by the "Domain:" entry if there are exactly
the same OR attributes in the destination address as in the same OR attributes in the destination address as in
the "Domain:" entry. (This restriction works for OU*, the "Domain:" entry. (This restriction works for OU4,
O, P, A and C only.) OU3, OU2, OU1, O, P, A and C only.)
Example: Example:
a) Domain: * P=switch; A=arcom; C=ch; a) Domain: * P=switch; A=arcom; C=ch;
b) 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; The address S=eppenberger; P=switch; A=arcom; C=ch;
matches both cases, a) and b). matches both cases, a) and b).
The address S=eppenberger; O=unibe; P=switch; A=arcom; The address S=eppenberger; O=unibe; P=switch; A=arcom;
C=ch; matches only case a). C=ch; matches only case a).
Note that it is not allowed to have equal <MHS-subtree> <responsible> ::= {"Administrator: " <UniquePersonKey> <CR>}
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. This is the person responsible for the listed domains.
His task is to get the agreement of the relaying WEPs His task is to get the agreement of the relaying
and keep the DOMAIN document up-to-date. This person is RELAY-MTAs and keep the DOMAIN document up-to-date.
the only one authorized to make changes to this This person is the only one authorized to make changes
document. to this document. Note that multiple administrators
may be listed.
<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> <Relay> ::= "Relay: " \
( 'UniqueRELAY-MTAkey' | \
"Internet-SMTP" ) "; " \
<RELAY-MTA-Priority> <CR>
The priority is used to define the sequence in which
different RELAY-MTAs may be tried in case of failure.
A lower integer corresponds to a higher priority as in
DNS. Priorities 0..49 are used to indicate backup
RELAY-MTAs. Priorities 50..99 are used for RELAY-MTAs
not acting as backup but as relay service provider for
a network service type not supported by the main
RELAY-MTA.
The keyword "Internet-SMTP" is a placeholder for an
RFC1327 gateway connected to Internet. The RELAY-MTA
manager selects a gateway of his choice.
<Priority> ::= <Number 0..infinite> <RELAY-MTA-Priority> ::= <Integer 0..99>
<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 5.5 The PERSON document
<PERSON-document> ::= <Community-Identifier> \ <PERSON-document> ::= <Community-Identifier> \
<Update-info> \ <Update-info> \
<PERSON-document-identifier> \ <PERSON-document-identifier> \
<PERSON-document-body> <PERSON-document-body>
<PERSON-document-identifier> ::= "Key: " <UniquePersonKey> 'CR' <PERSON-document-identifier> ::= "Key: " <UniquePersonKey> <CR>
<PERSON-document-body>::= <Name> {<EMail>} {<RFC822>} \ <PERSON-document-body>::= <Name> {<EMail>} {<RFC822>} \
<Phone> <Fax> <Mail> <Operation> <Phone> <Fax> <Mail> <Operation>
<Name> ::= "Name: " 'name of person' 'CR' <Name> ::= "Name: " 'name of person' <CR>
The name of the person is given. The issue of the The name of the person is given. The issue of the
character set problem is not addressed in this character set problem is not addressed in this
document. Especially international communities should document. Especially international communities should
restrict themselves to IA5. restrict themselves to IA5 or ASCII.
<RFC822> ::= "RFC822: " <RFC-822-address> 'CR' <RFC822> ::= "RFC822: " <RFC-822-address> <CR>
This is the RFC-822 address of the person. It is often This is the RFC-822 address of the person. It is often
a big help to know the RFC822 address of someone, for a big help to know the RFC822 address of someone, for
example if the X.400 system is not reachable. This is example if the X.400 system is not reachable. This is
also the reason why it is possible to provide multiple also the reason why it is possible to provide multiple
OR and RFC822 addresses. The first one is considered OR and RFC822 addresses. The first one is considered
the primary one. the primary one.
<Operation> ::= "Reachable: " {<time> "-" <time> "; "} \ 6. Routing rules
<Time-zone>
<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.
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
community.
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
allowed.
** 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 All the users within the MHS community have the right to send
one MHS domain to another of the same community are replyable. messages to each other. The general agreement is that the RELAY-MTA
infrastructure is used according to the following routing rules.
More direct connections based on bilateral agreements are fully
accepted.
** 4 ** A primary or secondary RELAY-MTA must allow incoming connections from
all other primary and secondary RELAY-MTAs with a common stack.
Primary RELAY-MTAs must be able to connect to all other primary
RELAY-MTAs which share a common stack. A secondary RELAY-MTA must
connect to at least one primary RELAY-MTA.
A message arriving at a WEP must either be sent to the next WEP A message arriving at a RELAY-MTA must either be sent to the next
based on the DOMAIN documents of the MHS community or it is sent to RELAY-MTA based on the DOMAIN documents of the MHS community or it is
an MTA closer to the destination based on local know-how. The sent to an MTA closer to the destination based on local routing
following algorithm must be used when relaying a message to the next decisions. The following algorithm must be used when forwarding a
WEP: message to the next RELAY-MTA:
1 Match the Recipient address in the message with the longest 1) Select the relevant DOMAIN document by searching for a match of
fitting MHS subtree from the DOMAIN documents. (The value on the the Recipient address in the message with the entries in the
line starting with the key "Domain:".) Also get the list of WEPs document.
relaying to this MHS subtree.
If your own WEP appears in this list, this indicates one of the If your own RELAY-MTA appears in this list, this indicates one of
following: the following:
- You offered relay services for another WEP with higher priority. - You offered relay services for another RELAY-MTA with higher
Continue with step 2 to decide on the next WEP. priority. Continue with step 2 to decide on the next RELAY-MTA.
- Your WEP is the final destination according the DOMAIN document - Your RELAY-MTA is the final destination according the DOMAIN
of your community. You need to forward the message to the final document of your community. You need to forward the message to
destination according local routing information. the final destination according local routing information.
2 From the list of WEPs for the obtained MHS subtree select those 2) From the list of RELAY-MTAs select those that have at least one
that can be reached directly. (Based on the information in the WEP common network service type with your own RELAY-MTA.
documents beginning with "Called:".)
3 Now decide if you want to send to secondary WEPs too. If you 3) Now delete all secondary RELAY-MTAs from the list where no
decide to use primary WEPs only for your routing, then delete all direct connection is desired. For remaining RELAY-MTAs in the
secondary WEPs from the list. list no difference is made anymore between primary and secondary
status.
4 Select from this reduced set of WEPs the one with the highest 4) Select from this reduced set of RELAY-MTAs the one with the
default priority. If there is more than one WEP having the same highest RELAY-MTA-priority. If there is more than one RELAY-MTA
priority, then select a WEP at random. If your own WEP appears in having the same priority, then select a RELAY-MTA of your choice.
that list then you are not allowed to send to a WEP with lower or If your own RELAY-MTA appears in that list, then you are not
equal priority. allowed to send to a RELAY-MTA with lower or equal priority.
5 If there are no other lines indicating which service type to use, 5) If there are no service-priorities set in the corresponding
you are free to choose the service type for connecting to the WEP. RELAY-MTA document indicating which service type to use, you are
However, if there are specific priorities set then select the free to choose the service type for connecting to the RELAY-MTA.
network with the highest priority. However, if there are specific priorities set then select the
service type with the highest priority.
6 If the connection fails then try other connections in the sequence 6) If the connection fails then try other service types in the
of descending priority. sequence of descending priority.
7 If no connection works for the selected WEP, then check in the 7) If no connection works for the selected RELAY-MTA, then check
list for the one with the same priority, if possible, or else in the list for the one with the same priority, if possible, or
select one with the next lower priority. Retry establishing the else select one with the next lower priority. If there is another
connection to the first WEP until the number of minutes indicated RELAY-MTA with a RELAY-MTA-priority between 0..49, then select it
in the delay field for the second WEP has passed, then switch to and proceed at step 5. Without another RELAY-MTA to try the
the second WEP. Go to step 5 to proceed with the selection of the currently selected RELAY-MTA will be retried.
connection type.
6.1 How to use priorities 6.1 How to use RELAY-MTA-priorities
An example helps to explain the usage of priorities. An example helps to explain the usage of RELAY-MTA-priorities.
Internet/TCP/RFC1006 and Public-X.25/X.25/TP0 are mandatory Internet/TCP/RFC1006 and Public-X.25/X.25/TP0 are mandatory service
service types in the community REMOTEmail. The MHS domain types in the community REMOTEmail. The MHS domain P=REMOTE; A=ARCOM;
C=CH;ADMD=ARCOM;PRMD=REMOTE operates WEP-B, only connected to C=CH; operates MTA-B, only connected to public X.25. A second
public X.25. A second WEP which is connected to both, Internet and RELAY-MTA which is connected to both, Internet and public X.25 is
public X.25 is needed to offer relay services. A connection using needed to offer relay services. A connection using Internet is
Internet is considered cheap, somebody else pays the leased lines. considered cheap in this example. Both service types are available
Both service types are available at WEP-A. Since WEP-B is the only at MTA-A. Since MTA-B is the only RELAY-MTA responsible for relaying
WEP responsible for relaying messages to messages to P=REMOTE; A=ARCOM; C=CH; to the final destination it must
C=CH;ADMD=ARCOM;PRMD=REMOTE to the final destination it must have have the highest priority.
the highest prioriy.
Community: REMOTEmail Community: REMOTEmail
Domain: C=CH;ADMD=ARCOM;PRMD=REMOTE Domain: * P=REMOTE; A=ARCOM; C=CH;
WEP: C=CH;ADMD=ARCOM;PRMD=REMOTE;MTAname=WEP-B; 9; 0 RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-B; 20
WEP: C=CH;ADMD=ARCOM;PRMD=RELAYX;MTAname=WEP-C; 5; 120 RELAY-MTA: P=MTA-C; A=ARCOM; C=CH;MTAname=MTA-C; 80
___________________________ __________________________
+-------+ X.25 +-------+ ( ) +-------+ X.25 +-------+ ( )
| WEP A +-------------+ WEP B +-(C=CH;ADMD=ARCOM;PRMD=REMOTE) | MTA-A +-------------+ MTA-B +-( P=REMOTE; A=ARCOM; C=CH; )
+-------+ +-------+ (___________________________) +-------+ +-------+ (__________________________)
\ / \ /
TCP/IP \ /X.25 TCP/IP \ /X.25
+-------+ +-------+
| WEP-C | | MTA-C |
+-------+ +-------+
WEP-A needs to relay a message for C=CH;ADMD=ARCOM;PRMD=REMOTE. If MTA-A needs to relay a message for P=REMOTE; A=ARCOM; C=CH; then
Rule **4** is evaluated step by step: the rules of chapter 6 are evaluated:
1 WEP-B and WEP-C are possible destinations 1. MTA-B and MTA-C are possible destinations
2 WEP-B and WEP-C are reachable from WEP-A 2. MTA-B and MTA-C are reachable from MTA-A
3 WEP-B is a primary WEP (not relevant in this example) 3. MTA-B is a primary RELAY-MTA (not relevant in this example)
4 WEP-B has the highest priority. 4. MTA-B has the highest priority.
5 WEP-B doesn't have specific service type lines documented. 5. MTA-B doesn't have specific service type lines documented.
WEP-A chooses public X.25, since it is the only possibility MTA-A chooses public X.25, since it is the only possibility
to connect to WEP-B. to connect to MTA-B.
The organization running WEP-A could save money by sending 6. No other service types are available if the connection
messages for the MHS domain C=CH;ADMD=ARCOM;PRMD=REMOTE via WEP-C. fails.
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 7. MTA-C has a priority of 80, it is not a backup RELAY-MTA.
avoided wherever possible by offering WEPs with equal priority for MTA-A must spool the message and try to connect directly to
all mandatory network services. This can be an important financial MTA-B.
issue for MHS communities spanning several organisations, it is
not relevant in general for an MHS community within a single
organisation.
6.2 How to use delays The organisation running MTA-A could save money by sending messages
for the MHS domain P=REMOTE; A=ARCOM; C=CH; via MTA-C. Since the
connection between MTA-C and the destination MTA-B is also expensive,
the organisation running MTA-C would have to pay for external relay
traffic. Setting a lower priority for MTA-C forces the other RELAY-
MTAs with public X.25 connectivity to take their share of the cost.
Two WEPs offer real backup connectivity for the MHS domain Note that forcing other RELAY-MTAs to use a specific stack should be
C=CH;ADMD=ARCOM;PRMD=REMOTE. It is therefore possible to set the avoided wherever possible by offering RELAY-MTAs with equal priority
delay to zero for both WEPs. WEP-B will be the preferred one since for all mandatory network services. This can be an important
it has the higher priority. If the connection to WEP-B fails, a financial issue for MHS communities spanning several organisations,
sending WEP may immediately try to connect to WEP-C. it is not relevant in general for an MHS community within a single
organisation.
6.2 How to use RELAY-MTA-priorities for backup RELAY-MTAS
Two RELAY-MTAs offer real backup connectivity for the MHS domain
P=REMOTE; A=ARCOM; C=CH;. It is therefore possible to set RELAY-MTA
priorities in the range of 0..49 for both RELAY-MTAs. MTA-B will be
the preferred one since it has the higher priority. If the
connection to MTA-B fails, a sending RELAY-MTA may immediately try to
connect to MTA-C.
Community: REMOTEmail Community: REMOTEmail
Domain: C=CH;ADMD=ARCOM;PRMD=REMOTE Domain: * P=REMOTE; A=ARCOM; C=CH;
WEP: C=CH;ADMD=ARCOM;PRMD=SWITCH;MTAname=WEP-B; 9; 0 RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-B; 10
WEP: C=CH;ADMD=ARCOM;PRMD=SWITCH;MTAname=WEP-C; 8; 0 RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-C; 30
___________________________ __________________________
+-------+ +-------+ ( ) +-------+ +-------+ ( )
| WEP-A +-------------+ WEP-B +-(C=CH;ADMD=ARCOM;PRMD=REMOTE) | MTA-A +-------------+ MTA-B +-( P=REMOTE; A=ARCOM; C=CH; )
+-------+ +-------+ (___________________________) +-------+ +-------+ (__________________________)
\ / \ /
\ +-------+ \ +-------+
-----------+ WEP-C | -----------+ MTA-C |
+-------+ +-------+
The next case is the same as in section 6.1. By setting the 6.3 Load Sharing
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
Domain: C=CH;ADMD=ARCOM;PRMD=REMOTE
WEP: C=CH;ADMD=ARCOM;PRMD=REMOTE;MTAname=WEP-B; 9; 0
WEP: C=CH;ADMD=ARCOM;PRMD=RELAYX;MTAname=WEP-C; 5; 120
___________________________
+-------+ 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.
6.3 Load Sharing
It is possible to set equal priorities to do some sort of load It is possible to set equal priorities to do some sort of load
sharing. However, most implementations are not able to do random sharing. However, most implementations are not able to do random
selection of WEPs with equal priorities but have a fixed selection of RELAY-MTAs with equal priorities but have a fixed
configuration. If load sharing is really needed then it is configuration. If load sharing is really needed then it is suggested
suggested to split up the MHS domain into several subdomains and to split up the MHS domain into several MHS subtrees and document
document them separately with a set of WEPs with different them separately with a set of RELAY-MTAs with different priorities.
priorities.
An example is provided for illustration of the first possibility An example is provided for illustration of the first possibility with
with equal priorities: equal RELAY-MTA-priorities:
Community: REMOTEmail Community: REMOTEmail
Domain: C=CH;ADMD=ARCOM;PRMD=REMOTE Domain: * P=REMOTE; A=ARCOM; C=CH;
WEP: C=CH;ADMD=ARCOM;PRMD=SWITCH;MTAname=WEP-B; 9; 0 RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-B; 10
WEP: C=CH;ADMD=ARCOM;PRMD=SWITCH;MTAname=WEP-C; 9; 0 RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-C; 10
_ ___________________________ _ __________________________
) +-------+ ( ) ) +-------+ ( )
)--+ WEP-B +--(C=CH;ADMD=ARCOM;PRMD=REMOTE) )--+ MTA-B +--( P=REMOTE; A=ARCOM; C=CH; )
) +-------+ (___________________________) ) +-------+ (__________________________)
) / ) /
) +-------+/ ) +-------+/
)--+ WEP-C | )--+ MTA-C |
_) +-------+ _) +-------+
And here is an example where the MHS domain And here is an example where the MHS domain
C=CH;ADMD=ARCOM;PRMD=REMOTE;O=Big-Org is documented with its own C=CH;ADMD=ARCOM;PRMD=REMOTE;O=Big-Org is documented with its own
DOMAIN document: Note that both WEPs serve as backup WEPs. DOMAIN document: Note that in this example both RELAY-MTAs serve
as backup RELAY-MTAs.
Community: REMOTEmail Community: REMOTEmail
Domain: C=CH;ADMD=ARCOM;PRMD=REMOTE Domain: * P=REMOTE; A=ARCOM; C=CH;
WEP: C=CH;ADMD=ARCOM;PRMD=SWITCH;MTAname=WEP-B; 9; 0 RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-B; 10
WEP: C=CH;ADMD=ARCOM;PRMD=SWITCH;MTAname=WEP-C; 8; 0 RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-C; 30
Community: REMOTEmail Community: REMOTEmail
Domain: C=CH;ADMD=ARCOM;PRMD=REMOTE;O=Big-Org Domain: * O=Big-Org; P=REMOTE; A=ARCOM; C=CH;
WEP: C=CH;ADMD=ARCOM;PRMD=SWITCH;MTAname=WEP-C; 9; 0 RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-C; 10
WEP: C=CH;ADMD=ARCOM;PRMD=SWITCH;MTAname=WEP-B; 8; 0 RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-B; 30
_ ___________________________ _ __________________________
) +-------+ ( ) ) +-------+ ( )
)--+ WEP-B +--(C=CH;ADMD=ARCOM;PRMD=REMOTE) )--+ MTA-B +--( P=REMOTE; A=ARCOM; C=CH; )
) +-------+ (___________________________) ) +-------+ (__________________________)
) \/ ) \/
) /\ _____________________________________ ) /\ _____________________________________
) +-------+ ( ) ) +-------+ ( )
)--+ WEP-C |--(C=CH;ADMD=ARCOM;PRMD=REMOTE;O=Big-Org) )--+ MTA-C |--( O=Big-Org; P=REMOTE; A=ARCOM; C=CH; )
_) +-------+ (_____________________________________) _) +-------+ (_____________________________________)
A third example shows a similar load sharing agreement as the 7. Open issues
previous one but it uses different delay values since WEP-B
doesn't have direct connectivity to the MHS domain
C=CH;ADMD=ARCOM;PRMD=REMOTE;O=Big-Org.
Community: REMOTEmail
Domain: C=CH;ADMD=ARCOM;PRMD=REMOTE
WEP: C=CH;ADMD=ARCOM;PRMD=SWITCH;MTAname=WEP-B; 9; 0
WEP: C=CH;ADMD=ARCOM;PRMD=SWITCH;MTAname=WEP-C; 8; 0
Community: REMOTEmail
Domain: C=CH;ADMD=ARCOM;PRMD=REMOTE;O=Big-Org
WEP: C=CH;ADMD=ARCOM;PRMD=SWITCH;MTAname=WEP-C; 9; 0
WEP: C=CH;ADMD=ARCOM;PRMD=SWITCH;MTAname=WEP-B; 8; 60
_ ___________________________
) +-------+ ( )
)--+ 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 Currently there are about 35 RELAY-MTAs within the COSINE-MHS
service. A rough guess is that a network with about 60 RELAY-MTAs is
still manageable provided there are automated tools for MTA
configuration. If there are more MTAs applying for RELAY-MTA 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-RELAY-MTAs should
form a backbone, documented within a specific MHS community.
Security considerations are not discussed in this memo. Since the RELAY-MTA 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)RELAY-MTA. The rules in chapter 6
could be modified to select X.400(88) systems first if the sending
RELAY-MTA is an (88) system itself. The issue of how to establish an
X.400(88) RELAY-MTA infrastructure within an MHS community is for
further study.
Appendix A Document examples for the COSINE-MHS community Appendix A: Document examples for the COSINE-MHS community
Instead of creating artificial documents to show an example Instead of creating artificial documents to show an example document
document set this appendix contains extracts from a real operational set, this appendix contains extracts from a real operational X.400
X.400 service. The research and development community in Europe uses service. The research and development community in Europe has used
X.400 since several years. This proposal has initially been written X.400 for several years. This proposal was initially written to
to address this community only and solve the urgent routing and address this community only and solve the urgent routing and
coordination problems. Contributions from different experts made it coordination problems. Contributions from different experts have
more flexible and therefore hopefully useful for other MHS made it more flexible and therefore hopefully useful for other MHS
communities. communities.
Appendix A1 The COMMUNITY document Appendix A1: The COMMUNITY document
Community: COSINE-MHS Community: COSINE-MHS
# The COSINE-MHS service is a MHS community formed by the European # The COSINE-MHS service is a MHS community formed by the European
# academic and research networks with additional contacts in all # academic and research networks with additional contacts in all
# other continents. # other continents.
#
# The coordination is done by the COSINE-MHS project team. # The coordination is done by the COSINE-MHS project team.
# #
Update: DATE=921111; START=930201 Update: FORMAT=V3; DATE=921218; START=930201
# #
Address: S=Project-Team; OU=COSINE-MHS; O=SWITCH; P=SWITCH Address: S=Project-Team; O=SWITCH; P=SWITCH; A=ARCOM; C=CH;
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
# #
Mail-server: S=COSINE-MHS-SERVER; OU=COSINE-MHS; O=SWITCH; Phone: +41 1-262-31-43
Fax: +41 1-261-81-88
#
Mail: SWITCH Head Office /
MHS Coordination Service /
Limmatquai 138 /
CH-8001 Zurich /
Switzerland
#
Reachable: 09:00-12:00; 14:00-17:30; UTC+1
#
Mail-server: S=mhs-server; O=switch; OU1=nic;
P=SWITCH; A=ARCOM; C=CH; P=SWITCH; A=ARCOM; C=CH;
FTP-server: nic.switch.ch; cosine-mhs; 'your email address' FTP-server: nic.switch.ch; cosine; user@domain
# #
Macro: Int-X25(80) TELEX+00728722+X25(80)+01+ Macro: Int-X25(80) TELEX+00728722+X.25(80)+01+
Macro: Internet-RFC-1006 TELEX+00728722+RFC-1006+03+ Macro: Internet-RFC-1006 TELEX+00728722+RFC-1006+03+
Macro: IXI TELEX+00728722+X.25(80)+06+
# #
Mandatory-Service: Public-X.25/X.25/TP0 Mandatory-Service: Public-X.25/X.25/TP0
# The public X.25 network. X.25 is supported in most X.400 # The public X.25 network. X.25 is supported in most X.400
# applications and mandatory in X.400 anyhow. # applications and mandatory in X.400 anyhow.
# #
Mandatory-Service: Internet/TCP/RFC1006 Mandatory-Service: Internet/TCP/RFC1006
# The Internet, standing for the global TCP/IP network of the # The Internet, standing for the global TCP/IP network of the
# research and development community # research and development community
# RFC1006 is considered a solution to ease migration to OSI. It will # RFC1006 is considered a solution to ease migration to OSI. It will
# be replaced by TP4/CLNS as soon as a reliable service is # be replaced by TP4/CLNS as soon as a reliable service is
# available. # available.
# #
Optional-Service: RARE-CLNS/CLNS/TP4 Optional-Service: Int-CLNS/CLNS/TP4
# The RARE Connectionless pilot service. Current participants are # The RARE Connectionless pilot service. Current participants are
# NORDUnet, SURFnet, CERN, NSFnet and SWITCH. # NORDUnet, SURFnet, CERN, NSFnet and SWITCH.
# #
Optional-Service: RARE-IXI/X.25/TP0 Optional-Service: EMPB-X.25/X.25/TP0
# The International X.25 Infrastructure covering most countries in # The International X.25 Infrastructure covering most countries in
# Europe. The absence of volume tariffs make it a preferred choice. # Europe. The absence of volume tariffs make it a preferred choice.
Appendix A2 Example of a WEP document Appendix A2: Example of a RELAY-MTA document
Community: COSINE-MHS Community: COSINE-MHS
# #
Update: DATE=921111; START=930201 Update: FORMAT=V3; DATE=921218; START=930201
# #
WEP: P=SWITCH; A=ARCOM; C=CH; MTAname=vms.switch RELAY-MTA: P=SWITCH; A=ARCOM; C=CH; MTAname=chx400.switch.ch
# #
Status: primary Status: primary
#
Password: ***none*** Password: none
RTS-dialog-mode: TWA RTS-dialog-mode: MONOLOGUE
# #
Called-address: Public-X.25/X.25/TP0; Called-address: Public-X.25/X.25/TP0;
Int-X25(80)=22847971014110; MTS-TP-84 "591"/Int-X25(80)=22847971014520+CUDF+03010100;
MTS-TP-84
Calling-address: Public-X.25/X.25/TP0; Calling-address: Public-X.25/X.25/TP0;
Int-X25(80)=22847971014 Int-X25(80)=22847971014520;
# #
Called-address: Internet/TCP/RFC1006; Called-address: Internet/TCP/RFC1006;
Internet-RFC-1006=130.59.1.1; MTS-TP-84 "591"/Internet-RFC-1006=chx400.switch.ch;
MTS-TP-84
Calling-address: Internet/TCP/RFC1006; Calling-address: Internet/TCP/RFC1006;
Internet-RFC-1006=130.59.1.1 Internet-RFC-1006=chx400.switch.ch
# #
System: COM=DEC VAX4000-300; OPS=VMS 5.4; MHS=DFN-EAN V2.2+ Called-address: EMPB-X.25/X.25/TP0;
"591"/IXI=20432840100520+CUDF+03010100;
MTS-TP-84
Calling-address: EMPB-X.25/X.25/TP0;
IXI=20432840100520;
# #
LocalDomain: O=switch; P=switch; A=arcom; C=ch; Calling-address: Int-CLNS/CLNS/TP4;
"591"/NS+39756F11111111010000014560AA00040005E100;
MTS-TP-84
Called-address: DCC+756+x11111111010000014560AA00040005E100
# #
EchoServer: S=echo; O=switch; P=switch; A=arcom; C=ch; # For X.400(88) over CLNS
# #
Administrator: CN=Christoph Graf, O=SWITCH, C=CH Calling-address: Int-CLNS/CLNS/TP4;
Administrator: CN=Urs Eppenberger, O=SWITCH, C=CH "592"/NS+39756F11111111010000014560AA00040005E100;
MTS-T
Called-address: DCC+756+x11111111010000014560AA00040005E100
#
System: HW=SUN 4/690MP; OS=SunOS 4.1.1; SW=PP-6.0
#
LocalDomain: O=switch; OU1=chx400; P=switch; A=arcom; C=ch;
# #
EchoServer: S=echo; O=switch; OU1=chx400; P=switch; A=arcom; C=ch;
#
Administrator: CN=Felix Kugler, O=SWITCH, C=CH
Administrator: CN=Christoph Graf, O=SWITCH, C=CH
Appendix A3 Example of a DOMAIN document Appendix A3: Example of a DOMAIN document
Community: COSINE-MHS Community: COSINE-MHS
# #
Update: DATE=921111; START=930201 Update: FORMAT=V3; DATE=921218; START=930201
## ##
Domain: P=SWITCH; A=ARCOM; C=CH; Domain: * P=SWITCH; A=ARCOM; C=CH;
Domain: P=SANDOZ; A=ARCOM; C=CH; Domain: * P=SANDOZ; A=ARCOM; C=CH;
Domain: P=ABB; A=ARCOM; C=CH; Domain: * P=ABB; A=ARCOM; C=CH;
Domain: P=UBS; A=ARCOM; C=CH; Domain: * P=UBS; A=ARCOM; C=CH;
Domain: P=ISREC; A=ARCOM; C=CH; Domain: * P=ISREC; A=ARCOM; C=CH;
Domain: P=ALCATEL; A=ARCOM; C=CH; Domain: * P=ALCATEL; A=ARCOM; C=CH;
Domain: P=ITU; A=ARCOM; C=CH; Domain: * P=ITU; A=ARCOM; C=CH;
Domain: P=OSILABMAIL; A=ARCOM; C=CH; Domain: * P=OSILABMAIL; A=ARCOM; C=CH;
Domain: P=WHO; A=ARCOM; C=CH; Domain: * P=WHO; A=ARCOM; C=CH;
Domain: P=CERN; A=ARCOM; C=CH; Domain: * P=CERN; A=ARCOM; C=CH;
Domain: P=CERBERUS; A=ARCOM; C=CH; Domain: * P=CERBERUS; A=ARCOM; C=CH;
# #
Administrator: CN=Christoph Graf, O=SWITCH, C=CH Administrator: CN=Christoph Graf, O=SWITCH, C=CH
Administrator: S=postmaster; O=SWITCH; P=SWITCH; A=ARCOM; 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 RELAY-MTA: P=SWITCH; A=ARCOM; C=CH; MTAname=chx400.switch.ch; 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 RELAY-MTA: P=SWITCH; A=ARCOM; C=CH; MTAname=vms.switch; 10
Net: Internet/TCP/RFC1006; 20
Net: Public-X.25/X.25/TP0; 10
Appendix A4 Example of a PERSON document Appendix A4: Example of a PERSON document
Community: COSINE-MHS Community: COSINE-MHS
# #
Update: DATE=921111; START=930201 Update: FORMAT=V3; DATE=921218; START=930201
# #
Key: CN=Christoph Graf, O=SWITCH, C=CH Key: CN=Christoph Graf, O=SWITCH, C=CH
# #
Name: Christoph Graf Name: Christoph Graf
# #
Address: S=Graf; O=SWITCH; P=SWITCH; A=ARCOM; C=CH; Address: S=Graf; O=SWITCH; P=SWITCH; A=ARCOM; C=CH;
RFC822: Graf@switch.ch RFC822: Graf@switch.ch
# #
Phone: +41 1 2565454 Phone: +41 1 2565454
Fax: +41 1 2618133 Fax: +41 1 2618133
# #
Mail: SWITCH Head Office/ Mail: SWITCH Head Office /
Christoph Graf/ Christoph Graf /
Limmatquai 138/ Limmatquai 138 /
CH-8001 Zurich/ CH-8001 Zurich /
Switzerland Switzerland
# #
Reachable: 09:00-12:00; 14:00-17:30; UTC-1 Reachable: 09:00-12:00; 14:00-17:30; UTC+0100
Appendix B OR Address Representation Appendix B: BNF Definitions
This Appendix defines the OR address representation to be used <called-connection> ::= "Called-address: " \
throughout the documents.It is based on the following CCITT <Service-type> "; " \
recommendation <P-address> "; " <MTS> \
["; " <Service-priority>] <CR>
Annex to CCITT Rec. F.401 and ISO/IEC 10021-2 <calling-connection> ::= "Calling-address: " \
ANNEX F REPRESENTATION OF O/R ADDRESSES FOR HUMAN USAGE <Service-type> "; " \
<P-address> <CR>
and on a document written by Paul-Andre Pays which defines a <checkpoint-size> ::= "RTS-checkpoint-size: " \
subset of the CCITT recommendation to limit the options and 'checkpoint size' <CR>
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 <COMMUNITY-document> ::= <Community-Identifier> \
the routing documents. <Update-info> \
<COMMUNITY-document-body>
O/R addresses in labelled format consist of delimited pairs of <COMMUNITY-document-body> ::= <Coordination> \
labels and values in the syntax <label>"="<value>;. The labels for [{<Macro-definition>}] \
each attribute are specified in Tables T-1 and T-2. The label and {<Connections>}
its value must be separated by the character "=". The value is case
insensitive.
The ADMD attribute must always be present even if its value <Community-Identifier> ::= "Community: " \
consists only of a single space. ('community name' | <DirectoryName>) <CR>
The label for a DDA consists of "DDA:" followed by the DDA type. <connection-info> ::= <password> <RTS> \
If an address includes more than one DDA of the same type, it is {<called-connection><calling-connection>}\
assumed that the DDAs are intended to be processed in the sequence [<system>] \
in which they are represented. If the value of a DDA type includes [<local-domain>] \
the character "=", this should be represented by "==". [<echo-server>]
Label/value pairs appear in sequence on a line, they should be <Connections> ::= {<mandatory-service>} \
delimited by ";". (The ";" character is not in the set of printable {[<optional-service>]}
strings which makes it an excellent choice as delimiter. No escaping
is needed as for the '=' character.)
Each ';' must be followed by white space. <contact-info> ::= {"Administrator: " <UniquePersonKey> <CR>}
The sequence of attributes must be the one given in the tables T-1 <Coordination> ::= <EMail> <Phone> <FAX> \
and T-2. <Mail> <Operation> <File-server>
Attribute Type Label <Country-Code> ::= 'Two Character Country Code ISO-3166'
X.121 Network Address X.121 <dialog-mode> ::= "RTS-dialog-mode: " \
E.164 Network Address E.164 ("TWA" | "MONOLOGUE") <CR>
PSAP Network Address PSAP
User Agent Numeric ID N-ID
Terminal Identifier T-ID
Terminal Type T-TY <DirectoryName> ::= 'Distinguished Name'
Domain Defined Attribute DDA:<type>
where the notation <type> identifies the type of domain defined <DOMAIN-document> ::= <Community-Identifier> \
attribute. <Update-info> \
<DOMAIN-document-body>
There are currently six terminal types, and if international <DOMAIN-document-body>::= {<Domain-entry>} <responsible> \
consistency is required the following specific abbreviations {<Relay>}
should be used to represent the values for these types: tlx,
ttx, g3fax, g4fax, ia5 and vtx.
Table T-1. Other Attributes <Domain-entry> ::= "Domain: " <OR-matching> <MHS-subtree> <CR>
Attribute Type Label <echo-server> ::= "EchoServer: " <X.400 address> <CR>
Given Name G <EMail> ::= "Address: " <X.400 address> <CR>
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 <email-server> ::= "Mail-server: "<X.400 address> <CR>
Examples: <extension> ::= 'local extension'
G=john; S=smith; O=a bank ltd; P=abl; A=snomail; C=aq; <Fax> ::= "Fax: " <tel-no-list> <CR>
G=Daniel; S=terrer; P=inria; A=atlas; C=FR;
S=terrer; OU1=mirsa; P=inria; A=atlas; C=FR; <File-server> ::= <email-server> [{<FTP-server>}] \
DDA:RFC-822=we(a)sell-it.com; P=internet; A= ; C=fi; [{<FTAM-server>]}
<FTAM-server> ::= "FTAM-server: " <P-address> "; "\
'account-name' ["; " 'password'] \
["; X.500 " <DirectoryName>] <CR>
<FTP-server> ::= "FTP-server: " 'domain name' "; " \
'account-name' ["; " 'password'] <CR>
<int-pref> ::= 'international prefix'
<local-domain> ::= "LocalDomain: " <MHS-subtree> <CR>
<Macro-definition> ::= "Macro: " 'Macro name' " " \
'Macro value' <CR>
<Mail> ::= "Mail: " 'postal address information' <CR>
<mandatory-service> ::= "Mandatory-Service: " \
<Service-type> <CR>
<MHS-subtree> ::= ["O=" 'Organization-name' "; "] \
["OU1="'OrganizationalUnit'"; "\
["OU2=" 'OrganizationalUnit' "; " \
["OU3=" 'OrganizationalUnit' "; " \
["OU4=" 'OrganizationalUnit' "; "]]]] \
["P=" 'PRMDname' "; "] \
"A=" 'ADMDname' "; " \
"C=" <Country-Code> ";"
<MTS> ::= "MTS-T" | "MTS-TP" | "MTS-TP-84"
<Name> ::= "Name: " 'name of person' <CR>
<national number> ::= 'national telephone number'
<Network-name> ::= 'Name of a network'
<Network-service> ::= 'Name of a network service'
<Operation> ::= "Reachable: " {<time> "-" <time> "; "} \
<Time-zone> <CR>
<optional-service> ::= "Optional-Service: " \
<Service-type> <CR>
<OR-matching> ::= ( "* " | "= " )
<P-address> ::= 'String encoded Presentation Address'
<password> ::= "Password: " \
("secret" | "none" | \
"value=\"" 'password' "\"") <CR>
<PERSON-document> ::= <Community-Identifier> \
<Update-info> \
<PERSON-document-identifier> \
<PERSON-document-body>
<PERSON-document-identifier> ::= "Key: " <UniquePersonKey> <CR>
<PERSON-document-body>::= <Name> {<EMail>} {<RFC822>} \
<Phone> ::= "Phone: " <tel-no-list> <CR>
<Relay> ::= "Relay: " \
'UniqueRELAY-MTAkey' "; " \
<RELAY-MTA-Priority> <CR>
<RELAY-MTA-document> ::= <Community-Identifier> \
<Update-info> \
<RELAY-MTA-document-Identifier> \
<RELAY-MTA-document-body>
<RELAY-MTA-document-body> ::= <Status> <connection-info> \
<contact-info>
<RELAY-MTA-document-Identifier> ::= \
"RELAY-MTA: " <UniqueRELAY-MTAkey> <CR>
<RELAY-MTA-Priority> ::= <Integer 0..99>
<responsible> ::= {"Administrator: " <UniquePersonKey> <CR>}
<RFC822> ::= "RFC822: " <RFC-822-address> <CR>
<RTS> ::= <dialog-mode> \
[<checkpoint-size> <window-size>]
<Service-priority> ::= 'Integer 0..99'
<Service-type> ::= <Network-name> "/" \
<Network-service> "/" \
<Transport-Protocol>
<Status> ::= "Status: " ("primary" | "secondary") <CR>
<system> ::= "System: HW=" 'computer type' "; " \
"OS=" 'operating system' "; " \
"SW=" 'MHS software' <CR>
<tel-no-list> ::= <tel-number> [{"; " <tel-number>}]
<tel-number> ::= {"+" <int-pref> " " <national number> \
[" x" <extension>]}
<time> ::= 'hh:mm'
<Time-zone> ::= ("UTC+" | "UTC-") 'hhmm'
<Transport-Protocol> ::= 'Name of a transport protocol'
<UniquePersonKey> ::= (<X.400 address> | <DirectoryName> )
<UniqueRELAY-MTAkey> ::= (([ "P=" 'PRMDname' "; " ] \
["A=" 'ADMDname' "; " ] \
"C=" <Country-Code> "; " \
"MTAname=" 'MTAname')
| <DirectoryName> )
<Update-info> ::= "Update: FORMAT=V3; DATE=" 'yymmdd' \
"; START=" 'yymmdd' \
["; END=" 'yymmdd'] <CR>
<window-size> ::= "RTS-window-size: " \
'window size' <CR>
<X.400 address> ::= 'OR address, ISO 10021-2 Annex F'
<X.400 routing coordination document set> ::= \
<COMMUNITY-document> \
{ <RELAY-MTA-document> } \
{ <DOMAIN-document> } \
{ <PERSON-document> }
Security Considerations
Security issues are not discussed in this memo.
Author's Address Author's Address
Urs Eppenberger Urs Eppenberger
SWITCH Head Office SWITCH Head Office
Limmatquai 138 Limmatquai 138
CH-8001 Zurich CH-8001 Zurich
Switzerland Switzerland
Phone: +41 1 261 8112 Phone: +41 1 261 8112
Fax: +41 1 261 8133
EMail: Eppenberger@switch.ch EMail: Eppenberger@switch.ch
S=Eppenberger; O=SWITCH; P=SWITCH; A=ARCOM; C=CH; S=Eppenberger; O=SWITCH; P=SWITCH; A=ARCOM; C=CH;
Comments to the document may also be sent to the distribution list
wg-msg@rare.nl of the RARE Working Group on Mail and Messaging.
 End of changes. 262 change blocks. 
841 lines changed or deleted 946 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/