Yesterday, you probably saw an announcement from Harald Alvestrand
containing a proposal on mappings between MIME and MHS. For some time,
we (Bob, Steve, and Marshall) have been independently developing our own
proposal. Although Harald's proposal differs in the details from ours,
the approaches are similar. After a phone conversation with Harald, we
intend to follow this plan:
1. Sometime during the San Diego IETF, Harald and Marshall, along with
any other interested parties, will meet to examine the two proposals.
2. The outcome of this meeting will be a plan to progress one document
through the IETF to ultimately become the Internet-standard in this
area. This might be his document, our document, or a combination
thereof.
3. In order to facilitate outside participation for step 1, our
document is attached below.
One point which the four of us agree on is that it is critical that the
community achieve consensus as quickly as possible. That is, when we
come out of our meeting at the San Diego IETF, we will be looking for
focused discussion in an IETF working group to achieve timely resolution
for advancement to the IESG for consideration.
Thanks,
Robert Miles, Steve Thompson, Marshall Rose
///////
draft Mapping MHS/RFC-822 Message Bodies Mar 92
Mapping between X.400 and RFC-822 Message Bodies
Thu Mar 5 17:41:17 1992
Robert S. Miles
Soft.Switch, Inc.
rsm(_at_)spyder(_dot_)ssw(_dot_)com
Steve Thompson
Soft.Switch, Inc.
sjt(_at_)gateway(_dot_)ssw(_dot_)com
Marshall T. Rose
Dover Beach Consulting, Inc.
mrose(_at_)dbc(_dot_)mtview(_dot_)ca(_dot_)us
1. Status of this Memo
This draft document is being circulated for comment. If
consensus is reached in the IETF 822 Extensions Working Group,
it will be submitted to the RFC editor as a Proposed Standard
protocol specificiation. Please send comments to the authors.
Miles, Thompson, Rose [Page 1]
draft Mapping MHS/RFC-822 Message Bodies Mar 92
2. Introduction
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 document, RFC-822[1], which defines the standard format
for the exchange of messages. RFC-822 has proven immensely
popular; in fact, the 822-connected Internet, is larger than
the scope of the IP-connected Internet.
The framework provided by RFC-822 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-from. Both parts are encoded using ASCII.
Recently, the Internet Engineering Task Force (IETF) has
developed an document called
Multipurpose Internet Mail Extensions
or MIME, which is currently an Internet-draft. The title is
actually misleading. MIME defines structure for Internet
message bodies. It is not an extension to RFC-822.
Independently of this, since the introduction of X.400(84),
there has been work ongoing for defining mappings between
X.400 and RFC-822. The most recent work in this area is
termed RFC-1148bis, a revision to RFC-1148[2]:
Mapping between X.400(1988) / ISO 10021 and RFC 822
and is currently an Internet-Draft.
RFC-1148bis focuses primarily on translation of headers. Very
little effort is spent on translation of the message body.
This document specifies the mapping rules between X.400 and
RFC-822 message bodies, using MIME as the basis of body
translation. These rules are described using the notational
conventions of RFC-1148bis.
Miles, Thompson, Rose [Page 2]
draft Mapping MHS/RFC-822 Message Bodies Mar 92
3. Approach
The mappings defined herein have been specifically designed to
provide optimal behavior for three different scenarios:
(1) Allow an SMTP user and an X.400 user to exchange a binary
file;
(2) Allow MIME content-types to "tunnel" through an X.400
relay (that is, two MIME users can exchange content-types
without loss through an X.400 relay); and,
(3) Allow MHS body parts to "tunnel" through an SMTP relay
(that is, two X.400 users can exchange body parts without
loss through an SMTP relay).
Other, related, scenarios, can also be easily accomodated.
Some of the mappings defined herein are straight-forward and
entirely algorithmic. However, others mappings require the
use of a table containing equivalences between externally-
defined MHS body parts and correspondent MIME content-types
and parameters.
To facilitate the mapping process, the Internet Assigned
Numbers Authority (IANA) maintains such a table. Once an
enterprise has registered an OID to describe an MHS body part,
it should complete a corresponding registry with the IANA. In
practice, the corresponding content-type will be application,
with an appropriate choice of sub-type and possible
parameters. The initial configuration of this table is found
in Appendix A.
Miles, Thompson, Rose [Page 3]
draft Mapping MHS/RFC-822 Message Bodies Mar 92
4. Mapping between X.400 and RFC-822 Message Bodies
To map between X.400 and RFC-822, RFC-1148bis is used.
However, when message bodies are translated, the following
algorithms are used instead:
4.1. Mapping from X.400 to RFC-822
This section replaces the text in RFC-1148bis starting at the
bottom of page 84,
The IPMS.Body is mapped into the RFC 822 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
RFC-1148bis.
If the IPMS.Body
Body ::=
SEQUENCE OF
BodyPart
consists of more than one body part, then the RFC-822 message
body is constructed as a
multipart/mixed
content-type. Each component of the multipart/mixed content-
type corresponds to a IPMS.BodyPart, preserving the ordering
of the body parts in the IPMS.Body.
Otherwise, if the IPMS.Body consists of a single body part,
then the RFC-822 message body is constructed as the content
corresponding to that body part.
Miles, Thompson, Rose [Page 4]
draft Mapping MHS/RFC-822 Message Bodies Mar 92
4.1.1. IPMS.IA5TextBodyPart
IA5TextBodyPart ::=
SEQUENCE {
parameters
IA5TextParameters,
data
IA5TextData
}
IA5TextParameters ::=
SET {
repertoire[0]
Repertoire
DEFAULT ia5
}
IA5TextData ::=
IA5String
Repertoire ::=
ENUMERATED { ita2(2), ia5(5) }
This is mapped into a
Content-type: text/plain; charset=us-ascii
body part, regardless of the value of the associated
IPMS.IA5TextBodyPart.parameters.repertoire
parameter.
Miles, Thompson, Rose [Page 5]
draft Mapping MHS/RFC-822 Message Bodies Mar 92
4.1.2. IPMS.G3FacsimileBodyPart
G3FacsimileBodyPart ::=
SEQUENCE {
parameters
G3FacsimileParameters,
data
G3FacsimileData
}
G3FacsimileParameters ::=
SET {
number-of-pages[0]
INTEGER
OPTIONAL,
non-basic-parameters[1]
G3FacsimileNonBasicParameters
OPTIONAL
}
G3FacsimileData ::=
SEQUENCE OF BIT STRING
This is mapped into
Content-Type: image/g3fax
body part. If the
IPMS.G3FacsimileBodyPart.parameters.number-of-pages
parameter is present, this is treated as a content-type
parameter of
x-pages=value
If the
IPMS.G3FacsimileBodyPart.parameters.non-basic-parameters
parameter is present, it is ignored.
Miles, Thompson, Rose [Page 6]
draft Mapping MHS/RFC-822 Message Bodies Mar 92
4.1.3. IPMS.MessageBodyPart
MessageBodyPart ::=
SEQUENCE {
parameters
MessageParameters,
data
MessageData
}
MessageParameters ::=
SET {
delivery-time[0]
MessageDeliveryTime
OPTIONAL,
delivery-envelope[1]
OtherMessageDeliveryFields
OPTIONAL
}
MessageData ::=
IPM
This is mapped into a
Content-type: message/rfc822
content-type, by recursively applying the mapping algorithm
from X.400 to RFC-822. If the
IPMS.MessageBodyPart.parameters.delivery-time
parameter is present, it is mapped into a
822.Delivery-Date
header field and placed in the message. If the
IPMS.MessageBodyPart.parameters.delivery-envelope
parameter is present, it is used for the MTS abstract service
mappings.
Miles, Thompson, Rose [Page 7]
draft Mapping MHS/RFC-822 Message Bodies Mar 92
4.1.4. IPMS.ExternallyDefinedBodyPart
ExternallyDefinedBodyPart ::=
SEQUENCE {
parameters[0]
ExternallyDefinedParameters
OPTIONAL
data
ExternallyDefinedData
}
ExternallyDefinedParameters ::=
EXTERNAL
ExternallyDefinedData ::=
EXTERNAL
EXTERNAL ::=
[UNIVERSAL 8]
IMPLICIT SEQUENCE {
direct-reference
OBJECT IDENTIFIER
OPTIONAL,
indirect-reference
INTEGER
OPTIONAL
data-value-descriptor
ObjectDescriptor
OPTIONAL,
encoding
CHOICE {
single-ASN1-type[0]
ANY,
octet-aligned[1]
IMPLICIT OCTET STRING,
arbitrary[2]
IMPLICIT BIT STRING
}
}
Miles, Thompson, Rose [Page 8]
draft Mapping MHS/RFC-822 Message Bodies Mar 92
mIMEparameters OBJECT IDENTIFIER ::=
{ -- tbd -- }
MIMEparameters ::=
SEQUENCE OF
SEQUENCE {
key
PrintableString,
value
PrintableString
}
mIMEBodyPart OBJECT IDENTIFIER ::=
{ -- tbd -- }
If the
IPMS.ExternallyDefinedBodyPart.data.direct-reference
parameter is not present, then Section 4.1.5 describes how
this body part is mapped.
Otherwise, the mapping table maintained by the IANA is
consulted: if the value of the
IPMS.ExternallyDefinedBodyPart.data.direct-reference
parameter is found in the table, then the correspondent MIME
content-type and parameters are used. If the value of this
parameter is not found in the table, then the body part is
mapped to a
application/x-oid
content with a parameter attribute of
reference=identifier
where identifier is the value of the
IPMS.ExternallyDefinedBodyPart.data.direct-reference
parameter expressed using the quoted string representation
defined in Section 3.3.7 of RFC1148bis.
Miles, Thompson, Rose [Page 9]
draft Mapping MHS/RFC-822 Message Bodies Mar 92
Regardless, if the
IPMS.ExternallyDefinedBodyPart.parameters
parameter is present, and the
IPMS.ExternallyDefinedBodyPart.parameters.direct-reference
parameter is also present, and it has the value
mIMEparameters
then the
IPMS.ExternallyDefinedBodyPart.parameters.encoding.
single-ASN1-type
contains a MIMEParameters parameter. Each key/value pair
present is mapped to a MIME parameter of the form:
key=value
In general, any parameter acceptable for a subtype of
application may be present. In addition, the key
creation-date
may also be present, to indicate the creation-date of the
object corresponding to the body part (e.g., a file creation
date). Note that the value for such a key uses the ASN.1
UTCTime
syntax and must be translated into the correspondent 822
date-time
syntax.
If any of these conditions do not hold for the
IPMS.ExternallyDefinedBodyPart.parameters
parameter, then it is ignored.
Miles, Thompson, Rose [Page 10]
draft Mapping MHS/RFC-822 Message Bodies Mar 92
4.1.5. Other Body Parts
Any body part not discussed in the preceeding text is mapped
into a
application/x-mhs
content-type. The MIME content contains the entire ASN.1
value, including the tag used in the IPMS.BodyPart CHOICE.
Further, a content-type parameter of
choice=tag
is present, where tag corresponds to the textual tag used in
the IPMS.BodyPart CHOICE.
Miles, Thompson, Rose [Page 11]
draft Mapping MHS/RFC-822 Message Bodies Mar 92
4.2. Mapping from RFC-822 to X.400
First, replace the first paragraph of Section 5.1.3 on page 72
of RFC-1148bis 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
RFC-822 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.
Miles, Thompson, Rose [Page 12]
draft Mapping MHS/RFC-822 Message Bodies Mar 92
Third, add the remainder of this section to the end of Section
5.1.3 of RFC-1148bis.
If the 822.MIME-Version header field is present, the following
mapping rules are used to generate the IPMS.body.
If the content-type is
multipart/mixed
then the IPMS.Body consists of multiple body parts, each
corresponding to a component of the multipart/mixed content-
type, preserving the ordering of the components in the
content-type.
Otherwise, the IPMS.Body consists of a single body part,
constructed according to one of the rules below.
Miles, Thompson, Rose [Page 13]
draft Mapping MHS/RFC-822 Message Bodies Mar 92
4.2.1. text/plain
If the
charset
parameter is not present, or, if present, it is not equal to
us-ascii
then Section 4.2.7 describes how this content-type is mapped.
Otherwise, this is mapped into a
IPMS.IA5TextBodyPart
body part. The
IPMS.IA5TextBodyPart.parameters.repertoire
parameter is set to ia5.
4.2.2. image/g3fax
This is mapped into a
IPMS.G3FacsimileBodyPart
body part. If the
x-pages=value
parameter is present, then this is mapped into the
IPMS.G3FacsimileBodyPart.parameters.number-of-pages
parameter. Otherwise, this parameter shall not present. The
IPMS.G3FacsimileBodyPart.parameters.non-basic-parameters
parameter shall not be present.
Miles, Thompson, Rose [Page 14]
draft Mapping MHS/RFC-822 Message Bodies Mar 92
4.2.3. message/rfc822
This is mapped into a
IPMS.MessageBodyPart
body part, by recursively applying the mapping algorithm from
RFC-822 to X.400. If the
822.Delivery-Date
header field is present, it is mapped into the
IPMS.MessageBodyPart.parameters.MessageDeliveryTime
parameter. Otherwise, this parameter shall not be present.
The
IPMS.MessageBodyPart.parameters.OtherMessageDeliveryFields
parameter shall not be present.
Miles, Thompson, Rose [Page 15]
draft Mapping MHS/RFC-822 Message Bodies Mar 92
4.2.4. MIME/MHS Body Part Equivalance
If the content-type is found in the mapping table maintained
by the IANA, this is mapped into a
IPMS.ExternallyDefinedBodyPart
body part. The
IPMS.ExternallyDefinedBodyPart.data.direct-reference
parameter will be set to the corresponding OBJECT IDENTIFIER
in the table, and the contents will be placed into the
IPMS.ExternallyDefinedBodyPart.data.encoding.octet-aligned
parameter. If any parameters are present with the content-
type, then a
IPMS.ExternallyDefinedBodyPart.parameters
parameter will be constructed accordingly. The
IPMS.ExternallyDefinedBodyPart.parameters.direct-reference
parameter will have the value
mIMEparameters
and the
IPMS.ExternallyDefinedBodyPart.parameters.encoding.
single-ASN1-type
will contain a MIMEParameters parameter. For each parameter
present with the content-type, a key/value pair will be added,
in order, to the MIMEParameters parameter.
Miles, Thompson, Rose [Page 16]
draft Mapping MHS/RFC-822 Message Bodies Mar 92
4.2.5. application/x-oid
If the
reference=identifier
parameter is not present, then Section 4.2.7 describes how
this content-type is mapped. Otherwise, the content-type is
mapped into a
IPMS.ExternallyDefinedBodyPart
body part. The
IPMS.ExternallyDefinedBodyPart.data.direct-reference
parameter will be set to the value of the
reference
parameter, and the contents will be placed into the
IPMS.ExternallyDefinedBodyPart.data.encoding.octet-aligned
parameter. If any parameters are present with the content-
type, then a
IPMS.ExternallyDefinedBodyPart.parameters
parameter will be constructed accordingly. The
IPMS.ExternallyDefinedBodyPart.parameters.direct-reference
parameter will have the value
mIMEparameters
and the
IPMS.ExternallyDefinedBodyPart.parameters.encoding.
single-ASN1-type
will contain a MIMEParameters parameter. For each parameter
present with the content-type, a key/value pair will be added,
in order, to the MIMEParameters parameter.
Miles, Thompson, Rose [Page 17]
draft Mapping MHS/RFC-822 Message Bodies Mar 92
4.2.6. application/x-mhs
This is mapped into a
IPMS.BodyPart
body part. The
choice=tag
parameter, if present, is ignored.
Miles, Thompson, Rose [Page 18]
draft Mapping MHS/RFC-822 Message Bodies Mar 92
4.2.7. Other Content-Types
Any content-type not discussed in the preceeding text is
mapped into a
IPMS.ExternallyDefinedBodyPart
body part. Note that this includes any
multipart/mixed
content-types which do not occur at the outer-most level of a
message.
The
IPMS.ExternallyDefinedBodyPart.parameters
parameter shall not be present. The
IPMS.ExternallyDefinedBodyPart.data.direct-reference
is set to
mIMEBodyPart
The
IPMS.ExternallyDefinedBodyPart.data.encoding.octet-aligned
parameter is set to the content-type, as if part of an RFC-822
message (i.e., the body part is represented in the ASCII
repertoire). Hence, the
IPMS.ExternallyDefinedBodyPart.data.encoding.octet-aligned
parameter consists of one or more Content- header fields,
possibly followed by a blank-line and the contents.
Miles, Thompson, Rose [Page 19]
draft Mapping MHS/RFC-822 Message Bodies Mar 92
5. Appendix A: MIME/MHS Body Part Registrations
To facilitate the process of mapping body parts, the IANA
maintains a table containing equivalences between OBJECT
IDENTIFIERs and corresponding MIME content-types and
parameters. Once an enterprise has registered an OID to
describe an MHS body part, it should complete a corresponding
registry with the IANA (iana(_at_)isi(_dot_)edu).
The initial configuration of this table is:
MHS OBJECT IDENTIFIER MIME CONTENT
--------------------- ------------
id-et-ia5-text [X.420(88)/Annex I] text/plain;
charset=us-ascii
id-et-g3-facsimile [X.420(88)/Annex I] image/g3fax;
x-pages=number-of-pages
id-et-message [X.420(88)/Annex I] message/rfc822
mIMEBodyPart (see note 1)
5.1. note 1: mIMEBodyPart
This OID is used to denote a MIME content encapsulated as an
MHS externally-defined body part. The
IPMS.ExternallyDefinedBodyPart.data.encoding.octet-aligned
parameter is set to the content-type, as if part of an RFC-822
message (i.e., the body part is represented in the ASCII
repertoire). Hence, the
IPMS.ExternallyDefinedBodyPart.data.encoding.octet-aligned
consists of one or more Content- header fields, possibly
followed by a blank-line and the contents.
The
IPMS.ExternallyDefinedBodyPart.parameters
parameter is not present.
Miles, Thompson, Rose [Page 20]
draft Mapping MHS/RFC-822 Message Bodies Mar 92
Table of Contents
1 Status of this Memo ................................... 1
2 Introduction .......................................... 2
3 Approach .............................................. 3
4 Mapping between X.400 and RFC-822 Message Bodies ...... 4
4.1 Mapping from X.400 to RFC-822 ....................... 4
4.1.1 IPMS.IA5TextBodyPart .............................. 5
4.1.2 IPMS.G3FacsimileBodyPart .......................... 6
4.1.3 IPMS.MessageBodyPart .............................. 7
4.1.4 IPMS.ExternallyDefinedBodyPart .................... 8
4.1.5 Other Body Parts .................................. 11
4.2 Mapping from RFC-822 to X.400 ....................... 12
4.2.1 text/plain ........................................ 14
4.2.2 image/g3fax ....................................... 14
4.2.3 message/rfc822 .................................... 15
4.2.4 MIME/MHS Body Part Equivalance .................... 16
4.2.5 application/x-oid ................................. 17
4.2.6 application/x-mhs ................................. 18
4.2.7 Other Content-Types ............................... 19
5 Appendix A: MIME/MHS Body Part Registrations .......... 20
5.1 note 1: mIMEBodyPart ................................ 20
Miles, Thompson, Rose [Page 21]