RFC 1495

Mapping between X.400 and RFC-822 Message Bodies

📅 published August 1993, from ietf

RFC 1495 🎀 Mapping between X.400 and RFC-822 Message Bodies

Okay bestie, this is RFC 1495 💅 It's called "Mapping between X.400 and RFC-822 Message Bodies," and it was written in August 1993 for the Network Working Group. The five authors are H. Alvestrand (SINTEF DELAB), S. Kille (ISODE Consortium), R. Miles (Soft*Switch, Inc.), M. Rose (Dover Beach Consulting, Inc.), and S. Thompson (Soft*Switch, Inc.) ✨

It's a Standards Track document, an IAB standards track protocol to be exact 🧚 It updates RFC 1327, and the header doesn't list any RFCs it obsoletes.

Status of this Memo

This RFC specifies an IAB standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements 🦋 For the standardization state and status of this protocol, check the current edition of the "IAB Official Protocol Standards." Distribution of this memo is unlimited 🌸

   1.  Introduction .............................................    1
   2.  Approach .................................................    2
   3.  Mapping between X.400 and RFC-822 Message Bodies .........    3
   3.1  Mapping from X.400 to RFC-822 ...........................    4
   3.2  Mapping from RFC-822 to X.400 ...........................    5
   3.2.1 Asymmetric Mappings ....................................    6
   3.2.1.1 Message/External-Body ................................    6
   3.2.1.2 Message/Partial ......................................    6
   3.2.1.3 Nested Multipart Content-types .......................    6
   3.2.2 Multipart IPMS Heading Extension .......................    7
   4.  Mapping between X.400 and RFC-822 Message Headers ........    7
   5.  OID Assignments ..........................................    9
   6.  Security Considerations ..................................    9
   7.  Authors' Addresses .......................................   10
   8.  References ...............................................   11

1. Introduction ✨

Okay so the Internet community is a HUGE collection of networks that each run under their own autonomous administration 👑 but they all share one core set of protocols. Those are known as the Internet suite of protocols (or just "TCP/IP") 💖

Electronic mail on the Internet is mainly defined by one document, STD-11, RFC-822 [1], which sets the standard format for exchanging messages. RFC-822 has been immensely popular. In fact, the 822-connected Internet is bigger than the scope of the IP-connected Internet 🔥

RFC-822 gives you memo-style textual messages. Each message has two parts: the headers and the body. The headers are like the structured fields in an inter-office memo, while the body is free-form. Both parts are encoded using ASCII 🎀

Then the Internet Engineering Task Force (IETF) came out with a document called

Multipurpose Internet Mail Extensions

or MIME RFC-1341. The name is kinda misleading, ngl 🙈 MIME defines structure for Internet message bodies. It is not an extension to RFC-822.

Separately, the International standards community built a different framework in 1984 (some say that's the problem 💀). It's known as the OSI Message Handling System (MHS), or sometimes X.400.

Ever since X.400(84) showed up, people have been working on mappings between MHS and RFC-822. The most recent work here is RFC-1327 [3], which mainly covers translating the envelope and headers. This document is complimentary to RFC-1327 because it covers translating the message body 🦋 The mappings are largely symmetrical when it comes to MIME and MHS structuring semantics, though the MIME semantics are somewhat richer. To make the transformations reversible, MHS heading extensions carry the extra MIME semantics 🧚

Send your comments to the MIME-MHS mailing list: <mime-mhs@surfnet.nl> 💌

2. Approach ✨

The mappings were designed specifically to give optimal behavior in three different scenarios 💅

(1) Let a MIME user and an MHS user swap arbitrary binary content;

(2) Let MIME content-types "tunnel" through an MHS relay. That is, two MIME users can exchange content-types without loss through an MHS relay); and,

(3) Let MHS body parts "tunnel" through a MIME relay. That is, two MHS users can exchange body parts without loss through a MIME relay).

Other related scenarios can also be accommodated pretty easily 🌈

