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
822std11(-> 2822prop) 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 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,
...
... Some RFC 822std11(-> 2822prop) networks may wish to use X.400 as an interconnection
mechanism (typically for policy reasons), and this is fully
supported.
...
... supported.
Where an X.400 messages transfers to RFC 822std11(-> 2822prop) and then back to X.400,
...
... Where an X.400 messages transfers to RFC 822std11(-> 2822prop) and then back to X.400,
there is no expectation of X.400 services ...
... 822std11(-> 2822prop) and then back to X.400,
there is no expectation of X.400 services which do not have an
equivalent service ...
... X.400 (1984) ...
... 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 ...
... 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
...
... 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)).
...
... 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.
...
... 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 ...
... 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
...
... 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) ...
... 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
...
... all X.400 services. Thus, it will be a poor choice for X.400
implementors to use RFC 987(-> 2156prop | 1327(-> 2156prop)) ...
... 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 ...
... 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
...
...
4. Addressing - This considers the mapping between X.400 O/R
names and RFC 822std11(-> 2822prop) addresses ...
... CONTEXT OF RFC 822std11(-> 2822prop) AND
X.400 (1988). DO NOT ATTEMPT TO READ THIS DOCUMENT UNLESS
YOU ARE ...
...
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 ...
...
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
are recommended to 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
...
... 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
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 are required
for reception of RFC 822std11(-> 2822prop) originated mail by an X.400 UA.
...
... The following standard IPM optional user facilities are 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) ...
... is set to the value at the time of translation.
When mapping to X.400, the UTCTime format which specifies the
timezone offset shall be used.
...
... 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 shall be
interpreted in a case insensitive manner, but always generated in
...
...
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 ...
... following alternative values shall be recognised when mapping from
RFC 822std11(-> 2822prop) to X.400. These shall not be generated when mapping from
X.400 to RFC 822std11(-> 2822prop) ...
... 822std11(-> 2822prop) to X.400. These shall not be generated when mapping from
X.400 to RFC 822std11(-> 2822prop).
...
...
When mapping from RFC 822std11(-> 2822prop) to X.400, the keywords: OU1, OU2, OU3, and
OU4, shall be recognised. If these are present, no keyword OU
shall be present. These will be treated as ordered values of OU.
...
... Maps with "Marshall.M.T.Rose"
Note that X.400 suggest that Initials is used to encode ALL initials.
Therefore, the defined encoding is "natural" when either GivenName or
...
...
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.
...
... This cannot be used in the general case, due to character set
problems, and to the variants of X.400 O/R Addresses which use
different attribute types. The only way to encode the full
...
... 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.
...
... 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
...
... set of attributes has been derived, which
will give appropriate routing within X.400. If any of the
later steps of Stage I force use of Stage II, then these
attributes should be used in Stage II.
...
... MTS.ORAddress specification and to the restrictions on this
set given in X.400, and that no upper bounds are exceeded
for any attribute. If not go to stage II.
...
... 822std11(-> 2822prop) system. Such addresses shall be encoded in
an X.400 O/R Address using a domain defined attribute.
...
... address. The administrative equivalence of the
mappings will ensure correct routing throug X.400 to a gateway back
to RFC 822std11(-> 2822prop) ...
... source route to a gateway
from the X.400 side. There are three cases, which are handled
differently:
...
... Addresses
These are optimised for replying. In general, the message
may end up anywhere within the X.400 world, and so this
optimisation identifies a gateway appropriate for the RFC
...
... namespace which do not have an administrative equivalence
with any part of the X.400 namespace, but for which it is
desirable to identify a preferred X.400 gateway ...
... X.400 namespace, but for which it is
desirable to identify a preferred X.400 gateway in order to
optimise routing.
...
... MTS Recipient
As the RFC 822std11(-> 2822prop) and X.400 worlds are fully connected, there
is no technical reason for this situation to occur. In some
...
... routing may be configured to connect two parts of the
RFC 822std11(-> 2822prop) world using X.400. The information that this part
of the domain space should be routed by X.400 ...
... X.400. The information that this part
of the domain space should be routed by X.400 rather than
remaining within the RFC 822std11(-> 2822prop) world will be configured
...
... to gateway mapping is important, as the use of this mapping
will lead to a remote X.400 address, which can be routed by
X.400 ...
... X.400 address, which can be routed by
X.400 routing procedures. The information in this mapping
shall not be used as a basis for deciding to convert a
...
... shall not be used as a basis for deciding to convert a
message from RFC 822std11(-> 2822prop) to X.400.
...
... 822std11(-> 2822prop) users will often use an LHS encoded address to identify an
X.400 recipient. Because the syntax is fairly complex, a number of
heuristics may be applied to facilitate this form of usage. A
...
... X.400.
2. "Genuine" X.400 addresses. This may include symmetrically
encoded RFC 822std11(-> 2822prop) ...
... Mapping B
This is used for X.400 addresses which do not use the explicit RFC
822std11(-> 2822prop) ...
... the one described at the end of 4.3.4. This is not
done, primarily because use of RFC 822std11(-> 2822prop) to connect X.400
systems is not expected to be significant.
...
... domain-syntax (as defined
in 4.3.1), allocate the next subdomain. At least one
attribute of the X.400 address shall not be mapped onto
subdomain, as 822.local-part cannot be null. If there are
...
... 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
...
... 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 ...
... 822std11(-> 2822prop), then to the AC
PRMD by X.400, and then to jj@seismo.css.gov by RFC 822std11(-> 2822prop).
...
... 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,
...
... 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) generated ID.
Otherwise, the ID is X.400 generated. Use the
IPMS.IPMIdentifier.user to generate an EBNF.std-or-address ...
... 987(-> 2156prop | 1327(-> 2156prop)) generated encodings may be recognised as follows. When
mapping from X.400 to RFC 822std11(-> 2822prop), if the IPMS.IPMIdentifier.user-
...
... 987(-> 2156prop | 1327(-> 2156prop)) generated. When
mapping from RFC 822std11(-> 2822prop) to X.400, if the 822.domain is not "MHS", and
...
... 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 ...
... appended. 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
...
... trace-information will be
generated already (from Date:), unless the message has
previously been in X.400, when it will be derived from the
X.400 trace ...
... services, a gateway conforming to this
specification does not need to map all of these fields to X.400.
Two extended fields must be mapped, in order to prevent looping.
...
... element of trace should not be
done. This is because the message has come from X.400, and so the
first element of trace ...
... encoded according to RFC 934, and this may be mapped on to the
corresponding X.400 structures.
The following may cause problems, due to other information not being
...
... Identifier:
Other fields may be either discarded or mapped to X.400. It is
usually desirable and beneficial to do map, particularly to
facilitate support of a message traversing multiple gateways ...
...
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 is recursively applied, to
generate an RFC 822std11(-> 2822prop) ...
... Notification" for a
receipt notification and to "X.400 Inter-Personal
Notification (failure)" for a non-receipt notification ...
... To: Julian Onions <jpo@computer-science.nottingham.ac.uk>
Subject: X.400 Inter-personal Notification
Message-Type: InterPersonal Notification
...
... 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 are calculated from the full list of X.400
recipients. This is all of the members of
MTA ...
... is used 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
supported at the first MTA ...
... information is conveyed to the RFC 822std11(-> 2822prop) user in a consistent manner.
The format is structured as if it was a message coming from X.400,
with the description in one body part, and a forwarded message
...
... 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 ...
... 4. 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, there are two different situations. The first case is
where there is one address in the Acknowledge-To: field, and it is
...
... MTS.PerRecipientSubmissionFields.originator-request-report.report
shall be set for each recipient, and the Acknowledge-To: field
discarded. Here, X.400 can provide the equivalent service.
...
... 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:
...
... MHS project, on behalf of the Internet and
other X.400 and RFC 822std11(-> 2822prop) users. For information on accessing this
information contact:
...
... from the form including the element with no value, although a
correct X.400 implementation will interpret both in the same
manner.
...
... Appendix G - Mapping with X.400(1984) ...
... X.400(1984).
The X.400(1984) protocols are a proper subset of X.400(1988). When
mapping from X.400 ...
...
The X.400(1984) protocols are a proper subset of X.400(1988). When
mapping from X.400(1984) to RFC 822std11(-> 2822prop) ...
... X.400(1984) protocols are a proper subset of X.400(1988). When
mapping from X.400(1984) to RFC 822std11(-> 2822prop), no changes to this specification
are needed.
...
...
When mapping from RFC 822std11(-> 2822prop) to X.400(1984), no use can be made of 1988
specific features. No use of such features is made at the MTS
...
... onto a Domain Defined Attribute "Common". This is in line with RFC
1328 on X.400 1988 to 1984 downgrading [Hardcastle-K92].
...
... This appendix defines a number of optional mappings which may be
provided to give access from RFC 822std11(-> 2822prop) to a number of X.400 services.
These mappings are beyond the basic scope of this specification.
...
... There has been a definite demand to use extended RFC 822std11(-> 2822prop) as a
mechanism to acccess X.400, and these extensions provide access to
certain features. If this functionality is provided, this appendix
shall be followed. The following headings are defined:
...
... - Generation of extended RFC 822std11(-> 2822prop) fields is mandatory.
Optionally, they may be parsed and mapped back to X.400. A
gateway should should indicate if this is done.
...
... 987(-> 2156prop | 1327(-> 2156prop)) was the original document, and contained the key elements of
this specification. It was specific to X.400(1984). RFC 1026(-> 2156prop | 1327(-> 2156prop))
specified a small number of necessary changes to RFC 987(-> 2156prop | 1327(-> 2156prop)) ...
... major goal of RFC 1148(-> 2156prop | 1327(-> 2156prop)) was to upgrade RFC
987 to X.400(1988). It did this, but did not obsolete RFC 987(-> 2156prop | 1327(-> 2156prop)), which
was recommended for use with X.400 ...
... X.400(1988). It did this, but did not obsolete RFC 987(-> 2156prop | 1327(-> 2156prop)), which
was recommended for use with X.400(1984). This appendix summarises
the changes made in going from RFC 987(-> 2156prop | 1327(-> 2156prop)) to RFC 1148(-> 2156prop | 1327(-> 2156prop)) ...
... 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 ...
... - The new service elements of X.400 are dealt with.
- A clear distinction is made between origination and
...
... 1. General
- The scope of the document was changed to cover X.400(1984),
and so obsolete RFC 987(-> 2156prop | 1327(-> 2156prop)).
...
... 822std11(-> 2822prop) networks
using X.400
- Text was tightened to be clear about optional and mandatory
...
... - Better examples are given
- Further X.400 upper bounds are handled correctly
2. Basic Mappings
...
... and a third table definition added.
- An appendix on use with X.400(1984) is added.
- Optional extensions are defined to give RFC 822std11(-> 2822prop) ...
... - Optional extensions are defined to give RFC 822std11(-> 2822prop) access to
further X.400 facilities.
- An appendix on conformance is added.
...
... CCITT/ISO88a.
CCITT/ISO, "CCITT Recommendations X.400/ ISO IS 10021-1,"
Message Handling: System and Service ...
...
Hardcastle-K92.
Hardcastle-Kille, S., "X.400 1988 to 1984 downgrading," RFC
1328, UCL, May 1992.
...