X.400 Downgrading: X.400 1988 to 1984 downgrading
How gateways should downgrade X.400 1988 messages and addresses for 1984 systems.
Hardcastle-Kille, S., "X.400 1988 to 1984 downgrading", RFC 1328, DOI 10.17487/RFC1328, May 1992, <https://www.rfc-editor.org/info/rfc1328>.
@misc{rfc1328,
series = {Request for Comments},
number = 1328,
howpublished = {RFC 1328},
publisher = {RFC Editor},
doi = {10.17487/RFC1328},
url = {https://www.rfc-editor.org/info/rfc1328},
author = {S. Hardcastle-Kille},
title = {{X.400 1988 to 1984 downgrading}},
pagetotal = 5,
year = 1992,
month = may,
} RFC text
Contents
Network Working Group S. Hardcastle-Kille
Request for Comments: 1328 University College London
May 1992
X.400 1988 to 1984 downgrading
Status of this Memo
This RFC specifies an IAB standards track protocol for the Internet
community, and requests discussion and suggestions for improvements.
Please refer to the current edition of the "IAB Official Protocol
Standards" for the standardization state and status of this protocol.
Distribution of this memo is unlimited.
Abstract
This document considers issues of downgrading from X.400(1988) to
X.400(1984) [MHS88a, MHS84]. Annexe B of X.419 specifies some
downgrading rules [MHS88b], but these are not sufficient for
provision of service in an environment containing both 1984 and 1988
components. This document defines a number of extensions to this
annexe.
This specification is not tutorial. COSINE Study 8.2 by J.A.I.
Craigie gives a useful overview [Cra88].
1. The need to Downgrade
It is expected that X.400(1988) systems will be extensively deployed,
whilst there is still substantial use of X.400(1984). If 1988
features are to be used, it it important for there to be a clear
approach to downgrading. This document specifies an approach to
downgrading for the Internet and COSINE communities. As 1988 is a
strict superset of 1984, the mapping is a one-way problem.
2. Avoiding Downgrading
Perhaps the most important consideration is to configure systems so
as to minimise the need for downgrading. Use of 1984 systems to
interconnect 1988 systems should be strenuously avoided.
In practice, many of the downgrading issues will be avoided. When a
1988 originator sends to a 1984 recipient, 1988 specific features
will not be used as they will not work! For distribution lists with
1984 and 1988 recipients, messages will tend to be "lowest common
denominator".
3. Addressing
In general there is a problem with O/R addresses which use 88
specific features. The X.419 downgrade approach will mean that
addresses using these features cannot be specified from 84 systems.
Worse, a message originating from such an address cannot be
transferred into X.400(1984). This is unacceptable. Two approaches
are defined. The first is a general purpose mechanism, which can be
implemented by the gateway only. The second is a special purpose
mechanism to optimise for a form of X.400(88) address which is
expected to be used frequently (Common Name). The second approach
requires cooperation from all X.400(88) UAs and MTAs which are
involved in these interactions.
3.1 General Approach
The first approach is to use a DDA "X400-88". The DDA value is an
std-or encoding of the address as defined in RFC 1327 [Kil92]. This
will allow source routing through an appropriate gateway. This
solution is general, and does not require co-operation. For example:
88:
PD-ADDRESS=Empire State Building; PRMD=XX; ADMD=ZZ; C=US;
84:
O=MHS-Relay; PRMD=UK.AC; C=GB;
DD.X400-88=/PD-ADDRESS=Empire State Building/PRMD=XX/ADMD=ZZ/C=US/;
The std-or syntax can use IA5 characters not in the printable string
set (typically to handle teletext versions). To enable this to be
handled, the std-or encoded in encapsulated into printable string
using the mappings of Section 3.4 of RFC 1327. Where the generated
address is longer than 128 characters, up to three overflow domain
defined attributes are used: X400-C1; X400-C2; X400-C3.
3.2 Common Name
Where a common name attribute is used, this is downgraded to the
Domain Defined Attribute "Common". For example:
88:
CN=Postmaster; O=A; ADMD=B; C=GB;
84:
DD.Common=Postmaster; O=A; ADMD=B; C=GB;
The downgrade will always happen correctly. However, it will not
always be possible for the gateway to do the reverse mapping.
Therefore, this approach requires that all 1988 MTAs and UAs which
wish to interact with 1984 systems through gateways following this
specification will need to understand the equivalence of these two
forms of address.
4. MTS
Annexe B of X.419 is sufficient, apart from the addressing.
The discard of envelope fields is unfortunate. However, the
criticality mechanism ensures that no information the originator
specifies to be critical is discarded. There is no sensible
alternative. If mapping to a system which support the MOTIS-86 trace
extensions, it is recommended that the internal trace of X.400(88) is
mapped on to this, noting the slight differences in syntax.
5. IPM Downgrading
The IPM service in X.400(1984) is usually provided by content type 2.
In many cases, it will be useful for a gateway to downgrade P2 from
content type 22 to 2. This will clearly need to be made dependent on
the destination, as it is quite possible to carry content type 22
over P1(1984). The decision to make this downgrade will be on the
basis of gateway configuration.
When a gateway downgrades from 22 to 2, the following should be done:
1. Strip any 1988 specific headings (language indication, and
partial message indication).
2. Downgrade all O/R addresses, as described in Section 3.
3. If a directory name is present, there is no method to preserve
the semantics within a 1984 O/R Address. However, it is
possible to pass the information across, so that the information
in the Distinguished Name can be informally displayed to the
end user. This is done by appendend a text representation of
the Distinguished Name to the Free Form Name enclosed in round
brackets. It is recommended that the "User Friendly Name"
syntax is used to represent the Distinguished Name [Kil90]. For
example:
(Steve Hardcastle-Kille, Computer Science,
University College London, GB)
4. The issue of body part downgrade is discussed in Section 6.
5.1 RFC 822 Considerations
A message represented as content type 22 may have originated from RFC
822 [Cro82]. The downgrade for this type of message can be improved.
This is discussed in RFC 1327 [Kil92].
6. Body Part downgrading
The issue of body part downgrade is very much linked up with the
whole issue of body part format conversion. If no explicit
conversion is requested, conversion depends on the MTA knowing the
remote UA's capabilities. The following options are available for
body part conversion in all cases, including this one. It is assumed
that body part conversion is avoided where possible.
1. Downgrade to a standard 1984 body part, without loss of
information
2. Downgrade to a standard 1984 body part, with loss of information
3. Discard the body part, and replace with a (typically IA5 text)
message. For example:
**********************************************
*
* There was a hologram here which could
* not be converted
*
**********************************************
4. Bounce the message
If conversion is prohibited, 4) must be done. If conversion-with-
loss is prohibited, 1) should be done if possible, otherwise 4). In
other cases 2) should be done if possible. If it is not possible,
the choice between 3) and 4) should be a configuration choice. X.419
only recognises 4). 3) Seems to be a useful choice in practice,
particularly where the message contains other body parts. Another
option is available when downgrading:
1. Encapsulate the body part as a Nationally Defined 1984
body part (body part 7).
This should be used when configured for the recipient UA.
References
[Cra88] Craigie, J., "Migration strategy for x.400(84) to
x.400(88)/MOTIS", COSINE Specification Phase 8.2, RARE, 1988.
[Cro82] Crocker, D., "Standard of the Format of ARPA Internet Text
Messages", RFC 822, UDEL, August 1982.
[Kil90] Kille, S., "Using the OSI directory to achieve user friendly
naming", Research Note RN/90/29, Department of Computer
Science, University College London, February 1990.
[Kil92] Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC
822", RFC 1327, University College London, May 1992.
[MHS84] Recommendations X.400, October 1984. CCITT SG 5/VII, Message
Handling Systems: System Model - Service Elements.
[MHS88a] CCITT recommendations X.400 / ISO 10021, April 1988. CCITT
SG 5/VII / ISO/IEC JTC1, Message Handling: System and
Service Overview.
[MHS88b] CCITT recommendations X.419/ ISO 10021, April 1988.
CCITT SG 5/VII / ISO/IEC JTC1, Message Handling: Protocol
Specifications.
7. Security Considerations
Security issues are not discussed in this memo.
8. Author's Address
Steve Hardcastle-Kille
Department of Computer Science
University College London
Gower Street
WC1E 6BT
England
Phone: +44-71-380-7294
EMail: S.Kille@CS.UCL.AC.UK
AI ELI5
On this page
§1The Need to Downgrade
The document considers downgrading from X.400(1988) to X.400(1984). Annexe B of X.419 has some rules, but they are not sufficient for an environment with both 1984 and 1988 components, so this document defines extensions. It is not a tutorial.
Since 1988 is a strict superset of 1984, the mapping is one-way. The most important advice is to configure systems to minimise downgrading, and to strenuously avoid using 1984 systems to interconnect 1988 systems. For distribution lists with both kinds of recipients, messages tend to be lowest common denominator.
New mail systems can do more than old ones, so going to an old one means dropping things. It is best to avoid that where you can.
§2Downgrading Addresses
O/R addresses using 1988-specific features cannot be specified from 1984 systems, and messages from such addresses cannot be transferred into X.400(1984). Two approaches are defined.
The general approach uses a domain defined attribute (DDA) named X400-88, whose value is an std-or encoding of the address as in RFC 1327. It lets a gateway source-route the message and needs no cooperation. If the result is longer than 128 characters, up to three overflow attributes (X400-C1, X400-C2, X400-C3) are used.
The special approach handles the Common Name attribute by downgrading it to the DDA Common, for example CN=Postmaster becomes DD.Common=Postmaster. The downgrade always works, but the gateway cannot always reverse it, so all 1988 MTAs and UAs that interact through such gateways must understand the equivalence.
Fancy address parts are folded into a plain label the old system can carry, so the message can still be sent and answered.
§3MTS and IPM Downgrading
For the message transfer system, annexe B of X.419 is sufficient apart from addressing. Discarding envelope fields is unfortunate, but the criticality mechanism ensures nothing the originator marked critical is discarded.
The 1984 IPM service usually uses content type 2, so a gateway may downgrade P2 from content type 22 to 2, depending on configuration and destination. When it does, it strips 1988-specific headings (language indication and partial message indication), downgrades all O/R addresses, and appends any directory name as text in round brackets to the Free Form Name, preferably in the User Friendly Name syntax. A message that originated from RFC 822 can be downgraded better, as discussed in RFC 1327.
The gateway removes the new-style headings and tucks the sender's full name into brackets so people can still read it.
§4Body Part Downgrading
Body part conversion should be avoided where possible. The options are to downgrade to a standard 1984 body part without or with loss of information, to replace the body part with a text message (for example saying a hologram could not be converted), or to bounce the message.
If conversion is prohibited, the message must bounce. If conversion-with-loss is prohibited, a lossless downgrade should be used if possible, otherwise bounce. Otherwise a lossy downgrade is done if possible, and a choice between the text replacement and bouncing is a configuration choice. Another option is to encapsulate the body part as a Nationally Defined 1984 body part (body part 7) when configured for the recipient UA.
If a part cannot be turned into something the old system understands, the gateway can swap in a note saying so, or send the message back.