To make the mapping process work, the Internet Assigned Numbers Authority (IANA) keeps a table called the "IANA MHS/MIME Equivalence Table" 📋 Once an enterprise has registered an OID to describe an MHS body part, it should complete a matching registration with the IANA for a MIME content-type/subtype. In practice, the MIME content-type will be "application," with a suitable choice of sub-type and possible parameters. If a new MIME content-type/subtype gets registered with the IANA without a matching entry in the Equivalence Table, the IANA will assign it an OID from the arc defined in this memo. See [4], section 5 for details 🫶

The companion document, "Equivalences between 1988 X.400 and RFC-822 Message Bodies"[4], sets up the initial configuration of this table. Both this document and the companion document use the notational conventions of RFC-1327 🌸

3. Mapping between X.400 and RFC-822 Message Bodies 🦋

An MHS message is made up of an IPMS.heading and an IPMS.body. The IPMS.Body is a sequence of IPMS.BodyParts, and an IPMS.BodyPart can be a nested message (IPMS.MessageBodyPart) 💜

A MIME message has headers and a content. For discussion purposes, the content can be structured (multipart or message) or atomic (everything else). An element of structured content can be a message or a content. Both message and structured content have subtypes that don't have direct analogies in MHS 😭

The mapping between X.400 and RFC-822 message bodies defined in this document is symmetrical for these cases:

(1) any atomic body part

(2) multipart: digest and mixed subtypes

(3) message/rfc822

RFC-1327 specifies the mappings for headers. Section 4 explains how this document modifies those mappings. When mapping between an MHS body and a MIME content, the following algorithm is used:

3.1. Mapping from X.400 to RFC-822 ✨

This section swaps out the RFC-1327 text, starting at the bottom of page 84, where it reads:

The IPMS.Body is mapped into the RFC-822 message body. Each IPMS.BodyPart is converted to ASCII as follows:

and running up to and including page 86 of Section 5.3.4 of RFC-1327 💖

If the IPMS.Body

             If the IPMS.Body

                  Body ::=
                      SEQUENCE OF
                          BodyPart

   consists of a single body part, then the RFC-822 message body is
   constructed as the MIME content corresponding to that body part.

Okay, so if the IPMS.Body has just one body part, the RFC-822 message body is built as the MIME content that matches that body part 🎀

If the body part is an IPMS.MessageBodyPart (forwarded IPM), you apply the mapping recursively. Otherwise, to map a specific MHS body part to a MIME content-type, you check the IANA MHS/MIME Equivalence table. If the MHS body part isn't listed in that table, the body part gets mapped onto an application/x400-bp content, as specified in [4] 🧚

If the IPMS.Body has more than one body part, the RFC-822 message body is built as a multipart/mixed content-type. The exception is when all of the body parts are messages, in which case it's mapped to a multipart/digest content-type 🔥 Each component of the multipart content-type corresponds to an IPMS.BodyPart, and the order of the body parts in the IPMS.Body is preserved 👑

There's one case that gets special treatment 🙈 If the IPMS.Body consists solely of a single IA5Text body part, then the RFC822 message body is NOT marked as a MIME content. This stops RFC822 mailers from invoking MIME functions when they don't need to 💅

3.2. Mapping from RFC-822 to X.400 ✨

First, replace the first paragraph of Section 5.1.3 on page 72 of RFC-1327 so it reads like this:

The IPM (IPMS Service Request) is generated according to the rules of this section. The IPMS.body usually consists of one IPMS.BodyPart of type IPMS.IA5TextBodyPart with IPMS.IA5TextBodyPart.parameters.repertoire set to the default (ia5), which contains the body of the RFC-822 message. However, if the 822.MIME-Version header field is present, a special algorithm is used to generate the IPMS.body.

Second, swap out the "Comments:" paragraph on page 74 for this version:

Comments: If an 822.MIME-Version header field is not present, generate an IPMS.Bodypart of type IPMS.IA5TextBodyPart with IPMS.IA5TextBodyPart.parameters.repertoire set to the default (ia5), containing the value of the fields, preceded by the string "Comments: ". This body part shall precede the other one.

Third, add the rest of this section to the end of Section 5.1.3 of RFC-1327 🌈

If the 822.MIME-Version header field is present, the following mapping rules generate the IPMS.body 🎀

If the MIME content-type is one of:

(1) any atomic body part

(2) multipart: digest and mixed subtypes

