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) evolved as a messaging standard on the DARPA (the US Defense
Advanced Research Projects Agency) Internet. It specifies and end to
end message format. It is used in conjunction with a number of
different message transfer protocol environments.
SMTP Networks
On the DARPA 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 920 which is a Specification for domains and a
distributed name service [Postel84a].
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 920, but not the corresponding domain
nameservers [Horton86a].
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. Subject to 1), 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 defines 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
822std11(-> 2822prop) 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 primary goal of this specification is to support single mappings,
so that X.400 and RFC 822std11(-> 2822prop) users can communicate with maximum
functionality.
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)).
Some RFC 822std11(-> 2822prop) networks may wish to use X.400 as an interconnection
mechanism (typically for policy reasons), and this is fully
supported.
Where an X.400 messages transfers to RFC 822std11(-> 2822prop) and then back to X.400,
there is no expectation of X.400 services which do not have an
equivalent service in standard RFC 822std11(-> 2822prop) being preserved - although
this may be possible in some cases.
1.6. X.400 (1984)
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)), which defined a mapping between
X.400(1984) and RFC 822std11(-> 2822prop). A basic decision is that the mapping
defined in this document is to the full 1988 version of X.400, and
not to a 1984 compatible subset. New features of X.400(1988) can be
used to provide a much cleaner mapping than that defined in RFC 987(-> 2156prop | 1327(-> 2156prop)).
This is important, to give good support to communities which will
utilise full X.400 at an early date. To interwork with 1984
systems, Appendix G shall be followed.
If a message is being transferred to an X.400(1984) system by way of
X.400(1988) MTA it will give a slightly better service to follow the
rules of Appendix G.
The changes between this and older versions of the document are given
in Appendices I and J. These are RFCs 987(-> 2156prop | 1327(-> 2156prop)), 1026(-> 2156prop | 1327(-> 2156prop)), 1138(-> 2156prop | 1327(-> 2156prop)), and 1148(-> 2156prop | 1327(-> 2156prop)).
This document is a revision of RFC 1148(-> 2156prop | 1327(-> 2156prop)) [Kille90a]. As far as
possible, changes have been made in a compatible fashion.
1.8. 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
- Mapping X.400 to extended versions of RFC 822std11(-> 2822prop), with support
for multimedia content.
The first two of 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(-> 2156prop | 1327(-> 2156prop))(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. Some optional and
limited extensions in this area have proved useful, and are defined
in Appendix H.
1.9. 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.10. 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 eleven appendices.
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.11. Acknowledgements
The work in this specification was substantially based on RFC 987(-> 2156prop | 1327(-> 2156prop)) and
RFC 1148(-> 2156prop | 1327(-> 2156prop)), which had input from many people, who are credited in the
respective documents.
A number of comments from people on RFC 1148(-> 2156prop | 1327(-> 2156prop)) lead to this document.
In particular, there were comments and suggestions from: Maurice
Abraham (HP); Harald Alvestrand (Sintef); Peter Cowen (X-Tel); Jim
Craigie (JNT); Ella Gardener (MITRE); Christian Huitema (Inria); Erik
Huizer (SURFnet); Neil Jones DEC); Ignacio Martinez (IRIS); Julian
Onions (X-Tel); Simon Poole (SWITCH); Clive Roberts (Data General);
Pete Vanderbilt SUN); Alan Young (Concurrent).
