Mapping between X.400 and RFC-822 Message Bodies
obsoleted by
- rfc-2156 — MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME
updates
- rfc-1327 — Mapping between X.400(1988) / ISO 10021 and RFC 822
Extracted elements (17)
MIME semantics are richer than MHS structuring semantics, so the mappings are not fully symmetric. MHS heading extensions are used to carry the additional MIME semantics (multipart subtype, partial message parameters) in order to provide reversible round-trip transformations.
The mappings are designed to support three scenarios: (1) arbitrary binary content exchange between MIME and MHS users, (2) MIME content-types tunneling through an MHS relay without loss, and (3) MHS body parts tunneling through a MIME relay without loss. MHS heading extensions carry additional MIME semantics to enable reversible transformations.
The mapping is symmetric for three cases: (1) any atomic body part, (2) multipart/digest and multipart/mixed subtypes, and (3) message/rfc822. For other content-types (message/external-body, message/partial, nested multipart), asymmetric mappings apply.
A nested multipart MIME content (which refers to a set of content-types, not a message) is always mapped to an IPMS.MessageBodyPart with an IPMS.BodyPart for each contained content-type.
For T.61 string mapping: (1) ASCII-only strings are copied directly; (2) strings from an IANA-registered character set use encoded-words per RFC-1342; (3) strings from unregistered character sets use X.408 mappings to IA5. This applies only to human-readable fields (Subject and FreeForm Name).
If the IPMS.Body consists solely of a single IA5Text body part, the RFC-822 message body is NOT marked as a MIME content. This prevents RFC-822 mailers from invoking MIME functionality unnecessarily.
MIME message/partial content maps to an MHS message using the PartialMessage heading extension derived from the message/partial parameters (number, total, id). When mapping MHS to MIME, if this heading is present, a message/partial should be generated.
The multipart IPMS HeadingExtension should be generated for all multipart content-types with the enumerated value set according to the subtype. When mapping from MHS to MIME, if present, the appropriate multipart content-type should be generated.
When mapping from RFC-822 headers, an encountered encoded-word is converted to T.61 if all characters are mappable to T.61; otherwise the encoded-word is copied directly into the T.61 string.
When mapping from RFC-822 to X.400, if the 822.MIME-Version header field is present, a special algorithm is used to generate the IPMS.body based on the MIME content-type.
When mapping from X.400 to RFC-822, if the MHS body part is not identified in the IANA Equivalence Table, it is mapped onto an 'application/x400-bp' content as specified in RFC-1494.
When mapping nested multipart content to MHS, the IPMS.this-IPM field must always be generated by the gateway. An IPMS.subject field should also be generated where there is no 'real' heading, to present useful information to non-MIME X.400 UAs.
OID assignments define the mime-mhs arc under internet.mail(7).mime-mhs(1), with mime-mhs-headings(1) containing id-hex-partial-message(1) and id-hex-multipart-message(2), and mime-mhs-bodies(2) for body part equivalences.
The MultipartType IPMS HeadingExtension (OID id-hex-multipart-message) is an ENUMERATED type with values mixed(1), alternative(2), digest(3), parallel(4). It should be generated for all multipart content-types to enable round-trip fidelity.
The PartialMessage IPMS HeadingExtension (OID id-hex-partial-message) carries message/partial parameters: a SEQUENCE of INTEGER number, INTEGER total, and IA5String id. When present in MHS-to-MIME mapping, a message/partial content-type is generated.
The IANA maintains the 'IANA MHS/MIME Equivalence Table' mapping MHS body part OIDs to MIME content-type/subtype pairs. If a new MIME content-type/subtype is registered without a corresponding entry, IANA assigns it an OID from the arc defined in this memo.
Two mechanisms mapped by this document carry security risk: (1) binary file transfer carries inherent risks of malicious content, and (2) strong content typing can be used to automatically launch applications against received content, leaving the invoker vulnerable to application-specific viruses such as spreadsheet macros or PostScript commands that delete files.