We will first define the scope and purpose of X.400. Here we will explain what X.400 is and what it aims to do. We will also explain where X.400 fits into the OSI model for data communications.
With the introduction of the CCITT X.400 recommendations on message handling systems, the aim was to supply a single international standard for the electronic interchange of messages.
With the massive and continuing growth in the internet and its associated protocols (more on these later), one might think that, for better or worse, it is unlikely that another protocol will displace it (in the near future in any case) as the primary means for exchanging electronic mail messages. This may be the case - but the fact remains that there are several other substantial networks out there and the internet mail protocols were not designed with generality and connectivity with other systems in mind.
There is a clear need to have a common international standard which can be used
as a mechanism to glue together the disjoint services in order to provide a
single coherent global electronic mail service.
The Standards
There are two versions of the X.400 reccommendations - those published in
1984 and those published in 1988:
Reccommnedations X.400, October 1984. CCITT SG 5/VII, Message Handling Systems: System Model - Service Elements.
CCITT recommendations X.400/ISO10021, April 1988. CCITT SG 5/VII ISO/IEC JTC1, Message Handling: System and Service Overview.
The standards define how Message Transfer Agents can operate together to provide an end-to-end Message Transfer Service. Specifically, they describe how the message transfer service may be used to provide an InterPersonal Messaging (IPM) Service (ie. Electronic Mail).
The standards are designed to work over the OSI communications stack. It uses the application layer elements of service defined in (???). It uses the Association Control Service Entity (ACSE) to establish connections and either the Remote Operations Service Entity (ROSE) or the Reliable Transfer Service Entity (ROSE) to transfer the messages. (These are accessed through several new service entities for X.400 - eg. the Message Transfer Service Entity (MTSE) - see the protocols section for more information).
The standards use the OSI request/indication view of protocols, that is, one of the entities originates a request whihc is then received as an indication on the other side of the link; for example a P7 MS-Bind operation could be seen as follows:
Put some more stuff here - detail individual standards in documents etc.
Comceptually, the model looks something like this (click on component or
protocol in image to go directly to description):
From the users, point of view, immediate interaction with the system is carried
out through a User Agent . The user agent allows the user
to compose, submit, and receive mail messages. It is worth noting that the
messages that a user can receive are not neccessarily IPM's - even if the
user is only using P2/P22 , he can also receive
receipt (and non-receipt)
notifications, and delivery reports. In addition, other standards exist for
the format of messages and more might well be invented in the future should
the need arise. (For example, a standard has already been defined for the
sending of EDI messages over X.400 (called Pedi or P35, defined in X.435)
- a P35 user agent will typically be
very different from a P2 user agent from the users point of view, but the
mechanisms used to transmit these EDI messages are essentially the same as
those used in the transport of P2 messages). (MGMT - add link to EDI page).
The actual transmission of messages is done via a
Mesage Transfer Agent (MTA) .
These perform all the routing and delivery functions needed.
One difficulty with the original X.400-84 standard was the the neccessity of
having the user agent available from the MTA at all times to avoid spurious
non-delivery problems. This problem was addressed in the 1988 standard by
the introduction of the
Message Store (MS) into the model. The message store
is available to the MTA at all times (often co-located) and supplies a
store and forward service to the User Agent. This is particularly useful
in the more distributed modern environment where the User Agent may be running
on a users personal machine and hence might not be available for long
periods of time.
Thus, in the 1988 model, the MTA delivers the message to the Message store,
which may well store the message for a considerable period of time, an option
not available to the high-traffic MTA, and which is outside the scope of the
service the MTA is supposed to provide.
The user may then connect to the message store at any time
and fetch the messages stored for him/her by the Message Store. When this system
is used, the user typically conducts all his business through the message store,
including message submission. This has lead to the increasing use (and
importance) of the P7 protocol (see below).
Click here for a more detailed overview of
the model components.
The Protocols defined by the standard are:
The P1 protocol is an end-to-end message transfer service. The P3 protocol
is a protocol for communication between User Agents and MTA's. The P7 protocol
is an increasingly widely used protocol for communication between the User
Agent and the Message Store. Typical P7 operations are:
The P2/P22 protocol defines the format of a highly strucutured memo-like
document. The two main components are the heading and the body part(s).
The heading specicifies things like the originator and recipient of the message,
copy and blind copy recipients of the message, whether the originator wishes
to receive a notification for the message and in what circumstances etc.
The body part may be one of many forms of data - those specified by the
standard include Ia5 text, G3Fax, Images, Audio data etc.
Messages may also be encapsulated within messages, providing a very clean
and strucutured forwarding mechanism.
Click here for a more detailed overview of the
protocols.
The main competitor at the moment to the OSI protocols are the equivalent
Internet Protocols (Not to be confused with IP!).
The main strength of these standards in the past has been their simplicity,
implementability and the accessability and readability of the standards
documents themselves. They have also benefited from the ethos of free
software, services and information that has been responsible for much
of the success of the Internet.
However, one would have to say that
the present time, the single greatest advantage of these protocols is
their enormous user base - with an estimated 20 million people on the
net (with more joining all the time), most of whom would consider electronic
mail to be the most basic (and important) service provided by the internet,
the chances of another protocol family displacing them in the near future are
slim.
The main Internet standards in relation to electronic mail are:
Comparison of X.400 to the Internet Mail Protocols.
( Warning these
are the authors personal opinions only and should be treated as such. As
with Marshall.T. Rose, purists from either side would be advised to stay clear.)
The X.400 MHS/MOTIS model
In this section we detail the main components of the X.400 model for the
interchange of electtronic mail messages - their purpose an and the services
they provide, and the protocols used to communicate between the various
compenents.
X.400 Components
The main components of the model are:
X.400 Protocols
The Internet Mail Protocols
Links
This page created by:
Gavin Doherty,
gdoherty@alf2.tcd.ie