view Side-By-Side changes
Date: Tue, 09 Apr 2002 09:09:43 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Wed, 09 Dec 1992 04:33:00 GMT
ETag: "3dde43-f32f-2b2576fc"
Accept-Ranges: bytes
Content-Length: 62255
Connection: close
Content-Type: text/plain
X400 Operations Group U. Eppenberger
Internet Draft SWITCH
11 November 1992
Expires: May 1993 RFC 1465:
Title: Routing coordination Coordination for X.400 MHS services
within Services
Within a multi protocol Multi Protocol / multi network environment
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts).
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
"working draft" or "work in progress."
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any other
Internet Draft.
It is intended that this document will be submitted to the IESG Multi Network
Environment Table Format V3 for consideration as a experimental standard. Distribution of this
document is unlimited.
1 Introduction Static Routing
Author: D. Eppenberger
Mailbox: Eppenberger@switch.ch
Pages: 31
Characters: 66,833
Updates/Obsoletes: none
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
however, manager, two of which are:
- Where do I route new X.400 addresses and
- How do I connect to a MHS domain that uses an underlying
technology that I do not support.
This document proposes how these problems can be solved in the short term. It proposes a strategy term solutions to these problems.
This memo defines an Experimental Protocol for maintaining and distributing
routing information and shows how messages can travel over different
networks by using multi stack MTAs as relays. Document formats the Internet
community. Discussion and
coordination procedures bridge suggestions for improvement are requested.
Please refer to the gap until an X.500 directory
service current edition of the "IAB Official Protocol
Standards" for the standardization state and status of this protocol.
Distribution of this memo is ready unlimited.
This announcement is sent to store the needed connectivity IETF list and routing
Eppenberger Expires: May 1993 [Page 1]
INTERNET-DRAFT Routing Coordination for X.400 Services November 1992
information. The format has been designed to allow the information RFC-DIST list.
Requests to be stored in a X.500 directory service while managers without
directory service access may still use a table based approach.
Many experts added to or deleted from the IETF X.400-Operations Group and RARE Working
Group 1 on Message Handling Systems have read drafts of this
document and contributed ideas and solutions. I would especially
like distribution list
should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be added
to thank Harald Alvestrand, Erik Huizer, Marko Kaittola, Allan
Cargille and Paul-Andre Pays.
2 Terminology
MHS community
One or more MHS domains form together an MHS community. Mail
exchange between these MHS domains is defined by the coordination
procedures within this document. An example of an MHS community is deleted from the global X.400 MHS service.
MHS domain
One RFC-DIST distribution list should be sent to
RFC-REQUEST@NIC.DDN.MIL.
Details on obtaining RFCs via FTP or more MHS subtrees form together EMAIL may be obtained by sending
an MHS domain. This is a
purely administrative grouping of MHS subtrees. It is helpful, if
someone is responsible for several MHS subtrees, to refer EMAIL message to an
MHS domain instead of listing all the subtrees.
MHS subtree
An MHS subtree consists of "rfc-info@ISI.EDU" with the total of message body
"help: ways_to_get_rfcs". For example:
To: rfc-info@ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the mailboxes
addressable within a subtree
author of the X.400 OR address space.
Example: O=SWITCH; P=SWITCH; A=ARCOM; C=CH;
MHS domain of SWITCH in Switzerland, consisting of all
mailboxes with O=SWITCH; P=SWITCH; A=ARCOM; C=CH; RFC in the OR
address.
WEP
Well known Entry Point, an X.400 MTA serving one question, or several MHS
domains. (Note that this term is used here in a different way than
in the early X.400ies (1987/88), where WEP has been used as the
term for an X.400 MTA serving a whole country.)
COSINE-MHS
The COSINE-MHS community is mainly formed by European X.400
service providers from the academic and research area, each of
which is a member of RARE. The COSINE-MHS community is used in the
annex as an example for the usage of this document in a
multinational environment.
Eppenberger Expires: May 1993 [Page 2]
INTERNET-DRAFT Routing Coordination for X.400 Services November 1992
3 Requirements
X.400 MTAs can communicate using different transport and network
protocol stacks. For this document the stacks used in a WAN
environment need to be considered:
Stack 1 Stack 2 Stack 3 Stack 4
Transport Layer 4 TP0 TP4 RFC1006 TP0
Networkservice 1-3 X.25 CLNS TCP/IP CONS
A common protocol stack is not the only requirement to enable
communication between two MTAs. The networks to which the MTAs
belong need to be interconnected. Some well known networks are
listed together with the stacks they use.
Network Stack Abbreviation
Public Switched Packet Data Networks 1 Public-X.25
International X.25 Infrastructure IXI 1,4 RARE-IXI
RARE connectionless pilot 2 RARE-CLNS
Internet 2,3 Internet
Note that several stacks may be supported over a single network.
However communication between MTAs is only possible if the MTAs
share at least a common stack AND a common network.
Unlike SMTP/TCP/IP systems, there is no directory service
available which would allow an MTA to look up the next MTA to which
it should submit a message. Routing within X.400 will continue to be
table based until a solution using X.500 directory services is
available.
Furthermore it is not generally allowed to connect to any MTA even
on the same network without being registered on the destination MTA.
These restrictions require a large coordination effort and carefully
configured and updated systems.
4 Outline of the proposal
This proposal offers a solution for describing information about
X.400 message routing within an MHS community in WEP and DOMAIN
documents. Basic information on the MHS community is documented in
the corresponding COMMUNITY document. All contact persons and WEP
administrators can be found in PERSON documents. A future X.500
based solution may need extended information to overcome still
unsolved problems like optimal routing or traffic optimization for
messages with multiple recipients. The information collected for the
intermediate solution however is very basic. All established
coordination procedures will help and even speed up the future
introduction of an X.500 based solution.
Eppenberger Expires: May 1993 [Page 3]
INTERNET-DRAFT Routing Coordination for X.400 Services November 1992
4.1 The COMMUNITY document
For each MHS community there exists one single COMMUNITY
document containing basic information. First the contact
information for the central coordination point can be found
together with the addresses for the file server where all the
documents are stored. It also lists network names and stacks to be
used in the WEP and DOMAIN documents. An MHS community must agree
on its own set of mandatory and optional networks and stacks.
4.2 The WEP document
Every MHS domain in the community may designate one or more MTAs
as WEPs. These WEPs accept incoming connections from the WEPs of
the other MHS domains and in return are allowed to send messages
to these WEPs. A WEP is documented with all the needed connection
information in the corresponding WEP document.
4.3 The DOMAIN document
An MHS domain has a responsible person who sets up the routing
entries for the domain in the DOMAIN document. The primary WEPs
listed in the DOMAIN document as serving this MHS domain must,
TOGETHER, offer at least connectivity to all networks and stacks
listed as mandatory in the COMMUNITY document. Optional WEPs may
be added, generally with higher priority, to allow more precise
routing.
An MHS domain may also decide not to operate a WEP. It will then
only need agreements with one or more WEPs from other MHS domains
which will relay for this domain. The domain itself, however, must
always create a DOMAIN document.
The structure of the DOMAIN document is very straightforward. It
starts of with one or more MHS subtrees, each on its own line.
After the domains follows a line indicating the responsible person
for the MHS subtrees mentioned. Finally the relaying WEP(s) are
listed with appropriate priorities.
4.4 The PERSON document
All administrators and responsible persons are documented in
PERSON documents. The COMMUNITY, WEP and DOMAIN documents contain
just keys pointing to a PERSON document. If such a person can
already be found in a X.500 directory service, then the key
consists of a Distinguished Name, else the key is just its OR
address.
4.5 Coordination
This approach requires an identified coordination point. It is
up to the MHS community to decide on the level of coordination and
Eppenberger Expires: May 1993 [Page 4]
INTERNET-DRAFT Routing Coordination for X.400 Services November 1992
support to be provided and on the funding mechanisms for such
activities. Basic information can be found in the COMMUNITY
document. The following list of support activities is considered
mandatory for an operational service:
- New WEPs joining the service are tested and support is given to
create the WEP document.
- New MHS domains joining the MHS community get assistance to set
up WEP(s) and find appropriate relaying WEP(s) and to create
DOMAIN documents.
- Updated documents are announced to the WEP managers.
- All the WEP, DOMAIN and PERSON documents are made available on a
file server together with the COMMUNITY document. The file
server must at least be reachable via email. MHS communites with
a big number of documents may consider additional access methods
like ftp and FTAM.
- Tools should be made available to manage routing tables for the
X.400 software used on the WEPs. The format of the documents has
especially been choosen to enable the use of automated tools.
4.6 Routing
The proposal addresses MHS communities spanning several
organisations. But it may also be used to manage routing within a
single organisation or even a global MHS community.
Two kind of mail relays are defined, the primary WEPs and the
secondary WEPs. All primary and secondary WEPs allow incoming
connections from each other. The primary WEPs can decide if they
also use more precise routing and send to the secondary WEPs too.
A secondary WEP must connect to at least one primary WEP.
The WEP managers must be aware that a large number of WEPs in an
MHS community may require significant operational recources to
keep the local routing tables up-to-date and to constantly monitor
the correct functioning of the connections.
MHS communities may decide on additional mandatory requirements
for the operation of a WEP. These may include a hot line, echo
services, exchange of statistics, response time to problem
reports, uptime of the WEP, etc. This will ensure a certain
quality of service for the end users.
Each MHS community must define update procedures for the routing
based on the documentation. Automated update has to be studied
carefully.
Eppenberger Expires: May 1993 [Page 5]
INTERNET-DRAFT Routing Coordination for X.400 Services November 1992
An MHS community should also define procedures for new WEPs and
MHS domains joining the service. Since the usage of X.400 is
growing rapidly a flexible but well coordinated way of integrating
new members into an MHS community is needed. The proposed
documentation format support this by allowing mandatory and
optional WEPs. All WEPs accept incoming connections from each
other. Sending messages can be done by using the mandatory WEPs
only. This allows new WEPs to join the community as optional and
to get mandatory status when traffic flow increases.
5 The documents
The definition is given in BNF-like syntax. The following
conventions are used:
| means choice
\ is used for continuation of a definition over several lines
[] means optional
{} means repeated one or more times
()...is used to group choices
'CR' is a Carriage Return and means that the next section starts
on its own line.
The definition is complete only to a certain level of detail.
Below this level, all expressions are to be replaced with text
strings. The format and semantics should be clear from the names
of the expressions and the comments given. Expressions without
more detailed definition are marked with single quotes '.
Since the documents should still be 'human readable', it is
possible to use multiple spaces wherever at least one space is
required. Please note that for some field values the number of
spaces is significant.
Comments may be placed anywhere in the document but only on
separate lines. Such a comment line must either start with a '#'
sign followed by white space and the comment or consist of a
single '#' on a single line.
If the information on a line in a document exceeds 80
characters, it is suggested to do line wrapping according RFC822:
Wrap the line at any convenient place, generally at a white space,
then continue on the second line with leading white space.
Some field values are case sensitive (TSAP, Password). In order
to handle this issue in a consistent way all keys and values must
use the same case as the BNF definitions.
Eppenberger Expires: May 1993 [Page 6]
INTERNET-DRAFT Routing Coordination for X.400 Services November 1992
5.1 Basic Definitions
<X.400 routing coordination document set> ::= \
<COMMUNITY-document> \
{ <WEP-document> } \
{ <DOMAIN-document> } \
{ <PERSON-document> }
A set of one COMMUNITY document and several WEP, DOMAIN
and PERSON documents belong together.
<DirectoryName> ::= 'Distinguished Name'
The string representation of a Distinguished Name is
defined in the IETF OSI-DS document 23. It is still an
Internet Draft, but the latest version is very likely
to be accepted at the Nov '92 IETF meeting. If a
Distinguished Name is used as a key in the documents,
then the information can be fetched from the directory
instead of checking the appropriate document. However
the same information must also be present in a document
as long as not all managers in the same community have
directory access.
<Community-Identifier> ::= "Community: " \
('community name' | <DirectoryName>) 'CR'
The 'community name' is a string identifying the MHS
community to be used in the first line of all
documents.
<UniqueWEPkey> ::= ([ "P=" 'PRMDname' "; " ] \
["A=" 'ADMDname' "; " ] \
"C=" <Country-Code> "; " \
"MTAname=" 'MTAname'
| <DirectoryName> )
A unique key is needed to identify the WEP. In addition
to the MTA name itself, it is proposed to use OR
address attributes of the management domain where the
WEP resides. ADMD and PRMD fields are both optional and
may be used to guarantee uniqueness of the key. The
values used are irrelevant. Even non-printable
characters like @ or ! are acceptable. The result is
not an address but a key string. A Distinguished Name
may be used instead.
<UniquePersonKey> ::= (<X.400 address> | <DirectoryName> )
A unique key is needed to make the links from the
documents where a responsible person or an
administrator is needed to the PERSON documents. It is
either the OR address of the person or a Distinguished
Name (if the person is already registered in the
directory).
<Country-Code> ::= 'Two Character Country Code ISO-3166'
Eppenberger Expires: May 1993 [Page 7]
INTERNET-DRAFT Routing Coordination for X.400 Services November 1992
<X.400 address> ::= 'OR address, ISO 10021-2 Annex F'
See Appendix B for a brief description of this format.
It has been used consequently all over the document.
This explains also the syntax of the <UniqueWEPkey> and
the <MHS-subtree>.
<EMail> ::= "Address: " <X.400 address> 'CR'
<tel-no-list> ::= <tel-number> [{"; " <tel-number>}]
<tel-number> ::= {"+" <int-pref> " " [<area> " "] \
<local-tel-no>}
<int-pref> ::= 'international prefix'
<area> ::= 'area code'
<local-tel-no> ::= 'local telefone number'
<Phone> ::= "Phone: " <tel-no-list> 'CR'
One or more phone numbers
<Fax> ::= "Fax: " <tel-no-list> 'CR'
One or more FAX numbers
<Mail> ::= "Mail: " 'postal address information' 'CR'
The items of the postal address are separated by '/'
wherever the next item goes onto the next line for a
printed address label. Especially if the community
spans several countries it does make sense to give the
full address including the country.
Example:
Mail: SWITCH Head Office/Urs Eppenberger/
Limmatquai 138/CH-8001 Zurich/Switzerland
results in the following mailing label:
SWITCH Head Office
Urs Eppenberger
Limmatquai 138
CH-8001 Zurich
Switzerland
<Update-info> ::= "Update: DATE=" 'yymmdd' \
["; START=" 'yymmdd'] \
["; END=" 'yymmdd'] 'CR'
The date of the last update of a document is given in
the form 'yymmdd'.
An optional start date can be set. A document can be
published this way before the information in it is
valid. (This is especially useful in absence of
automated tools. WEP managers get more time to prepare
their systems.)
An end date is used to set an expiration date for the
document.
Eppenberger Expires: May 1993 [Page 8]
INTERNET-DRAFT Routing Coordination for X.400 Services November 1992
<P-address> ::= 'String encoded Presentation Address'
The format of this string follows RFC1278, A string
encoding of Presentation Address and RFC1277, Encoding
Network Addresses to support operation over non-OSI
layers. See chapter 5.2 about the usage of macros in a
Presentation Address.
<Service-type> ::= <Network-name> "/" \
<Network-service> "/" \
<Transport-Protocol>
<Network-name> ::= 'Name of a network'
The network-name string identifies a network. A well
known key word should be choosen. (No '/' character is
allowed.)
Examples: Public-X.25, Internet, RARE-IXI, RARE-CLNS,
WIN,
<Network-service> ::= "X.25" | "CONS" | "CLNS" | "TCP"
One of the four values identifies the 'network service'
used. (TCP is considered a network service together
with RFC1006)
<Transport-Protocol> ::= "TP0" | "TP2" | "TP4" | "RFC1006"
The service type consists of a string with three parts
concatenated with a "/": Network-name/Network-
service/Transport-Protocol.
Since network and stack information forms one string,
it identifies in an easy way a connection possibility
between two WEPs. The COMMUNITY document defines the
strings to be used in the WEP and DOMAIN documents.
Some examples:
Internet/TCP/RFC1006
Public-X.25/X.25/TP0
RARE-IXI/CONS/TP0
RARE-CLNS/CLNS/TP4
(It is probably important to mention here that this
string has nothing to do with the format of a
presentation address as defined by Steve Hardcastle-
Kille in RFC1278. The problem of networks using the
same address structure (X.121 DTEs, 4 Byte Internet
addresses) but not beeing connected is not addressed in
RFC1278 but solved by using the proposed service
identifier above in addition to the presentation
address. As long as there are network islands, there is
no other way than the addition of an 'island'-
identifier. As soon as all systems have an NSAP and are
connected to a global OSI network, this problem will
disappear.)
Eppenberger Expires: May 1993 [Page 9]
INTERNET-DRAFT Routing Coordination for X.400 Services November 1992
<MHS-subtree> ::= ["OU4=" 'OrganizationalUnit-name' "; "] \
["OU3=" 'OrganizationalUnit-name' "; "] \
["OU2=" 'OrganizationalUnit-name' "; "] \
["OU1=" 'OrganizationalUnit-name' "; "] \
["O=" 'Organization-name' "; "] \
["P=" 'PRMDname' "; "] \
"A=" 'ADMDname' "; " \
"C=" <Country-Code> ";"
5.2 The COMMUNITY document
<COMMUNITY-document> ::= <Community-Identifier> \
<Update-info> \
<COMMUNITY-document-body>
The first line of the COMMUNITY document specifies the
<Community-Identifier> to be used in the header of all
other documents belonging to the same community. It is
recommended to add a few comment lines to describe the
members of this MHS community.
<COMMUNITY-document-body> ::= <Coordination> \
{<Macro-definition>}{<Connections>}
<Coordination> ::= <EMail> <Phone> <FAX> \
<Mail> <File-server>
Set of contact information for the coordination point
<File-server> ::= <email-server> [{<FTP-server>}] \
[{<FTAM-server>]}
All documents must be available at least to the
managers of the MHS domains and the WEPs through an
email server. If FTAM and FTP are also available, the
generation of automated update tools is much easier.
It is suggested to have a single server. If there is
only one, knowing a single X.400 OR address will allow
you to reach the server. However for FTP and FTAM more
system addresses may be possible depending on the
number of available network connections (or service
types as they are called in this document).
<email-server> ::= "Mail-server: "<X.400 address> 'CR'
The email address of the file server.
<FTP-server> ::= "FTP-server: " 'domain name' "; "
'account-name' ["; " 'password'] 'CR'
In addition to the domain name of the server, an
account name and a password is given. In most cases
this will probably be something like "anonymous" and
"guest".
Eppenberger Expires: May 1993 [Page 10]
INTERNET-DRAFT Routing Coordination for X.400 Services November 1992
<FTAM-server> ::= "FTAM-server: " \
('P-address' | <DirectoryName>) "; " \
<account-name> ["; " 'password'] 'CR'
The account name is often case sensitive. Some FTAM
server offer anonymous access with the account-name
ANON. Documenting a FTAM server with a Distinguished
Name is only allowed if the server is registered in the
directory.
<Macro-definition> ::= "Macro: " 'Macro name' " " \
'Macro value' 'CR'
Presentation addresses without the usage of macros are
generally unreadable. RFC1278 suggests a few macros.
All macros which are allowed in a communities must be
defined in the community document. It is recommended to
use the proposed macros in RFC1278 and add new ones if
necessary:
Macro: Int-X25(80) TELEX+00728722+X25(80)+01+
Macro: Janet-X25(80) TELEX+00728722+X25(80)+02+
Macro: Internet-RFC-1006 TELEX+00728722+RFC-1006+03+
<Connections> ::= {<mandatory-service>} \
{[<optional-service>]}
At least one service type is mandatory.
<mandatory-service> ::= "Mandatory-Service: " \
<Service-type> 'CR'
<optional-service> ::= "Optional-Service: " \
<Service-type> 'CR'
5.3 The WEP document
<WEP-document> ::= <Community-Identifier> \
<Update-info> \
<WEP-document-Identifier> \
<WEP-document-body>
A WEP document contains the full description of a
single WEP. Only one community is allowed. Since some
of the information is community dependent, it would not
be easily possible to have a single WEP document used
in different communities.
<WEP-document-Identifier> ::= "WEP: <UniqueWEPkey> 'CR'
<WEP-document-body> ::= <Status> <connection-info> \
<contact-info>
<Status> ::= "Status: " ("primary" | "secondary")
This defines if the WEP has 'primary' or 'secondary'
status. See section 4.3 and 6 for more information.
Eppenberger Expires: May 1993 [Page 11]
INTERNET-DRAFT Routing Coordination for X.400 Services November 1992
<connection-info> ::= <password> <RTS> \
{<called-connection><calling-connection>}
\
[<system>] \
[<local-domain>] \
[<echo-server>]
More than one set of connection information may be
present for WEPs supporting several networks and
protocol stacks.
<password> ::= "Password: " \
("***secret***" | "***none***" |
'password') 'CR'
If the keyword ***none*** is present, then no password
is used.
If the keyword ***secret*** is present, then the
connection needs a password which is not made publicly
available. The community might for example decide to
keep a list of the passwords at the central
coordination point. The list is then faxed to the WEP
managers.
If any other string is present, then this is the
password to be used for the connection.
<RTS> ::= <dialog-mode> \
[<checkpoint-size> <window-size>]
<dialog-mode> ::= "RTS-dialog-mode: " \
("TWA" | "MONOLOGUE") 'CR'
<ckeckpoint-size> ::= "RTS-checkpoint-size: " \
'checkpoint size' 'CR'
<window-size> ::= "RTS-window-size: " \
'window size' 'CR'
<called-connection> ::= "Called-address: " \
<Service-type> "; " \
<P-address> "; " <MTS> 'CR'
<MTS> ::= "MTS-T" | "MTS-TP" | "MTS-TP-84"
MTS-T: mts-transfer
MTS-TP: mts-transfer-protocol
MTS-TP-84: mts-transfer-protocol-1984
See ISO 10021-6, Section 3, chapter 11.1 for more
details on this matter. X.400(84) systems only support
mts-transfer-protocol-1984.
Eppenberger Expires: May 1993 [Page 12]
INTERNET-DRAFT Routing Coordination for X.400 Services November 1992
<calling-connection> ::= "Calling-address: " \
<Service-type> "; " \
<P-address> 'CR'
Since called and calling network addresses may differ
in certain configurations and some X.400 systems do
validation on calling network addresses, it is
important to have this information in the WEP document.
(Note: a calling X.121 address might change if the X.25
switch is reconfigured. This will stop a WEP from
connecting to other WEPs using address validation
without having changed anything at the higher layers!)
<system> ::= "System: COM=" 'computer type' "; " \
"OPS=" 'operating system' "; " \
"MHS=" 'MHS software' 'CR'
It is optional to provide HW/SW information.
Experience,however, has shown that a number of
communication problems were more easily identified and
solved with this information present and up-to-date.
<local-domain> ::= "LocalDomain: " <MHS-subtree> 'CR'
This is a useful but optional extension to the
documentation. Such an address should be routed through
the WEP or even end up on the WEP. This is not a
routing definition! The LocalDomain attributes might be
used together with S=nosuchuser to do connectivity and
availability tests.
<echo-server> ::= "EchoServer: " <X.400 address> 'CR'
Some of the WEPs might offer an echo server
functionality. It does make sense to document this in
the WEP document for test purpose. This field is
optional.
<contact-info> ::= {"Administrator: " <UniquePersonKey> 'CR'}
The contact details for the WEP administrator can be
found in the appropriate PERSON document. It is
possible to document a whole team using a distribution
list if this is desired. It is generally better to
document one or more 'real' persons.
5.4 The DOMAIN document
<DOMAIN-document> ::= <Community-Identifier> \
<Update-info> \
<DOMAIN-document-body>
<DOMAIN-document-body>::= {<Domain-entry>} <responsible> \
{<relay-WEP>}
<Domain-entry> ::= "Domain: " <OR-matching> <MHS-subtree> 'CR'
Eppenberger Expires: May 1993 [Page 13]
INTERNET-DRAFT Routing Coordination for X.400 Services November 1992
<OR-matching> ::= ( "* " | "= " )
This qualifier defines how the following OR address
attributes should be handled for the routing algorithm.
If a '*' is present, a destination address of a message
is matched by the "Domain:" entry if at least the OR
address attributes in the "Domain:" entry are equal to
the destination address.
If a "=" is present, a destination address of a message
is matched by the "Domain:" entry if there are exactly
the same OR attributes in the destination address as in
the "Domain:" entry. (This restriction works for OU*,
O, P, A and C only.)
Example:
a) Domain: * P=switch; A=arcom; C=ch;
b) Domain: = P=switch; A=arcom; C=ch;
The address S=eppenberger; P=switch; A=arcom; C=ch;
matches both cases, a) and b).
The address S=eppenberger; O=unibe; P=switch; A=arcom;
C=ch; matches only case a).
Note that it is not allowed to have equal <MHS-subtree>
lines in different DOMAIN documents belonging to the
same MHS community. An MHS subtree can only appear in
one DOMAIN document.
<responsible> ::= {"Administrator: " <UniquePersonKey> 'CR'}
This is the person responsible for the listed domains.
His task is to get the agreement of the relaying WEPs
and keep the DOMAIN document up-to-date. This person is
the only one authorized to make changes to this
document.
<relay-WEP> ::= "WEP: " \
'UniqueWEPkey' "; " \
<Default-Priority> "; " \
<Delay> 'CR' \
[ { "Net: " <Service-type> "; " \
<Priority> 'CR' } ]
A WEP has a default priority and a delay field. The
priority is used to define the sequence in which
different WEPs may be tried in case of failure.
The delay defines how long a sending WEP needs to wait
until it is allowed to select this WEP in case the
connection to the preferred WEP has failed.
It is also possible to set different priorities on each
network type. This may be chosen, for example, to
distribute the load amongst different networks
according to their available bandwith.
<Default-Priority> ::= <Number 0..infinite>
<Priority> ::= <Number 0..infinite>
Eppenberger Expires: May 1993 [Page 14]
INTERNET-DRAFT Routing Coordination for X.400 Services November 1992
<Delay> ::= <Minutes 0..infinite>
The exact meaning of these values and how they should
be used is explained in the next section.
5.5 The PERSON document
<PERSON-document> ::= <Community-Identifier> \
<Update-info> \
<PERSON-document-identifier> \
<PERSON-document-body>
<PERSON-document-identifier> ::= "Key: " <UniquePersonKey> 'CR'
<PERSON-document-body>::= <Name> {<EMail>} {<RFC822>} \
<Phone> <Fax> <Mail> <Operation>
<Name> ::= "Name: " 'name of person' 'CR'
The name of the person is given. The issue of the
character set problem is not addressed in this
document. Especially international communities should
restrict themselves to IA5.
<RFC822> ::= "RFC822: " <RFC-822-address> 'CR'
This is the RFC-822 address of the person. It is often
a big help to know the RFC822 address of someone, for
example if the X.400 system is not reachable. This is
also the reason why it is possible to provide multiple
OR and RFC822 addresses. The first one is considered
the primary one.
<Operation> ::= "Reachable: " {<time> "-" <time> "; "} \
<Time-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.
Eppenberger Expires: May 1993 [Page 15]
INTERNET-DRAFT Routing Coordination for X.400 Services November 1992
6 Routing rules
** 1 **
Every WEP must accept connections on its documented service types
(network and protocol stacks) from all other WEPs in the MHS
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
one MHS domain to another of the same community are replyable.
** 4 **
A message arriving at a WEP must either be sent to the next WEP
based on the DOMAIN documents of the MHS community or it is sent to
an MTA closer to the destination based on local know-how. The
following algorithm must be used when relaying a message to the next
WEP:
1 Match the Recipient address in the message with the longest
fitting MHS subtree from the DOMAIN documents. (The value on the
line starting with the key "Domain:".) Also get the list of WEPs
relaying to this MHS subtree.
If your own WEP appears in this list, this indicates one of the
following:
Eppenberger Expires: May 1993 [Page 16]
INTERNET-DRAFT Routing Coordination for X.400 Services November 1992
- You offered relay services for another WEP with higher priority.
Continue with step 2 to decide on the next WEP.
- Your WEP is the final destination according the DOMAIN document
of your community. You need to forward the message to the final
destination according local routing information.
2 From the list of WEPs for the obtained MHS subtree select those
that can be reached directly. (Based on the information in the WEP
documents beginning with "Called:".)
3 Now decide if you want to send to secondary WEPs too. If you
decide to use primary WEPs only for your routing, then delete all
secondary WEPs from the list.
4 Select from this reduced set of WEPs the one with the highest
default priority. If there is more than one WEP having the same
priority, then select a WEP at random. If your own WEP appears in
that list then you are not allowed to send to a WEP with lower or
equal priority.
5 If there are no other lines indicating which service type to use,
you are free to choose the service type for connecting to the WEP.
However, if there are specific priorities set then select the
network with the highest priority.
6 If the connection fails then try other connections in the sequence
of descending priority.
7 If no connection works for the selected WEP, then check in the
list for the one with the same priority, if possible, or else
select one with the next lower priority. Retry establishing the
connection to the first WEP until the number of minutes indicated
in the delay field for the second WEP has passed, then switch to
the second WEP. Go to step 5 to proceed with the selection of the
connection type.
6.1 How to use priorities
An example helps to explain the usage of priorities.
Internet/TCP/RFC1006 and Public-X.25/X.25/TP0 are mandatory
service types in the community REMOTEmail. The MHS domain
C=CH;ADMD=ARCOM;PRMD=REMOTE operates WEP-B, only connected to
public X.25. A second WEP which is connected to both, Internet and
public X.25 is needed to offer relay services. A connection using
Internet is considered cheap, somebody else pays the leased lines.
Both service types are available at WEP-A. Since WEP-B is the only
WEP responsible for relaying messages to
C=CH;ADMD=ARCOM;PRMD=REMOTE to the final destination it must have
the highest prioriy.
Eppenberger Expires: May 1993 [Page 17]
INTERNET-DRAFT Routing Coordination for X.400 Services November 1992
Community: REMOTEmail
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 |
+-------+
WEP-A needs to relay a message for C=CH;ADMD=ARCOM;PRMD=REMOTE.
Rule **4** is evaluated step by step:
1 WEP-B and WEP-C are possible destinations
2 WEP-B and WEP-C are reachable from WEP-A
3 WEP-B is a primary WEP (not relevant in this example)
4 WEP-B has the highest priority.
5 WEP-B doesn't have specific service type lines documented.
WEP-A chooses public X.25, since it is the only possibility
to connect to WEP-B.
The organization running WEP-A could save money by sending
messages for the MHS domain C=CH;ADMD=ARCOM;PRMD=REMOTE via WEP-C.
Since the connection between WEP-C and the destination WEP-B is
also expensive, the organization running WEP-C would have to pay
for external relay traffic. Setting a lower priority for WEP-C
forces the other WEPs with public X.25 connectivity to take their
share of the cost.
Note that forcing other WEPs to use a specific stack should be
avoided wherever possible by offering WEPs with equal priority for
all mandatory network services. This can be an important financial
issue for MHS communities spanning several organisations, it is
not relevant in general for an MHS community within a single
organisation.
Eppenberger Expires: May 1993 [Page 18]
INTERNET-DRAFT Routing Coordination for X.400 Services November 1992
6.2 How to use delays
Two WEPs offer real backup connectivity for the MHS domain
C=CH;ADMD=ARCOM;PRMD=REMOTE. It is therefore possible to set the
delay to zero for both WEPs. WEP-B will be the preferred one since
it has the higher priority. If the connection to WEP-B fails, a
sending WEP may immediately try to connect to WEP-C.
Community: REMOTEmail
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
___________________________
+-------+ +-------+ ( )
| WEP-A +-------------+ WEP-B +-(C=CH;ADMD=ARCOM;PRMD=REMOTE)
+-------+ +-------+ (___________________________)
\ /
\ +-------+
-----------+ WEP-C |
+-------+
The next case is the same as in section 6.1. By setting the
delay to 120 minutes for WEP-C the sending WEP retries
establishing a connection for two hours until it is allowed to
send messages to WEP-C.
Community: REMOTEmail
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.
Eppenberger Expires: May 1993 [Page 19]
INTERNET-DRAFT Routing Coordination for X.400 Services November 1992
6.3 Load Sharing
It is possible to set equal priorities to do some sort of load
sharing. However, most implementations are not able to do random
selection of WEPs with equal priorities but have a fixed
configuration. If load sharing is really needed then it is
suggested to split up the MHS domain into several subdomains and
document them separately with a set of WEPs with different
priorities.
An example is provided for illustration of the first possibility
with equal priorities:
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; 9; 0
_ ___________________________
) +-------+ ( )
)--+ WEP-B +--(C=CH;ADMD=ARCOM;PRMD=REMOTE)
) +-------+ (___________________________)
) /
) +-------+/
)--+ WEP-C |
_) +-------+
And here is an example where the MHS domain
C=CH;ADMD=ARCOM;PRMD=REMOTE;O=Big-Org is documented with its own
DOMAIN document: Note that both WEPs serve as backup WEPs.
Community: REMOTEmail
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; 0
_ ___________________________
) +-------+ ( )
)--+ WEP-B +--(C=CH;ADMD=ARCOM;PRMD=REMOTE)
) +-------+ (___________________________)
) \/
) /\ _____________________________________
) +-------+ ( )
)--+ WEP-C |--(C=CH;ADMD=ARCOM;PRMD=REMOTE;O=Big-Org)
_) +-------+ (_____________________________________)
Eppenberger Expires: May 1993 [Page 20]
INTERNET-DRAFT Routing Coordination for X.400 Services November 1992
A third example shows a similar load sharing agreement as the
previous one but it uses different delay values since WEP-B
doesn't have direct connectivity to the MHS domain
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
Security considerations are not discussed in this memo.
Eppenberger Expires: May 1993 [Page 21]
INTERNET-DRAFT Routing Coordination for X.400 Services November 1992
Appendix A Document examples for the COSINE-MHS community
Instead of creating artificial documents to show an example
document set this appendix contains extracts from a real operational
X.400 service. The research and development community in Europe uses
X.400 since several years. This proposal has initially been written
to address this community only and solve the urgent routing and
coordination problems. Contributions from different experts made it
more flexible and therefore hopefully useful for other MHS
communities.
Appendix A1 The COMMUNITY document
Community: COSINE-MHS
# The COSINE-MHS service is a MHS community formed by the European
# academic and research networks with additional contacts in all
# other continents.
# The coordination is done by the COSINE-MHS project team.
#
Update: DATE=921111; START=930201
#
Address: S=Project-Team; OU=COSINE-MHS; O=SWITCH; P=SWITCH
A=ARCOM; C=CH;
Phone: +41 1 2623143
FAX: +41 1 2623151
Mail: SWITCH Head Office/COSINE-MHS Project Team/
Limmatquai 138/ CH-8001 Zurich/Switzerland
#
Mail-server: S=COSINE-MHS-SERVER; OU=COSINE-MHS; O=SWITCH;
P=SWITCH; A=ARCOM; C=CH;
FTP-server: nic.switch.ch; cosine-mhs; 'your email address'
#
Macro: Int-X25(80) TELEX+00728722+X25(80)+01+
Macro: Internet-RFC-1006 TELEX+00728722+RFC-1006+03+
#
Mandatory-Service: Public-X.25/X.25/TP0
# The public X.25 network. X.25 is supported in most X.400
# applications and mandatory in X.400 anyhow.
#
Mandatory-Service: Internet/TCP/RFC1006
# The Internet, standing for the global TCP/IP network of the
# research and development community
# RFC1006 is considered a solution to ease migration to OSI. It will
# be replaced by TP4/CLNS as soon as a reliable service is
# available.
#
Optional-Service: RARE-CLNS/CLNS/TP4
# The RARE Connectionless pilot service. Current participants are
# NORDUnet, SURFnet, CERN, NSFnet and SWITCH.
#
Optional-Service: RARE-IXI/X.25/TP0
# The International X.25 Infrastructure covering most countries in
# Europe. The absence of volume tariffs make it a preferred choice.
Eppenberger Expires: May 1993 [Page 22]
INTERNET-DRAFT Routing Coordination for X.400 Services November 1992
Appendix A2 Example of a WEP document
Community: COSINE-MHS
#
Update: DATE=921111; START=930201
#
WEP: P=SWITCH; A=ARCOM; C=CH; MTAname=vms.switch
#
Status: primary
Password: ***none***
RTS-dialog-mode: TWA
#
Called-address: Public-X.25/X.25/TP0;
Int-X25(80)=22847971014110; MTS-TP-84
Calling-address: Public-X.25/X.25/TP0;
Int-X25(80)=22847971014
#
Called-address: Internet/TCP/RFC1006;
Internet-RFC-1006=130.59.1.1; MTS-TP-84
Calling-address: Internet/TCP/RFC1006;
Internet-RFC-1006=130.59.1.1
#
System: COM=DEC VAX4000-300; OPS=VMS 5.4; MHS=DFN-EAN V2.2+
#
LocalDomain: O=switch; P=switch; A=arcom; C=ch;
#
EchoServer: S=echo; O=switch; P=switch; A=arcom; C=ch;
#
Administrator: CN=Christoph Graf, O=SWITCH, C=CH
Administrator: CN=Urs Eppenberger, O=SWITCH, C=CH
#
Eppenberger Expires: May 1993 [Page 23]
INTERNET-DRAFT Routing Coordination for X.400 Services November 1992
Appendix A3 Example of a DOMAIN document
Community: COSINE-MHS
#
Update: DATE=921111; START=930201
##
Domain: P=SWITCH; A=ARCOM; C=CH;
Domain: P=SANDOZ; A=ARCOM; C=CH;
Domain: P=ABB; A=ARCOM; C=CH;
Domain: P=UBS; A=ARCOM; C=CH;
Domain: P=ISREC; A=ARCOM; C=CH;
Domain: P=ALCATEL; A=ARCOM; C=CH;
Domain: P=ITU; A=ARCOM; C=CH;
Domain: P=OSILABMAIL; A=ARCOM; C=CH;
Domain: P=WHO; A=ARCOM; C=CH;
Domain: P=CERN; A=ARCOM; C=CH;
Domain: P=CERBERUS; A=ARCOM; C=CH;
#
Administrator: CN=Christoph Graf, O=SWITCH, C=CH
Administrator: S=postmaster; O=SWITCH; P=SWITCH; A=ARCOM; C=CH;
#
WEP: P=SWITCH; A=ARCOM; C=CH; MTAname=vms.switch; 20; 0
Net: Internet/TCP/RFC1006; 9
Net: Public-X.25/X.25/TP0; 8
#
WEP: P=SWITCH; A=ARCOM; C=CH; MTAname=chx400.switch.ch; 10; 10
Net: Internet/TCP/RFC1006; 20
Net: Public-X.25/X.25/TP0; 10
Appendix A4 Example of a PERSON document
Community: COSINE-MHS
#
Update: DATE=921111; START=930201
#
Key: CN=Christoph Graf, O=SWITCH, C=CH
#
Name: Christoph Graf
#
Address: S=Graf; O=SWITCH; P=SWITCH; A=ARCOM; C=CH;
RFC822: Graf@switch.ch
#
Phone: +41 1 2565454
Fax: +41 1 2618133
#
Mail: SWITCH Head Office/
Christoph Graf/
Limmatquai 138/
CH-8001 Zurich/
Switzerland
#
Reachable: 09:00-12:00; 14:00-17:30; UTC-1
Eppenberger Expires: May 1993 [Page 24]
INTERNET-DRAFT Routing Coordination for X.400 Services November 1992
Appendix B OR Address Representation
This Appendix defines the OR address representation to be used
throughout the documents.It is based NIC@NIC.DDN.MIL. Unless
specifically noted otherwise on the following CCITT
recommendation
Annex to CCITT Rec. F.401 and ISO/IEC 10021-2
ANNEX F REPRESENTATION OF O/R ADDRESSES FOR HUMAN USAGE
and on a document written by Paul-Andre Pays which defines a
subset of the CCITT recommendation to limit the options and
automatic processable addresses. The definitions for the routing
documents is even more strict than proposed by P-A Pays which allows
for easier parsing tools.
Only printable string is allowed for values of OR attributes in
the routing documents.
O/R addresses in labelled format consist of delimited pairs of
labels and values in the syntax <label>"="<value>;. The labels for
each attribute RFC itself, all RFCs are specified in Tables T-1 and T-2. The label and
its value must be separated by the character "=". The value is case
insensitive.
The ADMD attribute must always be present even if its value
consists only of a single space.
The label for a DDA consists of "DDA:" followed by the DDA type.
If an address includes more than one DDA of the same type, it is
assumed that the DDAs are intended to be processed in the sequence
in which they are represented. If the value of a DDA type includes
the character "=", this should be represented by "==".
Label/value pairs appear in sequence on a line, they should be
delimited by ";". (The ";" character is not in the set of printable
strings which makes it an excellent choice as delimiter. No escaping
is needed as
unlimited distribution.
Submissions for the '=' character.)
Each ';' must be followed by white space.
The sequence of attributes must be the one given in the tables T-1
and T-2.
Eppenberger Expires: May 1993 [Page 25]
INTERNET-DRAFT Routing Coordination Requests for X.400 Services November 1992
Attribute Type Label
X.121 Network Address X.121
E.164 Network Address E.164
PSAP Network Address PSAP
User Agent Numeric ID N-ID
Terminal Identifier T-ID
Terminal Type T-TY
Domain Defined Attribute DDA:<type>
where the notation <type> identifies the type of domain defined
attribute.
There are currently six terminal types, and if international
consistency is required the following specific abbreviations Comments should be used sent to represent the values for these types: tlx,
ttx, g3fax, g4fax, ia5 and vtx.
Table T-1. Other Attributes
Attribute Type Label
Given Name G
Initials I
Surname S
Generation Qualifier Q
Common Name CN
Organisation O
Organisational Unit 1 OU1
Organisational Unit 2 OU2
Organisational Unit 3 OU3
Organisational Unit 4 OU4
Private Management Domain Name P
Administration Management Domain Name A
Country C
Table T-2. Standard Attributes of the Mnemonic Address Form
Examples:
G=john; S=smith; O=a bank ltd; P=abl; A=snomail; C=aq;
G=Daniel; S=terrer; P=inria; A=atlas; C=FR;
S=terrer; OU1=mirsa; P=inria; A=atlas; C=FR;
DDA:RFC-822=we(a)sell-it.com; P=internet; A= ; C=fi;
Eppenberger Expires: May 1993 [Page 26]
INTERNET-DRAFT Routing Coordination
RFC-EDITOR@ISI.EDU. Please consult RFC 1111, "Instructions to RFC
Authors", for X.400 Services November 1992
Author's Address
Urs Eppenberger
SWITCH Head Office
Limmatquai 138
CH-8001 Zurich
Switzerland
Phone: +41 1 261 8112
EMail: Eppenberger@switch.ch
S=Eppenberger; O=SWITCH; P=SWITCH; A=ARCOM; C=CH;
Eppenberger Expires: May 1993 [Page 27] further information.
Joyce K. Reynolds
USC/Information Sciences Institute
----