X.400
Click on the red underlined text to get to the source
... X.400 ...
... (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
...
... "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 ...
... 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.
...
... IPMS,
and not to wider application of X.400. It is expected that X.400
will be implemented very widely.
...
... 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 ...
... 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 ...
... 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
...
... X.400 ...
... 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 ...
...
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
...
... IPMS
Services). Going from X.400 to RFC 822std11(-> 2822prop), an RFC 822std11(-> 2822prop) message and the
...
...
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,
...
... 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.
...
... 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 ...
... 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:
...
... - 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
...
... 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 ...
... 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)).
...
... 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 ...
... user interface definition
These are really coupled. To map the X.400 services, this
specification defines a number of extensions to RFC 822std11(-> 2822prop) ...
... 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) ...
... 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 ...
... X.400 services.
Thus, it will be a poor choice for X.400 implementors to use RFC
987(88) as an interface ...
... 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
...
... interface is desired, a
specification targeted at X.400, without RFC 822std11(-> 2822prop) restrictions, would
be more appropriate.
...
...
4. Addressing - This considers the mapping between X.400 O/R
names and RFC 822std11(-> 2822prop) addresses ...
...
RFC 822std11(-> 2822prop) and X.400 provide a number of services to the end user. This
chapter describes the extent to which each service ...
... chapter describes the extent to which each service can be supported
across an X.400 <-> RFC 822std11(-> 2822prop) gateway. The cases considered are single
...
... originator specifies a Subject: field, this is considered to be
supported, as an X.400 recipient will get a subject indication.
...
... 822std11(-> 2822prop) services are supported or partially supported for
origination. The implications of non-supported X.400 services is
described under X.400 ...
... header into a heading extension in the IPM (InterPersonal Message).
This can be regarded as partial support, as it makes the information
available to any X.400 implementations which are interested in these
services. Communities which require significant RFC 822std11(-> 2822prop) ...
... 822std11(-> 2822prop) interworking
should require that their X.400 User Agents are able to display these
heading extensions. Support for the various service ...
... addresses in these fields are mapped onto text, and so are
not accessible to the X.400 user as addresses. In
principle, fuller support would be possible by mapping onto
...
... 822std11(-> 2822prop) User Agent of a message
originated in an X.400 system and transferred across a gateway. The
following standard services ...
... X.400 ...
... Origination in X.400 ...
...
When mapping services from X.400 to RFC 822std11(-> 2822prop) which are not supported
by RFC 822std11(-> 2822prop) ...
... action is implied, the service can be regarded as being partially
supported. Chapter 5 describes how to map X.400 services onto these
new headers ...
... These are the mandatory IPM services as listed in Section 19.8 of
X.400 / ISO/IEC 10021-1, listed here in the order given. Section
19.8 has cross references to short definitions of each service ...
... Identifier). This new header is required, as
X.400 has two message-ids whereas RFC 822std11(-> 2822prop) has only one (see
previous service ...
... ForwardedIPMessage is supported, with some loss of
information. Other types get some measure of support,
dependent on X.400 facilities for conversion to IA5. This
will only be done where content conversion is not
...
... This section describes support for the optional (user selectable) IPM
services as listed in Section 19.9 of X.400 / ISO/IEC 10021- 1,
listed here in the order given. Section 19.9 has cross references to
...
... Distribution List means MTS supported distribution list, in
the manner of X.400. This service does not exist in the RFC
822 world. RFC 822std11(-> 2822prop) ...
... Redirection means MTS supported redirection, in the manner
of X.400. This service does not exist in the RFC 822std11(-> 2822prop) world.
...
...
Use of Distribution List
In principle this applies only to X.400 supported
distribution lists (see DL Expansion Prohibited).
...
... Reception by X.400 ...
... The following standard IPM mandatory user facilities may be required
for reception of RFC 822std11(-> 2822prop) originated mail by an X.400 UA.
...
... The following standard IPM optional user facilities may be required
for reception of RFC 822std11(-> 2822prop) originated mail by an X.400 UA.
...
... represented. It may be present in RFC 822std11(-> 2822prop) originated messages, which
are received by an X.400 UA.
...
...
The X.400 protocols are encoded in a structured manner according to
ASN.1, whereas RFC 822std11(-> 2822prop) ...
... 822std11(-> 2822prop) is represented in ASCII, and needs to be
mapped into X.400 elements encoded as printable string. For this
reason, a mechanism to represent ASCII ...
... 822std11(-> 2822prop)
addresses from an X.400 system. These special encodings should be
mapped in a case insensitive manner, but always be generated in lower
...
...
Addressing is probably the trickiest problem of an X.400 <-> RFC 822std11(-> 2822prop)
gateway ...
... gateway. Therefore it is given a separate chapter. This chapter, as
a side effect, also defines a textual representation of an X.400 O/R
Address.
...
... semantics, other than to the end user.
The basic X.400 O/R Address, used by the MTS for routing ...
... attributes. For each unstructured attribute, a key and an encoding
is specified. For structured attributes, the X.400 attribute is
mapped onto one or more attribute value pairs. For domain ...
...
Maps with "Marshall.M.T.Rose"
Note that X.400 suggest that Initials is used to encode ALL initials.
Therefore, the proposed encoding is "natural" when either GivenName
...
...
2. In the general case, there would not be the necessary
administrative co-operation between the X.400 and RFC 822std11(-> 2822prop)
worlds, which would be needed for this to work.
...
... cannot be used in the general case, basically due to character set
problems, and lack of order in X.400 O/R Addresses. The only way to
encode the full PrintableString character set ...
... be maintained, as opposed to using simply subdomains:
1. As a shorthand to avoid redundant X.400 information. In
particular, there will often be only one ADMD per country,
and so it does not need to be given explicitly.
...
... so encoded follow a consistent hierarchy.
There will be some cases where an X.400 O/R address of this
encoding ...
... MTS.ORAddress, the
first OU in the SEQUENCE is the most significant, as
specified in X.400.
3. For the Domain ...
... mapping, there are NO implications on ordering significance
within X.400, where this is a Management Domain issue.
...
... There are two basic cases:
1. X.400 addresses encoded in RFC 822std11(-> 2822prop). This will also include
...
... MTS.ORAddress specification and to the restrictions on this
set given in X.400. If not go to stage II.
7. Build the O/R Address ...
... address, it must be rejected, as there is a need to interpret
such an address in X.400. For the 822-MTS return address, and
...
... as RFC 822std11(-> 2822prop) addresses in an X.400 O/R Name:
1. Convert the EBNF.822-address ...
... X.400.
2. "Genuine" X.400 addresses. This may include symmetrically
encoded RFC 822std11(-> 2822prop) ...
... Mapping B
This will be used for X.400 addresses which do not use the explicit
RFC 822std11(-> 2822prop) ...
... syntax EBNF.domain-syntax (as defined in 4.3.1), allocate
the next subdomain. At least one attribute of the X.400
address should not be mapped onto subdomain, as
...
... gateway. The symmetry is particularly useful in cases of (mail
exploder type) distribution list expansion. For example, an X.400
user sends to a list on an RFC 822std11(-> 2822prop) system which he belongs to. The
...
... user sends to a list on an RFC 822std11(-> 2822prop) system which he belongs to. The
received message will have the originator and any 3rd party X.400 O/R
Addresses in correct format (rather than doubly encoded). In cases
...
... Addresses in correct format (rather than doubly encoded). In cases
(X.400 or RFC 822std11(-> 2822prop)) where there is common agreement on gateway ...
... 822std11(-> 2822prop) networks, but are
interconnected by X.400, the following may happen: The originator
specifies:
...
... In other cases, the reversibility is more important, due to the (far
too frequent) cases where RFC 822std11(-> 2822prop) and X.400 services are partitioned.
...
... This will be sent to an arbitrary UK Academic Community gateway by
X.400. Then it will be sent by JNT Mail to another gateway
determined by the domain ...
... The basic functionality is to generate the 822-MTS originator and
recipients. There is information present on the X.400 side, which
cannot be mapped into analogous 822-MTS services ...
... There is a need to map both ways between 822.msg-id and
IPMS.IPMIdentifier. This allows for X.400 Receipt Notifications,
Replies, and Cross References to reference an RFC 822std11(-> 2822prop) ...
... gateway generated ID. A reversible and
symmetrical mapping is defined. This allows for good things to
happen when messages pass multiple times across the X.400/RFC 822std11(-> 2822prop)
boundary.
...
... msg-id represented in X.400 ...
... and the 822.domain is "MHS", then this ID was X.400 generated. If
EBNF.printablestring is present, the value is assigned to
IPMS ...
... 822std11(-> 2822prop) MTA level parameters to be carried in the analogous
X.400 service elements. The advantages of this mapping far outweigh
...
... X.400 Extension Field ...
... but may prevent useful communication.
3. Truncate fields to the upper bounds specified in X.400.
This will prevent problems with UAs which enforce upper
...
... content-id-length (16). Both are used, due to the much larger
upper bound of the content correlator, and that the content id is
available in X.400(1984).
...
...
- To prevent RFC 822std11(-> 2822prop)/X.400 looping caused by distribution
lists or redirects.
...
... services, a gateway conforming to this
specification does not need to map these fields to X.400, with the
exception of "DL-Expansion-History" and "Redirection-History"
described in the previous section. However, it is usually desirable
...
...
It is not clear how widely supported the X.400 return of contents
service will be. Experience with X.400 ...
... X.400 return of contents
service will be. Experience with X.400(1984) suggests that support
of this service may not be universal. As this service ...
... the RFC 822std11(-> 2822prop) world, two approaches are specified. The choice will
depend on the use of X.400 return of contents withing the X.400
community being serviced by the gateway ...
... 822std11(-> 2822prop) world, two approaches are specified. The choice will
depend on the use of X.400 return of contents withing the X.400
community being serviced by the gateway.
...
... gateway must make special provision to handle return of contents.
For every message passing from RFC 822std11(-> 2822prop) -> X.400, content return
request will not be requested, and report request always will be.
When the delivery ...
... MTS originator. The gateway
may retransmit the X.400 message if it wishes. When this approach is
taken, routing must be set up so that error reports are returned
...
... MTS.EncodedInformationTypes.non-basic-parameters is ignored. Built
in types are mapped onto fixed strings (compatible with X.400(1984)
and RFC 987(-> 2156prop | 1327(-> 2156prop))), and other types are mapped onto EBNF.object-identifier ...
... IPMS.MessageBodyPart
The X.400 -> RFC 822std11(-> 2822prop) mapping should be recursively applied,
to generate an RFC 822std11(-> 2822prop) ...
... If any MTS (or MTA) Extensions not specified in X.400 are present,
and they are marked as critical for transfer or delivery ...
... The 822-MTS recipients should be calculated from the full list of
X.400 recipients. This is all of the members of
MTA.MessageTransferEnvelope.per-recipient ...
... use it to generate a Deferred-Delivery: field. For some reason,
X.400 does not make this information available at the MTS level on
delivery ...
... profiles, and in particular the CEN/CENELEC profile
for X.400(1984) [Systems85a], specify that this element must be
...
... mailbox and EBNF.std-or in
EBNF.recipient-info. Both RFC 822std11(-> 2822prop) and X.400 forms are
given, as there may be a problem in the mapping tables. It
also generates the EBNF.mailbox ...
... To: jpo@computer-science.nottingham.ac.uk
Subject: X.400 Delivery Report
Message-Type: Delivery ...
... - The new service elements of X.400 are dealt with.
- A clear distinction is made between origination and
...
... 3. Acknowledge-To:
This field has no direct functional equivalent in X.400. However, it
can be supported to an extent, and can be used to improve X.400
...
... This field has no direct functional equivalent in X.400. However, it
can be supported to an extent, and can be used to improve X.400
support.
...
...
If an Acknowledge-To: field is present when going from JNT Mail to
X.400, MTS.PerRecipientSubmissionFields.originator-request-
report.report shall be set for each recipient. If there is more that
...
... extension heading.
When going from X.400 to JNT Mail, in cases where
MTA.PerRecipientMessageTransferFields.per-recipient ...
... JNT Mail trace uses the Via: syntax. When going from JNT Mail to
X.400, a mapping similar to that for Received: is used. No
MTS.GlobalDomainIdentifier of the site making the trace ...
... MTS.OtherMessageDeliveryFields.originator-name is to the Sender:
field. This can cause a problem when going from X.400 to JNT Mail if
the mapping of IPMS.Heading has already generated a Sender ...
...
Gatewaying of UUCP and X.400 is handled by first gatewaying the UUCP
address into RFC 822std11(-> 2822prop) ...
... 822std11(-> 2822prop) inthop!dest!user@gatehost.COM
or through a single X.400 to UUCP gateway:
...
... association between the domain and
X.400 namespaces described in Chapter 4. The use of this association
...
... the form including the element with no value, although a correct
X.400 implementation will interpret both in the same manner.
This syntax is not intended to be handled by users.
...
... CCITT/ISO, "CCITT Recommendations X.400/ ISO IS 10021-1", Message Handling: System and Service Overview, CCITT/ISO ...
... Kille, S., "Mapping Between X.400 and RFC 822std11(-> 2822prop)", UK Academic Community Report (MG.19) / RFC 987(-> 2156prop | 1327(-> 2156prop)) ...