1495
PROPOSED STANDARD
Mapping between X.400 and RFC-822 Message Bodies (Obsoleted)
Authors: H. Alvestrand, S. Kille, R. Miles, M. Rose, S. Thompson
Date: August 1993
Area: app
Working Group: mimemhs
Stream: IETF
Abstract
Since the introduction of X.400(84), there has been work ongoing for defining mappings between MHS and RFC-822. The most recent work in this area is RFC-1327 [3], which focuses primarily on translation of envelope and headers. This document is complimentary to RFC-1327 as it focuses on translation of the message body. [STANDARDS-TRACK]
RFC 1495
Obsoleted by: 2156 PROPOSED STANDARD
Network Working Group H. Alvestrand
Request for Comments: 1495 SINTEF DELAB
Updates: <a href="./rfc1327">1327</a> S. Kille
ISODE Consortium
R. Miles
Soft*Switch, Inc.
M. Rose
Dover Beach Consulting, Inc.
S. Thompson
Soft*Switch, Inc.
August 1993
<span class="h1">Mapping between X.400 and <a href="./rfc822">RFC-822</a> Message Bodies</span>
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.
Table of Contents
<a href="#section-1">1</a>. Introduction ............................................. <a href="#page-1">1</a>
<a href="#section-2">2</a>. Approach ................................................. <a href="#page-2">2</a>
<a href="#section-3">3</a>. Mapping between X.400 and <a href="./rfc822">RFC-822</a> Message Bodies ......... <a href="#page-3">3</a>
<a href="#section-3.1">3.1</a> Mapping from X.400 to <a href="./rfc822">RFC-822</a> ........................... <a href="#page-4">4</a>
<a href="#section-3.2">3.2</a> Mapping from <a href="./rfc822">RFC-822</a> to X.400 ........................... <a href="#page-5">5</a>
<a href="#section-3.2.1">3.2.1</a> Asymmetric Mappings .................................... <a href="#page-6">6</a>
<a href="#section-3.2.1.1">3.2.1.1</a> Message/External-Body ................................ <a href="#page-6">6</a>
<a href="#section-3.2.1.2">3.2.1.2</a> Message/Partial ...................................... <a href="#page-6">6</a>
<a href="#section-3.2.1.3">3.2.1.3</a> Nested Multipart Content-types ....................... <a href="#page-6">6</a>
<a href="#section-3.2.2">3.2.2</a> Multipart IPMS Heading Extension ....................... <a href="#page-7">7</a>
<a href="#section-4">4</a>. Mapping between X.400 and <a href="./rfc822">RFC-822</a> Message Headers ........ <a href="#page-7">7</a>
<a href="#section-5">5</a>. OID Assignments .......................................... <a href="#page-9">9</a>
<a href="#section-6">6</a>. Security Considerations .................................. <a href="#page-9">9</a>
<a href="#section-7">7</a>. Authors' Addresses ....................................... <a href="#page-10">10</a>
<a href="#section-8">8</a>. References ............................................... <a href="#page-11">11</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The Internet community is a large collection of networks under
autonomous administration, but sharing a core set of protocols.
These are known as the Internet suite of protocols (or simply
"TCP/IP").
Use of electronic-mail in the Internet is defined primarily by one
<span class="grey">Alvestrand, Kille, Miles, Rose & Thompson [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc1495">RFC 1495</a> MHS/RFC-822 Message Body Mapping August 1993</span>
document, STD-11, <a href="./rfc822">RFC-822</a> [<a href="#ref-1" title=""Standard for the Format of ARPA Internet Text Messages"">1</a>], which defines the standard format for
the exchange of messages. <a href="./rfc822">RFC-822</a> has proven immensely popular; in
fact, the 822-connected Internet, is larger than the scope of the
IP-connected Internet.
The framework provided by <a href="./rfc822">RFC-822</a> allows for memo-based textual
messages. Each message consists of two parts: the headers and the
body. The headers are analogous to the structured fields found in an
inter-office memo, whilst the body is free-form. Both parts are
encoded using ASCII.
Recently, the Internet Engineering Task Force (IETF) has developed an
document called,
Multipurpose Internet Mail Extensions
or MIME <a href="./rfc1341">RFC-1341</a>. The title is actually misleading. MIME defines
structure for Internet message bodies. It is not an extension to
<a href="./rfc822">RFC-822</a>.
Independently of this, the International standards community
developed a different framework in 1984 (some say that's the
problem). This framework is known as the OSI Message Handling System
(MHS) or sometimes X.400.
Since the introduction of X.400(84), there has been work ongoing for
defining mappings between MHS and <a href="./rfc822">RFC-822</a>. The most recent work in
this area is <a href="./rfc1327">RFC-1327</a> [<a href="#ref-3" title=""Mapping between X.400(1988) / ISO 10021 and RFC-822"">3</a>], which focuses primarily on translation of
envelope and headers. This document is complimentary to <a href="./rfc1327">RFC-1327</a> as
it focuses on translation of the message body. The mappings defined
are largely symmetrical with respect to MIME and MHS structuring
semantics, although the MIME semantics are somewhat richer. In order
to provide for reversible transformations, MHS heading extensions are
used to carry the additional MIME semantics.
Please send comments to the MIME-MHS mailing list:
<mime-mhs@surfnet.nl>.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Approach</span>
The mappings have been specifically designed to provide optimal
behavior for three different scenarios:
(1) Allow a MIME user and an MHS user to exchange an arbitrary binary
content;
(2) Allow MIME content-types to "tunnel" through an MHS relay that
is, two MIME users can exchange content-types without loss
<span class="grey">Alvestrand, Kille, Miles, Rose & Thompson [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc1495">RFC 1495</a> MHS/RFC-822 Message Body Mapping August 1993</span>
through an MHS relay); and,
(3) Allow MHS body parts to "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 easily accommodated.
To facilitate the mapping process, the Internet Assigned Numbers
Authority (IANA) maintains a table termed the "IANA MHS/MIME
Equivalence Table". Once an enterprise has registered an OID to
describe an MHS body part, it should complete a corresponding
registry with the IANA for a MIME content-type/subtype. In practice,
the corresponding content-type will be "application", with an
appropriate choice of sub-type and possible parameters. If a new
MIME content-type/subtype is registered with the IANA without a
corresponding entry in the Equivalence Table, the IANA will assign it
an OID, from the arc defined in this memo. See [<a href="#ref-4" title=""Equivalences between 1988 X.400 and RFC-822 Message Bodies"">4</a>], section 5 for
details.
The companion document, "Equivalences between 1988 X.400 and <a href="./rfc822">RFC-822</a>
Message Bodies"[<a href="#ref-4" title=""Equivalences between 1988 X.400 and RFC-822 Message Bodies"">4</a>], defines the initial configuration of this table.
The mappings described in both this document and the companion
document use the notational conventions of <a href="./rfc1327">RFC-1327</a>.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Mapping between X.400 and <a href="./rfc822">RFC-822</a> Message Bodies</span>
MHS messages are comprised of an IPMS.heading and an IPMS.body. The
IPMS.Body is a sequence of IPMS.BodyParts. An IPMS.BodyPart may be a
nested message (IPMS.MessageBodyPart).
A MIME message consists of headers and a content. For the purpose of
discussion, the content may be structured (multipart or message), or
atomic (otherwise). An element of a structured content may be a
message or a content. Both message and structured content have
subtypes which do not have direct analogies in MHS.
The mapping between X.400 and <a href="./rfc822">RFC-822</a> message bodies which this
document defines is symmetrical for the following cases:
(1) any atomic body part
(2) multipart: digest and mixed subtypes
(3) message/rfc822
<a href="./rfc1327">RFC-1327</a> specifies the mappings for headers. <a href="#section-4">Section 4</a> describes how
those mappings are modified by this document. When mapping between
<span class="grey">Alvestrand, Kille, Miles, Rose & Thompson [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc1495">RFC 1495</a> MHS/RFC-822 Message Body Mapping August 1993</span>
an MHS body and a MIME content, the following algorithm is used:
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Mapping from X.400 to <a href="./rfc822">RFC-822</a></span>
This section replaces the text in <a href="./rfc1327">RFC-1327</a> starting at the bottom of
page 84,
The IPMS.Body is mapped into the <a href="./rfc822">RFC-822</a> message body. Each
IPMS.BodyPart is converted to ASCII as follows:
and continuing up to and including page 86 of Section 5.3.4 of <a href="./rfc1327">RFC-</a>
<a href="./rfc1327">1327</a>.
If the IPMS.Body
Body ::=
SEQUENCE OF
BodyPart
consists of a single body part, then the <a href="./rfc822">RFC-822</a> message body is
constructed as the MIME content corresponding to that body part.
If the body part is an IPMS.MessageBodyPart (forwarded IPM), the
mapping is applied recursively. Otherwise, to map a specific MHS
body part to a MIME content-type, the IANA MHS/MIME Equivalence table
is consulted. If the MHS body part is not identified in this table,
then the body-part is mapped onto an "application/x400-bp" content,
as specified in [<a href="#ref-4" title=""Equivalences between 1988 X.400 and RFC-822 Message Bodies"">4</a>].
If the IPMS.Body consists of more than one body part, then the <a href="./rfc822">RFC-</a>
<a href="./rfc822">822</a> message body is constructed as a
multipart/mixed
content-type, unless all of the body parts are messages, in which
case it is mapped to a
multipart/digest
content-type. Each component of the multipart content-type
corresponds to a IPMS.BodyPart, preserving the ordering of the body
parts in the IPMS.Body.
There is one case which gets special treatement. If the IPMS.Body
consists solely of a single IA5Text body part, then the <a href="./rfc822">RFC822</a>
message body is NOT marked as a MIME content. This prevents <a href="./rfc822">RFC822</a>
mailers from invoking MIME function unnecessarily.
<span class="grey">Alvestrand, Kille, Miles, Rose & Thompson [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc1495">RFC 1495</a> MHS/RFC-822 Message Body Mapping August 1993</span>
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Mapping from <a href="./rfc822">RFC-822</a> to X.400</span>
First, replace the first paragraph of <a href="#section-5.1.3">Section 5.1.3</a> on page 72 of
<a href="./rfc1327">RFC-1327</a> to read as:
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 <a href="./rfc822">RFC-822</a>
message. However, if the 822.MIME-Version header field is
present, a special algorithm is used to generate the IPMS.body.
Second, replace the "Comments:" paragraph on page 74 to reads as:
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 preceed the other one.
Third, add the remainder of this section to the end of <a href="./rfc1327#section-5.1.3">Section 5.1.3
of RFC-1327</a>.
If the 822.MIME-Version header field is present, the following
mapping rules are used to generate the IPMS.body.
If the MIME content-type is one of:
(1) any atomic body part
(2) multipart: digest and mixed subtypes
<span class="grey">Alvestrand, Kille, Miles, Rose & Thompson [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc1495">RFC 1495</a> MHS/RFC-822 Message Body Mapping August 1993</span>
(3) message/rfc822
then the symmetric mapping applies as described in <a href="#section-6.1">Section 6.1</a>. Note
that the multipart content-types should be marked with the
IPMS.HeadingExtension described below.
Otherwise, three cases remain, which are discussed in turn.
<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>. Asymmetric Mappings</span>
<span class="h5"><a class="selflink" id="section-3.2.1.1" href="#section-3.2.1.1">3.2.1.1</a>. Message/External-Body</span>
This is mapped into a mime-body-part, as specified in [<a href="#ref-4" title=""Equivalences between 1988 X.400 and RFC-822 Message Bodies"">4</a>].
<span class="h5"><a class="selflink" id="section-3.2.1.2" href="#section-3.2.1.2">3.2.1.2</a>. Message/Partial</span>
This is 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.
<span class="h5"><a class="selflink" id="section-3.2.1.3" href="#section-3.2.1.3">3.2.1.3</a>. Nested Multipart Content-types</span>
In MIME, a multipart content refers to a set of content-types, not a
message with a set of content-types. However, a nested multipart
content will always be mapped to an IPMS.MessageBodyPart, with an
IPMS.BodyPart for each contained content-type.
The only mandatory field in the heading is the IPMS.this-IPM, which
must always be generated (by the gateway). A IPMS.subject field
should also be generated where there is no "real" heading. This will
present useful information to the non-MIME capable X.400(88) and to
all X.400(84) UAs.
<span class="grey">Alvestrand, Kille, Miles, Rose & Thompson [Page 6]</span><span id="page-7" ></span>
<span class="grey"><a href="./rfc1495">RFC 1495</a> MHS/RFC-822 Message Body Mapping August 1993</span>
The IPM.subject fields for the various types are:
mixed: "Multipart Message"
alternative: "Alternate Body Parts containing the same information"
digest: "Message Digest"
parallel: "Body Parts to be interpreted in parallel"
<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a>. Multipart IPMS Heading Extension</span>
The following IPMS.HeadingExtension should be generated for all
multipart content-types, with the enumerated value set according to
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 is present when mapping from MHS to MIME, then the
appropriate multipart content-type should be generated.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Mapping between X.400 and <a href="./rfc822">RFC-822</a> Message Headers</span>
Replace the first paragraph of <a href="#section-3.3.4">Section 3.3.4</a> on page 26 of <a href="./rfc1327">RFC-1327</a>
to read as:
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 [<a href="#ref-5" title=""Representation of Non-ASCII Text in Internet Message Headers Message Bodies"">5</a>] 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
<span class="grey">Alvestrand, Kille, Miles, Rose & Thompson [Page 7]</span><span id="page-8" ></span>
<span class="grey"><a href="./rfc1495">RFC 1495</a> MHS/RFC-822 Message Body Mapping August 1993</span>
[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 <a href="./rfc822">RFC-822</a> header, when an encoded-word (as
defined in [<a href="#ref-5" title=""Representation of Non-ASCII Text in Internet Message Headers Message Bodies"">5</a>]) 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.
Modify procedure "2a" on page 56 of <a href="./rfc1327">RFC-1327</a> to read as:
If the IPMS.ORDescriptor.free-form-name is present, convert it
to ASCII or T.61 (<a href="#section-3.3.4">Section 3.3.4</a>), and use this as the 822.phrase
component of the 822.mailbox construct.
Modify the final paragraph of procedure "2" on page 55 of <a href="./rfc1327">RFC-1327</a> to
read as:
The string is then encoded into T.61 or ASCII using a human-
oriented mapping (as described in <a href="#section-3.3.4">Section 3.3.4</a>). If the string
is not null, it is assigned to IPMS.ORDescriptor.free-form.name.
Modify the second paragraph of procedure "3" on page 55 of <a href="./rfc1327">RFC-1327</a>
to read as:
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
<a href="#section-3.3.4">Section 3.3.4</a>), and an IPMS.ORDescriptor with only an free-
form-name component is built from it.
Modify procedure "822.Subject" on page 62 of <a href="./rfc1327">RFC-1327</a> to read as:
Mapped to IMPS.Heading.subject. The field-body uses the human-
oriented mapping referenceed in <a href="#section-3.3.4">Section 3.3.4</a>.
Modify procedure "IPMS.Heading.subject" on page 71 of <a href="./rfc1327">RFC-1327</a> to
read as:
Mapped to "Subject:". The contents are converted to ASCII or
T.61 (<a href="#section-3.3.4">Section 3.3.4</a>). Any CRLF are not mapped, but are used as
points at which the subject field must be folded.
<span class="grey">Alvestrand, Kille, Miles, Rose & Thompson [Page 8]</span><span id="page-9" ></span>
<span class="grey"><a href="./rfc1495">RFC 1495</a> MHS/RFC-822 Message Body Mapping August 1993</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. OID Assignments</span>
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
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
There are no explicit security provisions in this document. However,
a warning is in order. This document maps two mechanisms between
<a href="./rfc822">RFC822</a> 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; for
example, a spreadsheet macro or Postscript command that deletes
files. See [<a href="#ref-2" title=""MIME: Mechanisms for Specifying and Describing the Format of Internet Message Bodies"">2</a>], Section 7.4.2 for a Postscript-specific discussion
of this issue.
<span class="grey">Alvestrand, Kille, Miles, Rose & Thompson [Page 9]</span><span id="page-10" ></span>
<span class="grey"><a href="./rfc1495">RFC 1495</a> MHS/RFC-822 Message Body Mapping August 1993</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Authors' Addresses</span>
Harald Tveit Alvestrand
SINTEF DELAB
N-7034 Trondheim
NORWAY
EMail: [email protected]
Steve Kille
ISODE Consortium
P.O. Box 505
London
SW11 1DX
England
Phone: +44-71-223-4062
EMail: [email protected]
Robert S. Miles
Soft*Switch, Inc.
640 Lee Road
Wayne, PA 19087
Phone: (215) 640-7556
EMail: [email protected]
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: [email protected]
Steven J. Thompson
Soft*Switch, Inc.
640 Lee Road
Wayne, PA 19087
Phone: (215) 640-7556
EMail: [email protected]
<span class="grey">Alvestrand, Kille, Miles, Rose & Thompson [Page 10]</span><span id="page-11" ></span>
<span class="grey"><a href="./rfc1495">RFC 1495</a> MHS/RFC-822 Message Body Mapping August 1993</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
[<a id="ref-1">1</a>] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, <a href="./rfc822">RFC 822</a>, UDEL, August 1982.
[<a id="ref-2">2</a>] Borenstein, N., and N. Freed, "MIME: Mechanisms for Specifying
and Describing the Format of Internet Message Bodies", <a href="./rfc1341">RFC 1341</a>,
Bellcore, Innosoft, June 1992.
[<a id="ref-3">3</a>] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021
and <a href="./rfc822">RFC-822</a>", <a href="./rfc1327">RFC 1327</a>, University College London, May 1992.
[<a id="ref-4">4</a>] Alvestrand, H., and S. Thompson, "Equivalences between 1988 X.400
and <a href="./rfc822">RFC-822</a> Message Bodies", <a href="./rfc1494">RFC 1494</a>, SINTEF DELAB, Soft*Switch,
Inc., August 1993.
[<a id="ref-5">5</a>] Moore, K., "Representation of Non-ASCII Text in Internet Message
Headers Message Bodies", <a href="./rfc1342">RFC 1342</a>, University of Tennesse, June
1992.
Alvestrand, Kille, Miles, Rose & Thompson [Page 11]
Annotations
Select text to annotate