view Side-By-Side changes
Date: Tue, 09 Apr 2002 09:09:41 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Wed, 09 Dec 1992 04:40:00 GMT
ETag: "3dde42-6f02-2b2578a0"
Accept-Ranges: bytes
Content-Length: 28418
Connection: close
Content-Type: text/plain
Network Working Group R. Hagens
Request for Comments: 1649 Advanced Network & Services, Inc.
Category: Informational A. Hansen
UNINETT
July 1994
Operational Requirements for X.400 Management Domains
in the GO-MHS Community
November 10, 1992
Robert A. Hagens
C=US; ADMD= ; PRMD=INTERNET; DDA.RFC-822=hagens(a)ans.net;
hagens@ans.net
Alf Hansen
C=no; ADMD= ; PRMD=uninett; O=sintef; OU=delab; S=Hansen; G=Alf
Alf.Hansen@delab.sintef.no
$ Revision: 1.14 $
Status of this Memo
This document specifies a set of minimal operational
requirements that shall be implemented by all Management
Domains (MDs) in the Global Open MHS Community (GO-MHS) This
document defines the core operational requirements; in some
cases, technical detail is handled by reference to other
documents.
The GO-MHS Community is defined as all organizations which
meet the requirements described in this document.
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 memo provides information for a maximum of
six months. the Internet Drafts may be updated, replaced, or
obsoleted by other documents at any time. It is community. This memo
does 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 specify an Internet Draft directory to learn the current status standard of this
or any other Internet Draft.
When agreement is reached, it will be submitted to the RFC
editor as an informational document. kind. Distribution of
this memo is unlimited. Please send comments to the authors or to
the discussion group:
INTERNET-DRAFT (OPS-1) [Page 1] Exp. Date: 05/10/93
ietf-osi-x400ops@cs.wisc.edu
C=us; ADMD= ; PRMD=xnren; O=UW-Madison; OU=cs; S=ietf-osi-x400ops
Beginning with version 1.9, this document contains change
bars which indicated changes that have been made. Change
bars only reflect the changes from the previous version.
Change bars appear to the right of the text. Deleted text is |
not shown.
Pervasive changes are not denoted with change bars. However,
they are noted at the beginning of the document. Pervasive
changes from version 1.8 to 1.10 are:
o
The phrase "International Service" has been replaced
with "International X.400 Service".
o
References have been cleaned up.
o
Section 2.3 has been extensively rewritten.
Pervasive changes from version 1.10 to 1.13 are:
o
The phrase "International X.400 Service" has been
replaced with GO-MHS Community.
Pervasive changes from version 1.13 to 1.14 are: |
o |
The phrase "IMD" (Internet Management Domain) has been |
replaced with GO-MD (Global Open Management Domain). |
o |
The phrase "Internet mail service" has been replaced |
with RFC-822 mail service. |
o |
The references are cleaned up. |
o |
Section 3.1.2 has been rewritten.
INTERNET-DRAFT (OPS-1) [Page 2] Exp. Date: 05/10/93
1. Introduction
There are several large, operational X.400 services currently
deployed. Many of the organizations in these ser-
vices services are connected
to the Internet. A number of other Internet-connected organizations
are beginning to operate internal X.400 services (for example, U.S.
government organ-
izations organizations following U.S. GOSIP). The motivation for
this document is to foster a GO-MHS Global Open Message Handling System
(GO-MHS) Community that has full interoperability with the existing
E-mail service based on
RFC 822. RFC-822 (STD-11).
The goal of this document is to unite regionally operated X.400
services on the various continents into one GO-MHS Community (as seen
from an end-user's point of view). Exam-
ples Examples of such regional
services are the COSINE MHS Service in Europe and the XNREN service
in the U.S.
A successful GO-MHS Community is dependent on decisions at both the
national and international level. National X.400 service providers
are responsible for the implementation of the minimum requirements
defined in this document. In addi-
tion addition to these minimum requirements,
national requirements may be defined by each national service
provider.
This document refers to other documents which also will be | are published as RFCs.
These documents are:
o Routing coordination for an X.400 MHS-service
within a multi protocol / multi network environment
[1].
o Co-ordination Procedures for RFC 1327 Gateways |
[4]. are [1], [2], [3], [4], [6] and [7] in the reference
list.
This document handles issues concerning X.400 1984 and X.400 1988 to
1984 downgrading. Issues concerning pure X.400 1988 are left for
further study.
Hagens & Hansen [Page 1]
RFC 1649 X.400 Management in GO-MHS July 1994
We are grateful to Allan Cargille and Lawrence Landweber for their
input and guidance on this paper. This paper is also a product of
discussions in the IETF X.400 Operations WG and the RARE WG-MSG
(former RARE WG1 (on MHS). MHS)).
1.1. Terminology
This document defines requirements, recommendations and con-
ventions. conventions.
Throughout the document, the following defini-
tions definitions apply: a
requirement is specified with the word shall. A recommendation is
specified with the word should. A
INTERNET-DRAFT (OPS-1) [Page 3] Exp. Date: 05/10/93 convention is specified with the
word might. Conventions are intended to make life easier for RFC 822 RFC-822
systems that don't follow the host requirements.
1.2. Profiles
Different communities have different profile requirements. The
following is a list of such profiles.
o U.S. GOSIP - unspecified version
o ENV - 41201
o UK GOSIP for X.400(88)
The
In the case when mail traffic is going from the RFC-822 mail service
to the GO-MHS Community, the automatic return of contents when mail
is non-delivered | should be requested by RFC 1327 gateways and should
be sup- |
ported supported at the MTA that generates the non-delivery report. |
However, it should be noted that this practice maximizes the | cost
associated with delivery reports.
2. Architecture of the GO-MHS Community
In order to facilitate a coherent deployment of X.400 in the GO-MHS
Community it is necessary to define, in general terms, the overall
structure and organization of the X.400 service. This section is
broken into several parts which discuss management domains, lower
layer connectivity issues, and overall routing issues.
The GO-MHS Community will operate as a single MHS community, as
defined in reference [1].
2.1. Management Domains
The X.400 model supports connectivity between communities with
different service requirements; the architectural vehi-
cle vehicle for this is
a Management Domain. Management domains are needed when different
administrations have different specific requirements. Two types of
management domains are defined by the X.400 model: an Administration
Hagens & Hansen [Page 2]
RFC 1649 X.400 Management in GO-MHS July 1994
Management Domain (ADMD) and a Private Management Domain (PRMD).
Throughout the world in various countries there are dif-
ferent different
organizational policies for MDs. All of these poli-
cies policies are legal
according to the X.400 standard. Currently,
national X.400 service providers
in a country (inside or outside the GO-MHS Community), are organized
as:
a) One or several ADMDs.
b) One or several PRMDs and with no ADMDs present in
the country. country, or that are not connected to any ADMD.
c) One or several PRMDs connected to one or several ADMDs.
INTERNET-DRAFT (OPS-1) [Page 4] Exp. Date: 05/10/93
Or in combinations of a), b) and c). At this stage it is not
possible to say which model is the most effective. Thus, the GO-MHS
Community shall allow every model.
2.2. The Well Known Entrypoint (WEP) RELAY-MTA
The X.400 message routing decision process takes as input the
destination O/R address and produces as output the name (and perhaps
connection information) of the MTA who will take responsibility of
delivering the message to the reci-
pient. recipient. The X.400 store and forward
model permits a message to pass through multiple MTAs. However, it
is generally accepted that the most efficient path for a message to
take is one where a direct connection is made from the originator to
the recipient's MTA.
Large scale deployment of X.400 in the GO-MHS Community will require
a well deployed X.500 directory infrastructure to support routing. In the
GO-MHS Community X.500 is considered to be the best protocol for such
an infrastructure. In this environment, a routing decision can be
made by searching the X.500 directory with a destination O/R | address in
order to obtain the name of the next hop MTA. This MTA may be a
central entry point into an MD, or it may be the destination MTA
within an MD.
Deployment of X.400 without X.500 a well deployed Directory infrastructure,
will require the use of static tables to store routing information. This table
These tables (keyed on O/R addresses), will be used to map a
destination O/R address to a next hop MTA. In order to facilitate effi-
cient
efficient routing, one could build a table that contains infor-
mation information
about every MTA in every MD. However, this table would be enormous
and very dynamic, so this is not feasible in practice. Therefore, it
is necessary to use the concept of a well known entrypoint (WEP). RELAY-MTA.
The purpose of a WEP RELAY-MTA is to act as a default entry point into an
MD. The MTA that acts as a WEP RELAY MTA for an MD shall be capable of
Hagens & Hansen [Page 3]
RFC 1649 X.400 Management in GO-MHS July 1994
accepting responsibility for all messages that it receives that are
destined for well-defined recipients in that MD.
The use of a WEP RELAY-MTA for routing is defined by reference [1]. WEPs
RELAY-MTAs in the GO-MHS Community shall route according to reference
[1].
2.3. Lower Layer Stack Incompatibilities
A requirement for successful operation of the GO-MHS Commun-
ity Community is
that all users can exchange messages. The GO-MHS Com-
munity Community is not
dependent on the traditional TCP/IP lower layer protocol suite. A
variety of lower layer suites are used as carriers of X.400 messages.
INTERNET-DRAFT (OPS-1) [Page 5] Exp. Date: 05/10/93
For example, consider Figure 1.
figure arch.ps
height 4i
-----------------------------------------------------
! !
! PRMD A !
! -------------------- !
! ! o x ! !
! ! ! !
! ! o w ! !
! ! z ! !
! -------------------- !
! PRMD B !
! ------------------ !
! ! o o ! !
! PRMD C ! o ! !
! ------------------ ! o z ! !
! ! o ! ! ! !
! ! o x ! ------------------ !
! ! o w ! !
! ! o ! !
! ------------------ !
! !
! Key: Each character the in !
! the boxes illustrates an MTA. !
! !
! x: TP0/RFC1006/TCP RELAY-MTA !
! w: TP4/CLNP RELAY-MTA !
! z: TP0/CONS/X.25 RELAY-MTA !
! o: MTA !
-----------------------------------------------------
Figure 1: A Deployment Scenario
Hagens & Hansen [Page 4]
RFC 1649 X.400 Management in GO-MHS July 1994
PRMD A has three WEPs RELAY-MTAs which collectively provide support for
the TP0/CONS/X.25, TP0/RFC1006, and TP4/CLNS stacks[1]
the TP0/CONS/X.25, TP0/RFC1006, and TP4/CLNS stacks. (Note: it is
acceptable for a single RELAY-MTA to support more than one stack.
Three RELAY-MTAs are shown in this figure for clarity.) Thus, PRMD A
is reachable via these stacks. However, since PRMD B only supports
the TP0/CONS/X.25 stack, it is not reachable from the TP0/RFC 1006 or
the TP4/CLNS stack. PRMD C supports TP0/RFC1006 and TP4/CLNS. Since
PRMD B and PRMD C do not share a common stack, how is a message from
PRMD C to reach a recipient in PRMD B ? B?
One solution to this problem is to require that PRMD B implement a
stack in common with PRMD C. However this may not be a politically
acceptable answer to PRMD B.
Another solution is to implement a transport service bridge (TSB)
between TP0/RFC 1006 in PRMD C to TP0/CONS in PRMD B. This will
solve the problem for PRMD C and B. However, the lack of coordinated
deployment of TSB technology makes this answer alone unacceptable on
an international scale.
The solution to this problem is to define a coordinated mechanism
that allows PRMD B to advertise to the world that it has made a
bilateral agreement with PRMD A to support reachability to PRMD B
from the TP0/RFC 1006 stack.
This solution does not require that every MTA or MD directly support
all stacks. However, it is a requirement that if a particular stack
is not directly supported by an MD, the MD will need to make
bilateral agreements with other MD(s) in order to assure that
connectivity from that stack is avail-
able. available.
Thus, in the case of Figure 1, PRMD B can make a bilateral agreement
with PRMD A which provides for PRMD A to relay messages which arrive
on either the TP4/CLNP stack or the TP0/RFC 1006 stack to PRMD B
using the TP0/CONS stack.
The policies described in reference [1] define this general purpose
solution. It is a requirement that all MDs follow the rules and
policies defined by reference [1].
[1] Note: it is acceptable for a single WEP to support
more than one stack. Three WEPs are shown in this picture
for clarity.
INTERNET-DRAFT (OPS-1) [Page 6] Exp. Date: 05/10/93
3. Description of GO-MHS Community Policies
A GO-MD is a Management Domain in the GO-MHS Community.
The policies described in this section constitute a minimum set of
common policies for GO-MDs. They are specified to ensure
interoperability between between:
Hagens & Hansen [Page 5]
RFC 1649 X.400 Management in GO-MHS July 1994
- all GO-MDs.
- all GO-MDs and the RFC-822 mail service (SMTP).
- all GO-MDs and other X.400 service providers.
Policies defined below are defined in terms of the words:
shall, should and might.
3.1. X.400 address registration Address Registration
An O/R address is a descriptive name for a UA that has cer-
tain certain
characteristics that help the Service Providers to locate the UA.
Every O/R address is an O/R name, but not every O/R name is an O/R
address. This is explained in reference [5], chapter 3.1.
Uniqueness of X.400 addresses shall be used to ensure end-
user end-user
connectivity.
Mailboxes shall be addressed according to the description of O/R
names, Form 1, Variant 1 (see reference [5], chapter 3.3.2). The
attributes shall be regarded as a hierarchy of of:
Country name (C)
Administration domain name (ADMD)
[Private domain name] (PRMD)
[Organization name] (O)
[Organizational Unit Names] (OUs)
[Personal name] (PN)
[Domain-defined attributes] (DDAs)
Attributes enclosed in square brackets are optional. At least one of
PRMD, PN, O an O, OU and PN names shall be present in an O/R address. At least
one of PN and DDA shall be present.
In general a subordinate address element shall be unique within the
scope of its immediately superior element. An exception is PRMD, see
section 3.1.2. 3.1.3. There shall exist registration authorities for each
level, or mechanisms shall be available to ensure such uniqueness.
INTERNET-DRAFT (OPS-1) [Page 7] Exp. Date: 05/10/93
3.1.1. Country (C)
The values of the top level element, Country, shall be defined by the
set of two letter country codes, or numeric country codes in ISO
3166.
3.1.2. Administration Management Domain (ADMD)
The values of the ADMD field are decided on a national | basis. Every
national decision made within the GO-MHS com- |
munity community shall be supported
by a GO-MD.
Hagens & Hansen [Page 6]
RFC 1649 X.400 Management in GO-MHS July 1994
3.1.3. Private Management Domain (PRMD)
The PRMD values should be unique within a country.
3.1.4. Organization (O)
Organization values shall be unique within the context of the
subscribed PRMD or ADMD if there is no PRMD. For clarification, the
following situation is legal:
1) C=FI; ADMD=FUMAIL; O=FUNET.
2) C=FI; ADMD=FUMAIL; PRMD=NOKIA; O=FUNET.
In this case 1) and 2) are different addreses. (Note that 2) at this
point is a hypotethical address). O=FUNET is a subscriber both at
ADMD=FUMAIL, 1), and at PRMD=NOKIA, 2).
3.1.5. Organizational units Units (OUs)
If used, a unique hierarchy of OUs shall be implemented. The top
level OU is unique within the scope of the immediately superior
address element (i.e., Organization, PRMD or ADMD). |
Multiple use Use of multiple
OUs may be confusing.
3.1.6. Given name, Name, Initials, Surname (G I S)
Each Organization can define its own Given-names, Initials, and
Surnames to be used within the Organization. In the cases when
Surnames are not unique within an O or OU, The the Given-name and/or
Initial will shall be used to identify the Originator/Recipient. In the
rare cases when more than one user would have the same combination of
G, I, S under the same O and/or OUs, each organization is free to
find a prac-
tical practical solution, and provide the users with unique O/R
addresses.
Either one of Given-name or Initials should be used, not both.
Periods shall not be used in Initials.
To avoid problems with the mapping of the X.400 addresses
into to RFC-822
addresses, the following rules might be used. ADMD, PRMD, O, and OU
values should consist of characters drawn from the alphabet (A-Z),
digits (0-9), and minus. Blank or Space characters should be
avoided. No distinction
INTERNET-DRAFT (OPS-1) [Page 8] Exp. Date: 05/10/93 is made between upper and lower case. The
last character
must shall not be a minus sign or period. The first
character should be either a letter or a digit (see [6], reference [6] and
[7]).
Hagens & Hansen [Page 7]
RFC 1649 X.400 Management in GO-MHS July 1994
3.1.7. Domain Defined Attributes (DDAs)
The GO-MHS Community shall allow the use of domain defined
attributes. Note: support Support for DDAs is mandatory because in the functional
profiles, and all software must upgrade to support DDAs. The
following DDAs shall be supported by a GO-MD:
"RFC-822" - defined in reference [3].
The following DDAs should be supported by a GO-MD:
"COMMON" - defined in reference [2].
3.2. X.400 88 -> 84 downgrading Downgrading
The requirements in reference [2] should be implemented in GO-MDs
3.3. X.400 / RFC 822 RFC-822 address mapping
All GO-MHS Community end-users shall be reachable from all end-users
in the RFC-822 mail service in the Internet (SMTP), and vice versa.
The address mapping issue is split into two parts:
1) Specification of RFC-822 addresses seen from the X.400 world.
2) Specification of X.400 addresses seen from the RFC-822 world.
The mapping of X.400 and RFC-822 addresses shall be per-
formed performed
according to reference [3].
3.3.1. Specification of RFC-822 addresses Addresses seen from the X.400 world World
Two scenarios are described:
A. The RFC-822 end-user belongs to an organization with no defined
X.400 standard attribute address space.
B. The RFC-822 end-user belongs to an organization with a defined
X.400 standard attribute address space.
INTERNET-DRAFT (OPS-1) [Page 9] Exp. Date: 05/10/93
Organizations belong to scenario B if their X.400 addresses are
registered according to the requirements in section 3.1.
3.3.1.1. An organization Organization with a defined X.400 address
space Address Space
An RFC-822 address for an RFC-822 mail user in such an organization
shall look exactly be in the same address space as a normal X.400 address for
X.400 users in the same organization. RFC-822 addresses and X.400
addresses are thus sharing the same address space. Example:
Hagens & Hansen [Page 8]
RFC 1649 X.400 Management in GO-MHS July 1994
University of Wisconsin-Madison is registered under C=US; |
ADMD=Internet; PRMD=XNREN; with O=UW-Madison and they are using OU=cs
to address end-users in the CS-department. The RFC-822 address for
RFC-822 mail users in the same depart-
ment department is: user@cs.wisc.edu.
An X.400 user in the GO-MHS Community will address the RFC-
822 RFC-822 mail
user at the CS-department with the X.400 address: |
C=US; ADMD=Internet; PRMD=xnren; O=UW-Madison; OU=cs; S=user;
This is the same address space as is used for X.400 end-
users end-users in the
same department.
3.3.1.2. An organization Organization with no defined X.400 address
space Address Space
RFC-822 addresses shall be expressed using X.400 domain defined
attributes. The mechanism used to define the RFC-
822 RFC-822 recipient will
vary on a per-country basis.
For example, in the US, U.S., a special PRMD named "Internet" is defined
to facilitate the specification of RFC-822 addresses. An X.400 user
can address an RFC-822 recipient in the U.S. by constructing an X.400
address such as: |
C=us; ADMD=Internet; PRMD=Internet; DD.RFC-822=user(a)some.place.edu;
The first part of this address: |
C=us; ADMD=Internet; PRMD=Internet;
denotes the U.S. portion of the Internet community and not a specific
"gateway". The 2nd part:
DD.RFC-822=user(a)some.place.edu
INTERNET-DRAFT (OPS-1) [Page 10] Exp. Date: 05/10/93
is the RFC-822 address of the RFC-822 mail user after sub-
stitution substitution of
non-printable characters according to reference [3]. The | RFC-822
address is placed in an X.400 Domain Defined Attri-
bute Attribute of type RFC-822 RFC-
822 (DD.RFC-822).
Each country is free to choose its own method of defining the RFC-822
community. For example in Italy, an X.400 user would refer to an
RFC-822 user as:
C=IT; ADMD=MASTER400; DD.RFC-822=user(a)some.place.it
In the UK, an X.400 user would refer to an RFC-822 user as:
Hagens & Hansen [Page 9]
RFC 1649 X.400 Management in GO-MHS July 1994
C=GB; ADMD= ; PRMD=UK.AC; O=MHS-relay; DD.RFC-822=user(a)some.place.uk
3.3.2. Specification of X.400 addresses Addresses seen from the RFC-
822 world RFC-822 World
If an X.400 organization has a defined RFC-822 address space, RFC-822
users will be able to address X.400 reci-
pients recipients in RFC-822/Internet
terms. This means that the address of the X.400 user, seen from an
RFC-822 user, will generally be on of the form:
Firstname.Lastname@some.place.edu
where the some.place.edu is a registered Internet domain.
This implies the necessity of maintaining and distributing address
mapping tables to all participating RFC-987 gate-
ways. RFC-1327 gateways. The mapping
tables shall be globally consistent. Effective mapping table
coordination procedures are needed.
The procedures defined in [4] shall be followed.
If an organization does not have a defined RFC-822 address space, an
escape mapping (defined in reference [3]) shall be used. In this
case, the address of the X.400 user, seen from an RFC-
822 RFC-822 user, will
be on of the form:
"/G=First name/S=Lastname/O=orgname/PRMD=foo/ADMD=bar/C=us/"@
"/G=Firstname/S=Lastname/O=org name/PRMD=foo/ADMD=bar/C=us/"@
some.gateway.edu
Note that reference [7] specifies that quoted left-hand side
addresses must be supported and that these addresses may be greater
than 80 characters long.
This escape mapping shall also be used for X.400 addresses which do
not map cleanly to RFC-822 addresses.
INTERNET-DRAFT (OPS-1) [Page 11] Exp. Date: 05/10/93
It is recommended that an organization with no defined RFC-
822 RFC-822
address space, should register RFC-822 domains at SRI-
NIC. the appropriate
registration entity for such registrations. This will minimize the
number of addresses which must use the escape mapping.
If the escape mapping is not used, RFC-822 users will not see the
difference between an Internet RFC-822 address and an address in the
GO-MHS Community. For example:
The X.400 address:
C=us; ADMD=ATTMail; PRMD=CDC; O=CPG; S=Lastname; G=Firstname;
will from an RFC-822 user look like:
Hagens & Hansen [Page 10]
RFC 1649 X.400 Management in GO-MHS July 1994
Firstname.Lastname@cpg.cdc.com
3.4. Routing policy Policy
To facilitate routing in the GO-MHS Community before an X.500
infrastructure is deployed, the following two tables,
an MTA table documents, a RELAY-MTA
document and a Domain table, document, are defined. These tables documents are
formally defined in reference [1]. The use of these tables documents is
necessary to solve the routing crisis that is present today. However,
this is a temporary solution that will eventually be replaced by the
use of X.500.
The MTA table RELAY-MTA document will define the names of well known MTAs
(WEPs) RELAY-MTAs and their
associated connection data including selec-
tor selector values, NSAP addresses,
supported protocol stacks, and supported X.400 protocol version(s).
Each entry in the Domain table document consists of a sub-tree hierarchy of
an X.400 address, followed by a list of MTAs which are willing to
accept mail for the address or provide a relay service for it. Each
MTA name will be associated with a priority value. Collectively, the
list of MTA names in the Domain table document make the given address
reachable from all protocol stacks. In addition, the list of MTAs may pro-
vide
provide redundant paths to the address, so in this case, the priority
value indicates the preferred path, or the pre-
ferred preferred order in which
alternative routes should be tried.
The MTA RELAY-MTA and Domain tables documents are coordinated by the group
specified in the Community document. The procedures for
table document
information gathering and distribution, are for further study.
INTERNET-DRAFT (OPS-1) [Page 12] Exp. Date: 05/10/93
3.5. Minimum statistics/accounting Statistics/Accounting
The following are not required for all end-MTA. MTAs. The informa- |
tion information is
provided as guidelines for MTA managers, and is |
based on work in [8].
It managers. This is important that certain key statistics be kept by each
MTA. helpful for
observing service use and evaluating service performance.
This section defines the data which must should be kept by each MTA.
There are no constraints on the encoding used to store the data
(i.e., format).
For each message/report passing the MTA, the following information is to
should be collected.
Hagens & Hansen [Page 11]
RFC 1649 X.400 Management in GO-MHS July 1994
The following fields must should be collected.
Date
Time
Priority
Local MTA Name
Size
The following fields are conditionally collected.
From MTA Name (fm)
To MTA Name (tm)
Delta Time (dt)
Message-id (id)
At least one of 'fm' and 'tm' must should be present. If one of 'fm' and
'tm' is not present, 'id' must should be present. If both 'fm' and 'tm'
are present, then 'dt' indicates the number of minutes that the
message was delayed in the MTA. If 'id' cannot be mapped locally
because of log file formats, 'id' is not present and every message
creates two lines: one with 'fm' empty and one with 'tm' empty. In
this case, 'date' and 'time' in the first line represent the date and
time the message entered the MTA. In the second line, they represent
the date and time the message left the MTA.
The following fields are optionally collected.
From Domain (fd)
To Domain (td)
For route tracing, 'fd' and 'td' are useful. They represent X.400
OU's, O, PRMD, ADMD and C and may be supplied up to any level of
detail.
INTERNET-DRAFT (OPS-1) [Page 13] Exp. Date: 05/10/93
4. Community Document
For the GO-MHS community there will exist one single COMMUN- |
ITY COMMUNITY
document containing basic information as defined in reference [1]. |
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 RELAY-MTA and DOMAIN | documents. The GO-MHS community
must agree on its own set of | mandatory and optional networks and
stacks. |
The following is an example of the community document for |
the GO-MHS Community. The example is taken from the current |
definition of the Community Document for the COSINE-MHS com- |
munity.
Community: GO-MHS |
# The GO-MHS community is formed by the X.400 |
# networks in all participating countries. |
#
# The coordination is done by the COSINE-MHS project team.
# Another solution must be found at least by the end of 1992.
Update: DATE=920302
Address: C=CH;ADMD=ARCOM;PRMD=SWITCH;O=SWITCH;
OU=COSINE-MHS;S=Project-Team;
Phone: +41 1 2623143
FAX: +41 1 2623151
Mail: SWITCH Head Office/COSINE-MHS Project Team/Limmatquai 138/
CH-8001 Zurich/Switzerland
#
Mail-server: C=CH;ADMD=ARCOM;PRMD=SWITCH;O=SWITCH;OU=NIC;
S=COSINE-MHS-SERVER;
FTP-server: nic.switch.ch; cosine-mhs; 'your email address'
#
Mandatory-Service: Public-X.25/X.25/TP0
# The public X.25 network. X.25 is supported in most
Hagens & Hansen [Page 12]
RFC 1649 X.400
# applications and mandatory Management 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: NSF-CLNS/CLNS/TP4
# The NSF Connectionless pilot service. Current participants GO-MHS July 1994
5. Security Considerations
Security issues are
# NSFnet as well as many regionals.
Optional-Service: RARE-IXI/X.25/TP0
# The International X.25 Infrastructure covering most countries not discussed in
# Europe. The absence of volume tariffs make it a preferred choice.
INTERNET-DRAFT (OPS-1) this memo.
6. Authors' Addresses
Robert Hagens
Advanced Network & Services, Inc.
1875 Campus Commons Drive
Suite 220
Reston, VA 22091
U.S.A.
Phone: +1 703 758 7700
Fax: +1 703 758 7717
EMail: hagens@ans.net
DDA.RFC-822=hagens(a)ans.net; P=INTERNET; C=US
Alf Hansen
UNINETT
Elgesetergt. 10
Postbox 6883, Elgeseter
N-7002 Trondheim
Norway
Phone: +47 7359 2982
Fax: +47 7359 6450
EMail: Alf.Hansen@uninett.no
G=Alf; S=Hansen; O=uninett; P=uninett; C=no
Hagens & Hansen [Page 14] Exp. Date: 05/10/93 13]
RFC 1649 X.400 Management in GO-MHS July 1994
References
[1] U. Eppenberger, U., Routing coordination Coordination for an X.400 MHS-
service within MHS-Services
Within a multi protocol Multi Protocol / multi network en-
vironment, IETF Internet Draft, "draft-ietf-x400ops-
mhs-service-00.txt". Multi Network Environment, RFC 1465,
SWITCH, May 1993.
[2] S.E. Hardcastle-Kille: X.400 Hardcastle-Kille, S., "X.400 1988 to 1984 downgrading, RFC 1328,
University College London, May 1992.
[3] S.E. Hardcastle-Kille: Mapping Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021
and RFC 822, RFC 1327, May 1992.
[4] Urs Eppenberger, Jeroen Houttuin, Paul Klarenberg, Jim
Romaguera: Co-ordination Procedures Cargille, A., "Postmaster Convention for X.400 Operations", RFC 1327 Gate-
ways, (IETF Internet Draft).
1648, University of Wisconsin, July 1994.
[5] <ref. CCITT Red Book, X.400> International Telecommunications Union, CCITT. Data
Communications Networks, Volume VIII, Message Handling Systems,
ITU: Geneva 1985.
[6] K. Harrenstien, et al. DOD K., Stahl, M., and E. Feinler, "DOD Internet Host
Table Specifi-
cation. Request for Comments Specification", RFC 952, SRI, October 1985.
[7] R. Braden. Requirements Braden, R., "Requirements for Internet Hosts -- Applica-
tion Application and Support. Request for Comments
Support", STD 3, RFC 1123, USC/Information Sciences Institute,
October 1989.
[8] The COSINE MHS Project Team, "Requirements for A Final
Format Of Traffic Statistics"
INTERNET-DRAFT (OPS-1)
Hagens & Hansen [Page 15] Exp. Date: 05/10/93 14]
----