7. Appendix B - Mapping with X.400(1984)

   This appendix defines modifications to the  mapping for use with
   X.400(1984).

   The 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
   level.  The heading extension feature is used at the IPMS level, and
   this shall be replaced by the RFC 987(-> 2156prop | 1327(-> 2156prop)) approach.  All header
   information which would usually be mapped into the rfc-822-heading-
   list extension is mapped into a single IA5 body part, which is the
   first body part in the message.  This body part will start with the
   string "RFC-822-Headers:" as the first line.  The headers then follow
   this line.  This specification requires correct reverse mapping of
   this format, either from 1988 or 1984.  RFC 822std11(-> 2822prop) extended headers
   which could be mapped into X.400(1988) elements, are also mapped to
   the body part.

   In an environment where RFC 822std11(-> 2822prop) is of major importance, it may be
   desirable for downgrading to consider the case where the message was
   originated in an RFC 822std11(-> 2822prop) system, and mapped according to this
   specification.  The rfc-822-heading-list extension may be mapped
   according to this appendix.

   When parsing std-or, the following restrictions shall be observed:

   -    Only the 84/88 attributes identified in the table in
        Section 4.2 are present.

   -    No teletex encoding is allowed.

   If an address violates this, it shall be treated as an RFC 822std11(-> 2822prop)
   address, which will usually lead to encoding as a DDA "RFC-822".

   It is possible that attributes of zero length may be present
   in an OR Address.  This is not legal in 1988, except for ADMD
   where the case is explicitly described in Section 4.3.5.
   Attributes of zero length are deprecated (the attribute shall be
   omitted), and will therefore be unusual.  However, some systems
   generate them and rely on them.  Therefore, any null attribute
   shall be enoded using the std-or encoding (e.g., /O=/).

   If a non-Teletex Common Name (CN) is present, it shall be
   mapped onto a Domain Defined Attribute "Common".  This is in line
   with RFC 1328hist on X.400 1988 to 1984 downgrading [22].

   This specification defines a mapping of the Internet message
   framework to X.400.  Body part mappings are defined in RFC
   2157prop [6], which relies on X.400(88) features.   Downgrading to
   X.400(84) for body parts is defined in RFC 1496hist (HARPOON), which
   shall be followed in the context of this appendix [5].