X.400 1988 to 1984 downgrading
RFC 1328

Document Type RFC - Historic (May 1992; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1328 (Historic)
Telechat date
Responsible AD (None)
Send notices to (None)
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.


   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

   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

Hardcastle-Kille                                                [Page 1]
RFC 1328             X.400 1988 to 1984 downgrading             May 1992

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:

     PD-ADDRESS=Empire State Building;  PRMD=XX; ADMD=ZZ; C=US;

     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:

       CN=Postmaster; O=A; ADMD=B; C=GB;

       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.

Hardcastle-Kille                                                [Page 2]
RFC 1328             X.400 1988 to 1984 downgrading             May 1992

   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
Show full document text