(3) message/rfc822

then the symmetric mapping applies as described in Section 6.1. Note that multipart content-types should be marked with the IPMS.HeadingExtension described below 💖

Otherwise, three cases remain, and we'll go through each one in turn 🦋

3.2.1. Asymmetric Mappings ✨

3.2.1.1. Message/External-Body

This gets mapped into a mime-body-part, as specified in [4] 🧚

3.2.1.2. Message/Partial

This gets mapped onto a message, and the following heading extension is used. The extension is derived from the message/partial parameters 💅

                  partial-message  HEADING-EXTENSION
                      VALUE PartialMessage
                      ::= id-hex-partial-message

                  PartialMessage ::=
                      SEQUENCE {
                          number INTEGER,
                          total  INTEGER,
                          id     IA5String
                      }

If this heading is present when mapping from MHS to MIME, then a message/partial should be generated 🫶

3.2.1.3. Nested Multipart Content-types 🎀

okay so bestie, in MIME a multipart content is a set of content-types, not a message with a set of content-types 🧚 (it sounds like a tiny difference, but it matters!). Still, a nested multipart content will always get mapped to an IPMS.MessageBodyPart, with an IPMS.BodyPart for each content-type inside it 🌸.

The only mandatory field in the heading is IPMS.this-IPM, and it must always be generated (by the gateway) 🔥. An IPMS.subject field should also be generated wherever there's no "real" heading 🙈. This gives useful info to the non-MIME capable X.400(88) UAs and to all the X.400(84) UAs 🫶.

The IPM.subject values for each type are:

mixed: "Multipart Message"
alternative: "Alternate Body Parts containing the same information"
digest: "Message Digest"
parallel: "Body Parts to be interpreted in parallel"

3.2.2. Multipart IPMS Heading Extension ✨

the following IPMS.HeadingExtension should be generated for all multipart content-types, with the enumerated value set based on the subtype 💅:

                  multipart-message HEADING-EXTENSION
                      VALUE MultipartType
                      ::= id-hex-multipart-message

                  MultipartType ::=
                      ENUMERATED {
                          mixed(1),
                          alternative(2),
                          digest(3),
                          parallel(4)
                      }

If this heading shows up when you're mapping from MHS to MIME, then the matching multipart content-type should be generated 🦋.

4. Mapping between X.400 and RFC-822 Message Headers ✨

okay this section is all about the headers, and it's giving edits. Each one replaces or changes a specific paragraph or procedure in [3] (RFC-1327), so here's what changes 💖.

First up, replace the first paragraph of Section 3.3.4 on page 26 of RFC-1327 with this:

In cases where T.61 strings are used only for conveying human-interpreted information, the aim of this mapping is to render the characters appropriately in the remote character set, rather than to maximize reversibility. For these cases, the following steps are followed to find an appropriate encoding: 1) If all the characters in the string are contained within the ASCII repertoire, the string is simply copied. 2) If all the characters in the string are from an IANA-registered character set, then the appropriate encoded-word(s) according to [5] are generated instead. 3) If the characters in the string are from a character set which is not registered with the IANA, then the mappings to IA5 defined in CCITT Recommendation X.408 (1988) shall be used [CCITT/ISO88a]. These will then be encoded in ASCII. This approach will only be used for human-readable information (Subject and FreeForm Name). When mapping from an RFC-822 header, when an encoded-word (as defined in [5]) is encountered: 1) If all the characters contained therein are mappable to T.61, the string content shall be converted into T.61. 2) Otherwise, the encoded-word shall be copied directly into the T.61 string.

Next, procedure "2a" on page 56 of RFC-1327 gets updated 🌈. If IPMS.ORDescriptor.free-form-name is present, convert it to ASCII or T.61 (Section 3.3.4), and use that as the 822.phrase component of the 822.mailbox construct 🔥.

Then the final paragraph of procedure "2" on page 55 of RFC-1327 changes to this. The string gets encoded into T.61 or ASCII using a human-oriented mapping (as described in Section 3.3.4). If the string is not null, it gets assigned to IPMS.ORDescriptor.free-form.name 🫶.

