1. Chapter 1 -- Overview
This document relates to the CCITT 1988 X.400 Series Recommendations
/ ISO IEC 10021 on the Message Oriented Text Interchange Service
(MOTIS). This ISO/CCITT standard is referred to in this document as
"X.400", which is a convenient shorthand. Any reference to the 1984
CCITT Recommendations will be explicit. X.400 defines an
Interpersonal Messaging System (IPMS), making use of a store and
forward Message Transfer System. This document relates to the IPMS,
and not to wider application of X.400. It is expected that X.400
will be implemented very widely.
1.2. RFC 822std11(-> 2822prop)
RFC 822std11(-> 2822prop) is the current specification of the messaging standard on the
Internet. This standard evolved with the evolution of the network
from the ARPANET (created by the Defense Advanced Research Projects
Agency) to the Internet, which now involves over 1000 networks and is
sponsored by DARPA, NSF, DOE, NASA, and NIH. It specifies an end to
end message format. It is used in conjunction with a number of
different message transfer protocol environments.
SMTP Networks
On the Internet and other TCP/IP networks, RFC 822std11(-> 2822prop) is used in
conjunction with two other standards: RFC 821std10(-> 2821prop), also known as
Simple Mail Transfer Protocol (SMTP) [Postel82a], and RFC 1034std13
which is a Specification for domains and a distributed name
service [Mockapetris87a].
UUCP Networks
UUCP is the UNIX to UNIX CoPy protocol, which is usually used
over dialup telephone networks to provide a simple message
transfer mechanism. There are some extensions to RFC 822std11(-> 2822prop),
particularly in the addressing. They use domains which conform
to RFC 1034std13, but not the corresponding domain nameservers
[Horton86a].
Csnet
Some portions of Csnet follow the Internet protocols. The
dialup portion of Csnet uses the Phonenet protocols as a
replacement for RFC 821std10(-> 2821prop). This portion uses domains which
conform to RFC 1034std13, but not the corresponding domain
nameservers.
Bitnet
Some parts of Bitnet and related networks use RFC 822std11(-> 2822prop) related
protocols, with EBCDIC encoding.
JNT Mail Networks
A number of X.25 networks, particularly those associated with
the UK Academic Community, use the JNT (Joint Network Team)
Mail Protocol, also known as Greybook [Kille84a]. This is used
with domains and name service specified by the JNT NRS (Name
Registration Scheme) [Larmouth83a].
The mappings specified here are appropriate for all of these
networks.
1.3. The need for conversion
There is a large community using RFC 822std11(-> 2822prop) based protocols for mail
services, who will wish to communicate with users of the IPMS
provided by X.400 systems. This will also be a requirement in cases
where communities intend to make a transition to use of an X.400
IPMS, as conversion will be needed to ensure a smooth service
transition. It is expected that there will be more than one gateway,
and this specification will enable them to behave in a consistent
manner. Note that the term gateway is used to describe a component
performing the protocol mappings between RFC 822std11(-> 2822prop) and X.400. This is
standard usage amongst mail implementors, but should be noted
carefully by transport and network service implementors.
Consistency between gateways is desirable to provide:
1. Consistent service to users.
2. The best service in cases where a message passes through
multiple gateways.
1.4. General approach
There are a number of basic principles underlying the details of the
specification. These principles are goals, and are not achieved in
all aspects of the specification.
1. The specification should be pragmatic. There should not be
a requirement for complex mappings for "Academic" reasons.
Complex mappings should not be required to support trivial
additional functionality.
2. Subject to 1), functionality across a gateway should be as
high as possible.
3. It is always a bad idea to lose information as a result of
any transformation. Hence, it is a bad idea for a gateway
to discard information in the objects it processes. This
includes requested services which cannot be fully mapped.
4. All mail gateways actually operate at exactly one level
above the layer on which they conceptually operate. This
implies that the gateway must not only be cognisant of the
semantics of objects at the gateway level, but also be
cognisant of higher level semantics. If meaningful
transformation of the objects that the gateway operates on
is to occur, then the gateway needs to understand more than
the objects themselves.
5. The specification should be reversible. That is, a double
transformation should bring you back to where you started.
1.5. Gatewaying Model
X.400 defines the IPMS Abstract Service in X.420/ISO 10021-7,
[CCITT/ISO88b] which comprises of three basic services:
1. Origination
2. Reception
3. Management
Management is a local interaction between the user and the IPMS, and
is therefore not relevant to gatewaying. The first two services
consist of operations to originate and receive the following two
objects:
1. IPM (Interpersonal Message). This has two components: a
heading, and a body. The body is structured as a sequence
of body parts, which may be basic components (e.g., IA5
text, or G3 fax), or IP Messages. The heading consists of
fields containing end to end user information, such as
subject, primary recipients (To:), and importance.
2. IPN (Inter Personal Notification). A notification about
receipt of a given IPM at the UA level.
The Origination service also allows for origination of a probe, which
is an object to test whether a given IPM could be correctly received.
The Reception service also allows for receipt of Delivery Reports
(DR), which indicate delivery success or failure.
These IPMS Services utilise the Message Transfer (MT) Abstract
Service [CCITT/ISO88c]. The MT Abstract Service provides the
following three basic services:
1. Submission (used by IPMS Origination)
2. Delivery (used by IPMS Reception)
3. Administration (used by IPMS Management)
Administration is a local issue, and so does not affect this
standard. Submission and delivery relate primarily to the MTS
Message (comprising Envelope and Content), which carries an IPM or
IPN (or other uninterpreted contents). There is also an Envelope,
which includes an ID, an originator, and a list of recipients.
Submission also includes the probe service, which supports the IPMS
Probe. Delivery also includes Reports, which indicate whether a
given MTS Message has been delivered or not.
The MTS is REFINED into the MTA (Message Transfer Agent) Service,
which define the interaction between MTAs, along with the procedures
for distributed operation. This service provides for transfer of MTS
Messages, Probes, and Reports.
1.5.2. RFC 822std11(-> 2822prop)
RFC 822std11(-> 2822prop) is based on the assumption that there is an underlying
service, which is here called the 822-MTS service. The 822-MTS
service provides three basic functions:
1. Identification of a list of recipients.
2. Identification of an error return address.
3. Transfer of an RFC 822std11(-> 2822prop) message.
It is possible to achieve 2) within the RFC 822std11(-> 2822prop) header. Some 822-MTS
protocols, in particular SMTP, can provide additional functionality,
but as these are neither mandatory in SMTP, nor available in other
822-MTS protocols, they are not considered here. Details of aspects
specific to two 822-MTS protocols are given in Appendices B and C.
An RFC 822std11(-> 2822prop) message consists of a header, and content which is
uninterpreted ASCII text. The header is divided into fields, which
are the protocol elements. Most of these fields are analogous to P2
heading fields, although some are analogous to MTS Service Elements
or MTA Service Elements.
Given this functional description of the two services, the functional
nature of a gateway can now be considered. It would be elegant to
consider the 822-MTS service mapping onto the MTS Service Elements
and RFC 822std11(-> 2822prop) mapping onto an IPM, but reality just does not fit.
Another elegant approach would be to treat this document as the
definition of an X.400 Access Unit (AU). Again, reality does not
fit. It is necessary to consider that the IPM format definition, the
IPMS Service Elements, the MTS Service Elements, and MTA Service
Elements on one side are mapped into RFC 822std11(-> 2822prop) + 822-MTS on the other
in a slightly tangled manner. The details of the tangle will be made
clear in Chapter 5. Access to the MTA Service Elements is minimised.
The following basic mappings are thus defined. When going from RFC
822 to X.400, an RFC 822std11(-> 2822prop) message and the associated 822-MTS
information is always mapped into an IPM (MTA, MTS, and IPMS
Services). Going from X.400 to RFC 822std11(-> 2822prop), an RFC 822std11(-> 2822prop) message and the
associated 822-MTS information may be derived from:
1. A Report (MTA, and MTS Services)
2. An IPN (MTA, MTS, and IPMS Services)
3. An IPM (MTA, MTS, and IPMS Services)
Probes (MTA Service) must be processed by the gateway, as discussed
in Chapter 5. MTS Messages containing Content Types other than those
defined by the IPMS are not mapped by the gateway, and should be
rejected at the gateway.
1.5.4. Repeated Mappings
The mappings specified here are designed to work where a message
traverses multiple times between X.400 and RFC 822std11(-> 2822prop). This is often
essential, particularly in the case of distribution lists. However,
in general, this will lead to a level of service which is the lowest
common denominator (approximately the services offered by RFC 822std11(-> 2822prop)).
In particular, there is no expectation of additional X.400 services
being mapped - although this may be possible in some cases.
Much of this work is based on the initial specification of RFC 987(-> 2156prop | 1327(-> 2156prop))
and in its addendum RFC 1026(-> 2156prop | 1327(-> 2156prop)). A basic decision is that the mapping
will be to the full 1988 version of X.400, and not to a 1984
compatible subset. This is important, to give good support to
communities which will utilise full X.400 at an early date. This has
the following implications:
- This document does not obsolete RFC 987(-> 2156prop | 1327(-> 2156prop)), as it has a
different domain of application.
- If a gatewayed message is being transferred to a 1984
system, then RFC 987(-> 2156prop | 1327(-> 2156prop)) should be used. If the X.400 side of
the gateway is a 1988 system, then it should be operated in
1984 compatibility mode. There is no advantage and some
disadvantage in using the new mapping, and later on applying
X.400 downgrading rules. Note that in an environment where
RFC 822std11(-> 2822prop) is of major importance, it may be desirable for
downgrading to consider the case where the message was
originated in an RFC 822std11(-> 2822prop) system, and mapped according to
this specification.
- New features of X.400 can be used to provide a much cleaner
mapping than that defined in RFC 987(-> 2156prop | 1327(-> 2156prop)).
Unnecessary change is usually a bad idea. Changes on the RFC 822std11(-> 2822prop)
side are avoided as far as possible, so that RFC 822std11(-> 2822prop) users do not see
arbitrary differences between systems conforming to this
specification, and those following RFC 987(-> 2156prop | 1327(-> 2156prop)). Changes on the X.400
side are minimised, but are more acceptable, due to the mapping onto
a new set of services and protocols.
A summary of changes made is given in Appendix A.
1.7. Aspects not covered
There have been a number of cases where RFC 987(-> 2156prop | 1327(-> 2156prop)) was used in a manner
which was not intended. This section is to make clear some
limitations of scope. In particular, this specification does not
specify:
- Extensions of RFC 822std11(-> 2822prop) to provide access to all X.400
services
- X.400 user interface definition
These are really coupled. To map the X.400 services, this
specification defines a number of extensions to RFC 822std11(-> 2822prop). As a side
effect, these give the 822 user access to SOME X.400 services.
However, the aim on the RFC 822std11(-> 2822prop) side is to preserve current service,
and it is intentional that access is not given to all X.400 services.
Thus, it will be a poor choice for X.400 implementors to use RFC
987(88) as an interface - there are too many aspects of X.400 which
cannot be accessed through it. If a text interface is desired, a
specification targeted at X.400, without RFC 822std11(-> 2822prop) restrictions, would
be more appropriate.
1.8. Subsetting
This proposal specifies a mapping which is appropriate to preserve
services in existing RFC 822std11(-> 2822prop) communities. Implementations and
specifications which subset this specification are strongly
discouraged.
1.9. Document Structure
This document has five chapters:
1. Overview - this chapter.
2. Service Elements - This describes the (end user) services
mapped by a gateway.
3. Basic mappings - This describes some basic notation used in
Chapters 3-5, the mappings between character sets, and some
fundamental protocol elements.
4. Addressing - This considers the mapping between X.400 O/R
names and RFC 822std11(-> 2822prop) addresses, which is a fundamental gateway
component.
5. Detailed Mappings - This describes the details of all other
mappings.
There are also six appendices:
A. Differences with RFC 987(-> 2156prop | 1327(-> 2156prop))
B. Mappings Specific to JNT Mail
C. Mappings Specific to UUCP Mail
D. Object Identifier Assignment
E. BNF Summary
F. Format of Address Tables
WARNING:
THE REMAINDER OF THIS SPECIFICATION IS TECHNICALLY DETAILED.
IT WILL NOT MAKE SENSE, EXCEPT IN THE CONTEXT OF RFC 822std11(-> 2822prop) AND
X.400 (1988). DO NOT ATTEMPT TO READ THIS DOCUMENT UNLESS
YOU ARE FAMILIAR WITH THESE SPECIFICATIONS.
1.10. Acknowledgements
This work was partly sponsored by the Joint Network Team. The
workshop at UCL in June 1989 to work on this specification was also
an IFIP WG 6.5 meeting.
The work in this specification was substantially based on RFC 987(-> 2156prop | 1327(-> 2156prop)),
which had input from many people.
Useful comments and suggestions were made by Pete Cowen (Nottingham
Univ), Jim Craigie (JNT), Christian Huitema (Inria), Peter Lynch
(Prime), Julian Onions (Nottingham Univ), Sandy Shaw (Edinburgh
Univ), Einar Stefferud (NMA), and Peter Sylvester (GMD).