The second paragraph of procedure "3" on page 55 of RFC-1327 also gets an update 💅. If the 822.group construct is present, any included 822.mailbox is encoded as above to generate a separate IPMS.ORDescriptor. The 822.group is mapped to T.61 or ASCII (as described in Section 3.3.4), and an IPMS.ORDescriptor with only a free-form-name component is built from it 🧚.

Procedure "822.Subject" on page 62 of RFC-1327 becomes: mapped to IMPS.Heading.subject. The field-body uses the human-oriented mapping referenced in Section 3.3.4 ✨.

Last one, procedure "IPMS.Heading.subject" on page 71 of RFC-1327 is updated too 🦋. It gets mapped to "Subject:". The contents are converted to ASCII or T.61 (Section 3.3.4). Any CRLF are not mapped, but they're used as the points where the subject field must be folded 💖.

5. OID Assignments 👑

here are the OID assignments, bestie 🧚:

   MIME-MHS DEFINITIONS ::= BEGIN


   mail OBJECT IDENTIFIER ::= { internet 7 }

   mime-mhs OBJECT IDENTIFIER ::= { mail 1 }

   mime-mhs-headings OBJECT IDENTIFIER ::= { mime-mhs 1 }

   id-hex-partial-message OBJECT IDENTIFIER ::=
           { mime-mhs-headings 1 }

   id-hex-multipart-message OBJECT IDENTIFIER ::=
           { mime-mhs-headings 2 }


   mime-mhs-bodies OBJECT IDENTIFIER ::= { mime-mhs 2 }


   END

6. Security Considerations 💀

okay, serious moment, bestie 🙈. There are no explicit security provisions in this document. BUT a warning is in order. This document maps two mechanisms between RFC822 and X.400 that could cause problems.

The first is the transfer of binary files. The inherent risks are well known and won't be reiterated here 💀.

The second is the propagation of strong content typing. The typing can be used to automatically "launch" or initiate applications against those contents. Any such launching leaves the invoker vulnerable to application-specific viruses, like a spreadsheet macro or a Postscript command that deletes files 😭. See [2], Section 7.4.2 for a Postscript-specific discussion of this issue 🫶.

7. Authors' Addresses 🌸

the authors, in all their glory 💜:

Harald Tveit Alvestrand
SINTEF DELAB
N-7034 Trondheim
NORWAY

EMail: Harald.Alvestrand@delab.sintef.no


Steve Kille
ISODE Consortium
P.O. Box 505
London
SW11 1DX
England

Phone: +44-71-223-4062
EMail: S.Kille@ISODE.COM


Robert S. Miles
Soft*Switch, Inc.
640 Lee Road
Wayne, PA 19087

Phone: (215) 640-7556
EMail: rsm@spyder.ssw.com


Marshall T. Rose
Dover Beach Consulting, Inc.
420 Whisman Court
Mountain View, CA  94043-2186
US

Phone: +1 415 968 1052
Fax:   +1 415 968 2510
EMail: mrose@dbc.mtview.ca.us


Steven J. Thompson
Soft*Switch, Inc.
640 Lee Road
Wayne, PA 19087

Phone: (215) 640-7556
EMail: sjt@gateway.ssw.com

8. References 📚

the receipts, bestie 🎀:

[1] Crocker, D., "Standard for the Format of ARPA Internet Text
    Messages", STD 11, RFC 822, UDEL, August 1982.

[2] Borenstein, N., and N. Freed, "MIME: Mechanisms for Specifying
    and Describing the Format of Internet Message Bodies", RFC 1341,
    Bellcore, Innosoft, June 1992.

[3] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021
    and RFC-822", RFC 1327, University College London, May 1992.

[4] Alvestrand, H., and S. Thompson, "Equivalences between 1988 X.400
    and RFC-822 Message Bodies", RFC 1494, SINTEF DELAB, Soft*Switch,
    Inc., August 1993.

[5] Moore, K., "Representation of Non-ASCII Text in Internet Message
    Headers Message Bodies", RFC 1342, University of Tennesse, June
    1992.

📦 where this page comes from

ietf: rfc1495 1993-08
💖 girlified by claude-haiku-5-5 on 2026-10-15: a language model's rewrite of the original, under its terms