view Side-By-Side changes
Date: Tue, 09 Apr 2002 05:09:53 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Mon, 02 Sep 1996 22:21:00 GMT
ETag: "361b75-1614e-322b5dcc"
Accept-Ranges: bytes
Content-Length: 90446
Connection: close
Content-Type: text/plain
draft X.400/MIME body mapping May 96
Network Working Group H. Alvestrand
Request for Comments: 2157 UNINETT
Category: Standards Track January 1998
Mapping between X.400 and RFC-822/MIME Message Bodies
Thu Aug 15 14:51:04 MET DST 1996
Harald Tveit Alvestrand
UNINETT
Harald.T.Alvestrand@uninett.no
Status of this Memo
The name of this draft is draft-ietf-mixer-bodymap-06.txt.
The following text is required for all drafts:
This document is specifies an Internet Draft. Internet Drafts
are working documents of standards track protocol for the
Internet Engineering
Task Force (IETF), its Areas, community, and its Working Groups.
Note that other groups may also distribute working
documents as Internet Drafts.
Internet Drafts are draft documents valid requests discussion and suggestions for a
maximum of six months. Internet Drafts may be
updated, replaced, or obsoleted by other documents at
any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other
than as a "working draft" or "work in progress."
improvements. Please check the I-D abstract listing contained in
each Internet Draft directory refer to learn the current
status of this or any other Internet Draft.
This document describes the translation edition of message body
parts between X.400 and MIME.
Please send comments to the MIXER mailing list:
<ietf-mixer@innosoft.com>
Alvestrand Exp Nov 96 [Page 1]
draft X.400/MIME body mapping May 96
1. Introduction
This document is a companion to [MIXER], which defines the
principles and translation of headers "Internet
Official Protocol Standards" (STD 1) for interworking
between MIME-based RFC-822 mail and X.400 mail.
This document defines how to map body parts of X.400
messages into MIME entities and vice versa, including the
handling of multipart messages standardization state
and forwarded messages.
A table status of contents that should be quite useful for
locating specific sections this protocol. Distribution of this memo is given in the back unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Table of the
document.
1.1. Contents
1 Introduction ........................................... 2
1.1 Glossary
The following terms are defined in this document:
Body ............................................. 3
2 Basic rules for body part
Part of a message that has a unique type. This term
comes conversion ................... 4
2.1 Generating the IPM Body from X.400; MIME .................... 5
2.2 Generating the corresponding term in MIME (RFC
1521) is limited to use in parts of a multipart
message; Body from the term "body" may correspond better.
Content-type
Type information indicating what IPMS.Body .......... 6
2.3 Mapping the content EMA FTBP parameters ...................... 7
2.3.1 Mapping GraphicStrings ............................. 7
2.3.2 Mapping specific parameters ........................ 7
2.3.3 Summary of a
body part actually is. This term comes from MIME; the
corresponding X.400 term FTBP elements generated ................. 10
2.4 Information that is "body part type".
Mapping
(noun): A description lost when mapping ................ 11
3 Encapsulation of how to transform an X.400
body part into a MIME body part, or how to transform
a MIME body part into an X.400 body part.
Equivalence
A set parts ............................ 11
3.1 Encapsulation of two mappings that taken together provide a
lossless conversion between an MIME in X.400 ....................... 12
3.1.1 FTBP encapsulating body part and a
MIME ....................... 12
3.1.2 BP15 encapsulating body part ....................... 13
3.1.3 Encapsulation
The process of wrapping something from one of the
mail systems using IA5 (HARPOON) .................. 15
3.1.4 Content passing using BP14 ......................... 16
3.2 Encapsulating X.400 Body Parts in such a way that it can be carried
inside the other mail system. When encapsulating, it
is not expected that the other mail system can make
Alvestrand Exp Nov 96 [Page 2]
draft X.400/MIME MIME ............... 16
3.3 Encapsulating FTBP body mapping May 96
reasonable sense of parts in MIME ................ 17
4 User control over the body part, but a gateway back
into the first system will always be able choice ................... 18
4.1 Conversion from MIME to convert
the body part without loss back X.400 ........................ 18
4.2 Conversion from X.400 to its original
format.
HARPOON encapsulation
The encapsulating of a MIME body part by putting it
inside an IA5 body with all headers and encoding
intact. First described in RFC 1496 (HARPOON).
Tunneling ........................ 20
5 The equivalence registry ............................... 21
5.1 What happens when information one gateway encapsulates a message
and sends it to another gateway that decapsulates it.
The hope is that this will cause minimal damage to
the message in transit.
DISCUSSION
At many points in this document, the author has found
it useful to include material that explains part of
the reasoning behind the specification. These
sections all start with DISCUSSION: and continue to
the next numbered section heading; they do not
dictate any additional requirements on must give about a gateway.
2. Basic rules for body part conversion
The basic approach mapping
..................................................... 21
5.2 Equivalence summary for translating body parts is described
in section 2.1 known X.400 and 2.2.
Chapter 3 gives details on "encapsulation", which allows
you to be certain that no information is lost even when
unknown types are encountered.
Chapter 6 gives the core mappings for various body parts.
The conformance requirements in chapter 8 describe what
the minimum conformance for a MIXER gateway is with
respect to body part conversion.
DISCUSSION:
At the moment (Sept 1995) both the MIME and the X.400
worlds are in a state of flux with regards
Types ................................................ 22
5.3 MIME to carrying
around stuff that is not text. X.400 Table .................................. 23
Alvestrand Exp Nov 96 Standards Track [Page 3]
draft 1]
RFC 2157 X.400/MIME body mapping May 96
In such a situation, there is little chance Body Mapping January 1998
5.4 X.400 to MIME Table .................................. 23
5.5 Use of defining a
mapping between them that OBJECT IDENTIFIERs and ASN.1 MACROS ........... 24
6 Defined Equivalences ................................... 26
6.1 IA5Text - text/plain ................................. 26
6.2 GeneralText - text/plain (ISO-8859) .................. 27
6.3 BilaterallyDefined - application/octet-stream
...................................................... 29
6.4 FTBP EMA Unknown Attachment -
application/octet-stream ............................. 29
6.5 MessageBodyPart - message/RFC822 ..................... 30
6.6 MessageBodyPart - multipart/* ........................ 31
6.7 Teletex - Text/Plain (Teletex) ....................... 32
7 Body parts where encapsulation is the best recommended .......... 33
7.1 message/external-body ................................ 34
7.2 message/partial ...................................... 35
7.3 multipart/signed ..................................... 35
7.4 multipart/encrypted .................................. 36
8 Conformance requirements ............................... 37
9 Security Considerations ................................ 38
10 Author's Address ...................................... 38
11 Acknowledgements ...................................... 38
References .............................................. 38
APPENDIXES .............................................. 41
Appendix A: Escape code normalization ................... 41
Appendix B: OID Assignments ............................. 44
Appendix C: Registration information for all people, all
of the time.
For this reason, this specification allows
Teletex character set ............................... 46
Appendix D: IANA Registration form for new
mappings ................................................ 48
Full Copyright Statement ................................. 49
1. Introduction
This document is a gateway
considerable latitude in deciding exactly what conversion companion to apply.
The decision taken by the gateway may be based on various
information sources:
(1) If the gateway knows what body parts or content
types [MIXER], which defines the recipient is able to handle, or has
registered a particular set principles
and translation of preferences headers for a
user, interworking between MIME-based RFC-
822 mail and knows X.400 mail.
This document defines how to convert the message
reasonably to those body parts, the gateway may
choose to convert map body parts in the message to
those types only.
(2) If the gateway gets indications (via special
headers or heading-extensions defined for of X.400 messages into
MIME entities and vice versa, including the
purpose) that the sender wanted a particular
representation on the "other side", handling of multipart
messages and the gateway
is able to satisfy the request, it may do so. Such
a mechanism is forwarded messages.
Alvestrand Standards Track [Page 2]
RFC 2157 X.400/MIME Body Mapping January 1998
1.1. Glossary
The following terms are defined in chapter 4 of this
document.
(3) If the gateway gets document:
Body part
Part of a message that might be
appropriate has a unique type. This term comes from
X.400; the corresponding term in MIME (RFC 2046) is limited to send as one out use
in parts of several types,
but where a multipart message; the typing term "body" may correspond
better.
Content-type
Type information does not tell you
which one indicating what the content of a body part
actually is. This term comes from MIME; the corresponding X.400
term is "body part type".
Mapping
(noun): A description of how to use (like transform an X.400 BP14, FTAM "just body part into
a
file", or MIME application/octet-stream), it may
apply heuristics like looking at content body part, or looking
at filenames to figure out how to deal with the
message.
(4) If the gateway knows transform a MIME body part into an
X.400 body part.
Equivalence
A set of two mappings that taken together provide a lossless
conversion between an X.400 body part and a MIME body part
Encapsulation
The process of wrapping something from one of the next hop for mail systems in
such a way that it can be carried inside the
message has limited capabilities (like X.400/84), other mail system.
When encapsulating, it may choose to perform conversions appropriate
for is not expected that medium.
Alvestrand Exp Nov 96 [Page 4]
draft X.400/MIME body mapping May 96
(5) Where no mapping is known by the gateway, it
may choose to drop other mail system
can make reasonable sense of the body part, reject the
message, or encapsulate the body part as de
scribed in chapter 3. The choice may be con
figurable, but a conformant MIXER gateway MUST back
into the first system will always be able to be configured for encapsulation.
In many cases, a message that goes SMTP->X.400->SMTP will
arrive convert the body part
without loss of information.
In some cases, the reverse translation may not be
possible, or two gateways may choose to apply different
translations, based on the criteria above, leading to an
apparently inconsistent service.
In addition, service will vary because some gateways will
have implemented conversions not implemented by other
gateways.
This is believed back to be unavoidable.
2.1. Generating the IPM Body from MIME
When converting the body its original format.
HARPOON encapsulation
The encapsulating of a message from MIME to X.400,
the following steps are taken:
If the header does not contain a 822.MIME-Version field,
then generate body part by putting it inside an IPMS.Body with a single IPMS.BodyPart of
type IPMS.IA5TextBodyPart containing the IA5
body of the RFC
822 message with
IPMS.IA5TextBodyPart.parameters.repertoire set to the
default (IA5).
If 822.MIME-Version is present, the body is analyzed as all headers and encoding intact. First described in RFC
1496 [HARPOON].
Tunneling
What happens when one gateway encapsulates a
MIME message and the body sends it
to another gateway that decapsulates it. The hope is converted according that this
will cause minimal damage to the
mappings configured and implemented message in transit.
DISCUSSION
At many points in this document, the gateway.
2.2. Generating the MIME Body from the IPMS.Body
When converting the body author has found it useful to
include material that explains part of a message from X.400 the reasoning behind the
specification. These sections all start with DISCUSSION: and
continue to MIME, the following steps are taken: next numbered section heading; they do not dictate
any additional requirements on a gateway.
Alvestrand Exp Nov 96 Standards Track [Page 5]
draft 3]
RFC 2157 X.400/MIME body mapping May 96
If there is more than one body part, Body Mapping January 1998
The words MUST, SHOULD and the first MAY, when capitalized, are used as defined
in RFC 2119 [MUST].
2. Basic rules for body part conversion
The basic approach for translating body parts is IA5 described in section
2.1 and starts with the string "RFC-822-Headers:"
as the first line, then the remainder of this body part
shall be appended 2.2.
Chapter 3 gives details on "encapsulation", which allows you to be
certain that no information is lost even when unknown types are
encountered.
Chapter 6 gives the RFC 822 header. This relies upon core mappings for various body parts.
The conformance requirements in chapter 8 describe what the theory that this minimum
conformance for a MIXER gateway is with respect to body part has been generated
according to Appendix B of MIXER. A gateway shall check
conversion.
DISCUSSION:
At the consistency moment both the MIME and syntax the X.400 worlds seem to be in a
stable state of this body part, flux with regards to ensure carrying around stuff that the resulting message is conformant with RFC 822.
If the remaining IPMS.Body consists of
not text. In such a single
IPMS.Bodypart, situation, there are three possibilities.
(1) If it is little chance of type IPMS.IA5Text, and the first line defining a
mapping between them that is "MIME-Version: 1.0", it is assumed to be a
HARPOON-encapsulated body part. The complete body
content is then appended to the headers; the
separating blank line is inside best for all people, all of the message. If an
RFC 822 syntax error is discovered inside
time. For this reason, this specification allows a gateway
considerable latitude in deciding exactly what conversion to apply.
The decision taken by the
message, it gateway may be mapped directly as described
below instead.
(2) based on various information
sources:
(1) If it the gateway knows what body parts or content
types the recipient is able to handle, or has
registered a particular set of type IPMS.IA5Text, then this is mapped
directly preferences for a
user, and no MIME encoding is used.
(3) All other types are mapped according knows how to convert the
mappings configured and implemented in message
reasonably to those body parts, the gateway.
If gateway may
choose to convert body parts in the IPMS.Body contains multiple IPMS.Bodypart fields,
then a MIME message of content type multipart is
generated. to
those types only.
(2) If all of the body parts are messages, then
this is multipart/digest. Otherwise it is
multipart/mixed. The components of gateway gets indications (via special
headers or heading-extensions defined for the multipart are
generated in
purpose) that the same order as in sender wanted a particular
representation on the IPMS.Body.
Each component "other side", and the gateway
is mapped according able to satisfy the mappings
configured and implemented request, it may do so. Such
a mechanism is defined in the gateway; any IA5 body
parts are checked to see if they are HARPOON mappings. chapter 4 of this
document.
Alvestrand Exp Nov 96 Standards Track [Page 6]
draft X.400/MIME body mapping May 96
2.3. 4]
RFC 2157 X.400/MIME Body Mapping January 1998
(3) If the EMA FTBP parameters
DISCUSSION:
EMA has defined gateway gets a profile for use message that might be
appropriate to send as one out of several types,
but where the File Transfer
Body Part (FTBP). [MAWG]
New mappings are expected typing information does not tell you
which one to use this as (like an X.400 BP14, FTAM "just a
file", or MIME application/octet-stream), it may
apply heuristics like looking at content or looking
at filenames to figure out how to deal with the mechanism
message.
(4) If the gateway knows that the next hop for
carrying body parts, and since the
message has limited capabilities (like X.400/84),
it is important may choose to have a
consistent mapping perform conversions appropriate
for the special FTBP parameters, these
are defined here.
The that medium.
(5) Where no mapping of is known by the gateway, it
may choose to drop the body will depend on part, reject the content-type in
MIME and on
message, or encapsulate the application-reference in FTBP, and is not
specified here.
However, body part as
described in chapter 3. The choice may be
configurable, but a conformant MIXER gateway MUST
be able to be configured for encapsulation.
In many cases, we expect a message that the translation goes SMTP->X.400->SMTP will involve simply copying arrive
without loss of information.
In some cases, the octets from one format reverse translation may not be possible, or two
gateways may choose to apply different translations, based on the other; that is, "no conversion".
2.3.1. Mapping GraphicStrings
Some parameters of the EMA Profile are encoded as ASN.1
GraphicStrings, which are troublesome because they can
contain any ISO registered graphic character set.
To map these
criteria above, leading to ASCII for use in mail headers, an apparently inconsistent service.
In addition, service will vary because some gateways will have
implemented conversions not implemented by other gateways.
This is believed to be unavoidable.
2.1. Generating the gateway
may either:
(1) Use IPM Body from MIME
When converting the RFC 1522 encoding mechanism body of a message from MIME to create
appropriate encoded-words for X.400, the headers involved.
Note that in some cases, such as within Content-
Disposition filenames,
following steps are taken:
If the encoded-words must be in
quotes, which is header does not contain a 822.MIME-Version field, then
generate an IPMS.Body with a single IPMS.BodyPart of type
IPMS.IA5TextBodyPart containing the normal usage body of encoded-
words.
(2) Apply the normalization procedure given in Appendix
A RFC 822 message with
IPMS.IA5TextBodyPart.parameters.repertoire set to identify the ASCII characters of default (IA5).
If 822.MIME-Version is present, the string, body is analyzed as a MIME
message and replace all non-ASCII characters with the
question mark (?). body is converted according to the mappings
configured and implemented in the gateway.
Alvestrand Exp Nov 96 Standards Track [Page 7]
draft 5]
RFC 2157 X.400/MIME body mapping May 96
Both procedures are valid for MIXER gateways; Body Mapping January 1998
2.2. Generating the
simplified procedure MIME Body from the IPMS.Body
When converting the body of ignoring escape sequences and bit-
stripping a message from X.400 to MIME, the result is NOT valid.
2.3.2. Mapping specific parameters
The
following parameters steps are mapped in both directions:
Content-ID
The mapping of this element is complex.
The Content-ID taken:
If there is encoded as an IPM.MessageIdentifier more than one body part, and entered into the
FTBP.FileTransferParameters.related-stored-file.
file-identifier.cross-reference.message-reference.
FTBP.FileTransferParameters.related-stored-file.
relationship.descriptive-relationship first body part is set to the IA5
and starts with the string "Internet MIME Body Part".
FTBP.FileTransferParameters.related-stored-file.
file-identifier.cross-reference.application-
crossreference is set to a null OCTET STRING.
The reverse mapping is only performed if "RFC-822-Headers:" as the
FTBP.FileTransferParameters.related-stored-file.
relationship.descriptive-relationship has first line,
then the string
value "Internet MIME Body Part".
Content-Description
The value remainder of this field is mapped body part shall be appended to and from the
first string in
FTBP.FileTransferParameters.environment.user-visible-
string.
Alvestrand Exp Nov 96 [Page 8]
draft X.400/MIME body mapping May 96
Content-Disposition RFC 822
header. This field is defined in [CDISP]. It has multiple
components; relies upon the handling theory that this body part has been
generated according to Appendix B of each component is
given below.
The "disposition" component is ignored on MIME ->
X.400 mapping, MIXER. A gateway shall check
the consistency and syntax of this body part, to ensure that the
resulting message is always "attachment" on X.400 ->
MIME mapping.
NOTE: conformant with RFC 1806 gives only 822.
If the "filename" component.
The other components remaining IPMS.Body consists of a single IPMS.Bodypart, there
are expected three possibilities.
(1) If it is of type IPMS.IA5Text, and the first line
is "MIME-Version: 1.0", it is assumed to be added a
HARPOON-encapsulated body part. The complete body
content is then appended to the
next version of headers; the
separating blank line is inside the message. If an
RFC 1806.
C-D: filename
The filename component of 822 syntax error is discovered inside the C-D header
message, it may be mapped directly as described
below instead.
(2) If it is of type IPMS.IA5Text, then this is mapped to
directly and from FileTransferParameters.file-
attributes.pathname.
The EBNF.disposition-type the default MIME encoding (7bit) is ignored when creating
used, unless very long lines or non-ASCII or
control characters are found in the FTBP pathname, and always set to "attachment"
when creating the Content-Disposition header. For
example:
Content-Disposition: attachment; filename=dodo.doc
or
Content-Disposition: attachment; filename=/etc/passwd
The filename will body part, in
which case Quoted-Printable SHOULD be carried as a single incomplete-
pathname string. No special significance is assumed
for used.
(3) All other types are mapped according to the characters "/"
mappings configured and "\". Note that normal
security precautions MUST be taken implemented in using a
filename on a local file system; this should be
obvious from the second example.
This gateway.
If the IPMS.Body contains multiple IPMS.Bodypart fields, then a MIME
message of content type multipart is done to be conformant with generated. If all of the EMA Profile.
Alvestrand Exp Nov 96 [Page 9]
draft X.400/MIME body mapping May 96
C-D: Creation-date
Mapped to and from FileTransferParameters.file-
attributes.date-and-time-of-creation
For
parts are messages, then this and all other date fields, the RFC-822 date
format is used (822.date-time). Note that the
parameter syntax multipart/digest. Otherwise it is
multipart/mixed. The components of RFC 1806 requires that all dates
be quoted!
C-D: Modification-date
Mapped to and from FileTransferParameters.file-
attributes.date-and-time-of-last-modification
C-D: Read-date
Mapped to and from FileTransferParameters.file-
attributes.date-and-time-of-last-read-access
C-D: Size
Mapped to and from FileTransferParameters.file-
attributes.object-size. If the value is "no-value-
available", multipart are generated in
the same order as in the IPMS.Body.
Each component is NOT generated.
Other RFC-822 headers
Mapped mapped according to extension the mappings configured and
implemented in
FTBP.FileTransferParameters.extensions using the
rfc-822-field HEADING-EXTENSION from [MIXER].
NOTE:
The set of headers that gateway; any IA5 body parts are mapped will depend on checked to see if
they are HARPOON mappings, as described above.
Alvestrand Standards Track [Page 6]
RFC 2157 X.400/MIME Body Mapping January 1998
2.3. Mapping the
placement EMA FTBP parameters
DISCUSSION:
EMA has defined a profile for use of the body part (single body part or
multipart).
When it is File Transfer Body Part
(FTBP). [MAWG]
New mappings are expected to use this as the only mechanism for carrying
body of a message, headers
starting with "content-" SHOULD be put into the FTAM
extension, parts, and all other headers should be put into
Alvestrand Exp Nov 96 [Page 10]
draft X.400/MIME body mapping May 96
the IPMS extension for the message.
When since it is important to have a single bodypart of a multipart, ALL
headers on consistent mapping
for the body part special FTBP parameters, these are included, since there is
nowhere else to put them. Note that only headers that
start with "content-" have defined semantics in this
case.
EMA NOTE here.
The EMA profile, version 1.5, specifies that handling
of extensions is Optional for reception. This means
that some non-MIXER gateways may not implement
handling of this field, and some UAs may not have the
possibility mapping of showing the content of this field to body will depend on the user.
An alternative approach using
FTBP.FileTransferParameters.environment.user-visible-
string was suggested to EMA, content-type in MIME and
on the EMA MAWG
recommended application-reference in its April 1996 conference FTBP, and is not specified here.
However, in many cases, we expect that the
IETF MIXER group should rather choose this approach.
2.3.3. Summary of FTBP elements generated
This is a summary of translation will involve
simply copying the preceding section, and does not
add new information.
The following elements of octets from one format to the FTBP other; that is, "no
conversion".
2.3.1. Mapping GraphicStrings
Some parameters are mapped
or used (the rightmost column gives their status in of the EMA profile; M=Mandatory, O=Optional, R=Recommended for
Origination/Receipt):
FileTransferParameters M/M
Related-Stored-File O/O
file-identifier
cross-reference
application-crossreference NULL
message-reference Content-ID
descriptive-relationship Used Profile are encoded as marker
contents-type Must be unstructured-binary M/M
environment M/M
application-reference Selects mapping M/M
user-visible-string Content-description R/M
Alvestrand Exp Nov 96 [Page 11]
draft X.400/MIME body mapping May 96
file-attributes
pathname C-D: Filename R/M
date-and-time-of-creation C-D: Creation-Date O/O
date-and-time-of-last-modification C-D: Modification-Date R/M
date-and-time-of-last-read-access C-D: Read-Date O/O
object-size C-D: Size R/M
extensions Other headers O/O
All other elements of the FTBP parameters ASN.1
GraphicStrings, which are discarded.
NOTE: There is ongoing work on defining a more complete
mapping between FTBP headers and a set of RFC-822 headers.
A gateway MAY choose to support the larger set once it is
available, but MUST support this limited troublesome because they can contain any
ISO registered graphic character set.
2.4. Information that is lost when mapping
MIME defines fields which add information to MIME
contents. Two of To map these are "Content-ID", and "Content-
Description", which have special rules here, but MIME
allows new fields to be defined at any time.
The possibilities are limited about what one can do with
this information: ASCII for use
in mail headers, the gateway may either:
(1) When using encapsulation, Use the information can be
preserved
(2) When using mapping RFC 2047 [MIME-HDR] encoding mechanism to FTBP,
create appropriate encoded-words for the information can headers
involved. Note that in some cases, such as within
Content-Disposition filenames, the encoded-words
must be
preserved in quotes, which is not the FileTransferParameters.extensions
defined for that purpose.
(3) When mapping to a single-body message, normal usage of
encoded-words.
(2) Apply the
information can be preserved as P22 header
extensions
(4) When mapping normalization procedure given in Appendix
A to other body part types, identify the
information must be discarded.
Alvestrand Exp Nov 96 [Page 12]
draft X.400/MIME body mapping May 96
3. Encapsulation of body parts
Where no mapping is possible, the gateway may choose any ASCII characters of the following alternatives:
- Discard the body part, leaving a "marker" saying what
happened
- Reject the message
- "Encapsulate" string,
and replace all non-ASCII characters with the body part, by wrapping it in a body
part defined
question mark (?).
Both procedures are valid for that purpose in the other mail
system
The choice to be made should be configurable in MIXER gateways; the
gateway, and may depend on both policy and knowledge simplified
procedure of ignoring escape sequences and bit-stripping the recipient's capabilities.
3.1. Encapsulation of MIME in X.400
Four body parts result
is NOT valid.
2.3.2. Mapping specific parameters
The following parameters are defined here to encapsulate MIME body
parts mapped in X.400. both directions:
Content-ID
The BP15 body part mapping of this element is backwards compatible with complex.
Alvestrand Standards Track [Page 7]
RFC 1494. 2157 X.400/MIME Body Mapping January 1998
The FTBP body part Content-ID is compatible with the EMA MAWG
document [MAWG], version 1.5, but has some extensions, in
particular encoded as an IPM.MessageIdentifier and entered
into the one for extra headers.
The imagined scenarios for each body part are:
FTBP For use when sending FTBP.FileTransferParameters.related-stored-file. file-
identifier.cross-reference.message-reference.
FTBP.FileTransferParameters.related-stored-file.
relationship.descriptive-relationship is set to recipients that can handle
generic FTBP, and for tunnelling the string
"Internet MIME Body Part".
FTBP.FileTransferParameters.related-stored-file. file-
identifier.cross-reference.application-crossreference is set to a
null OCTET STRING.
The reverse mapping is only performed if the
FTBP.FileTransferParameters.related-stored-file.
relationship.descriptive-relationship has the string value
"Internet MIME UA
BP15 For use when tunnelling MIME Body Part".
Content-Description
The value of this field is mapped to a MIME UA through an
X.400(88) network, or to UAs that have been written
to RFC 1494
IA5 For use when tunneling MIME to a and from the first string in
FTBP.FileTransferParameters.environment.user-visible-string.
Content-Disposition
This field is defined in [CDISP]. It has multiple components; the
handling of each component is given below.
The "disposition" component is ignored on MIME UA through an -> X.400 network, where some mapping,
and is always "attachment" on X.400 -> MIME mapping.
C-D: filename
The filename component of the links may involve
X.400(84).
BP14 For use C-D header is mapped to and from
FileTransferParameters.file-attributes.pathname.
The EBNF.disposition-type is ignored when creating the recipient may be an X.400(84) UA
with BP14 handling capability, FTBP
pathname, and always set to "attachment" when creating the loss of
information in headers is not regarded as important.
Content-Disposition header. For example:
Content-Disposition: attachment; filename=dodo.doc
or
Content-Disposition: attachment; filename=/etc/passwd
Alvestrand Exp Nov 96 Standards Track [Page 13]
draft 8]
RFC 2157 X.400/MIME body mapping May 96
but the gateway Body Mapping January 1998
The filename will be carried as a single incomplete-pathname
string. No special significance is free to use any method it finds
appropriate assumed for the characters "/"
and "\". Note that normal security precautions MUST be taken in any situation.
FTBP
using a filename on a local file system; this should be obvious
from the second example.
This is expected done to be conformant with the most useful body part in
sending EMA Profile.
C-D: Creation-date
Mapped to X.400(92) systems, while and from FileTransferParameters.file-attributes.date-
and-time-of-creation
For this and all other date fields, the BP14 content
passing RFC-822 date format is primarily useful for sending to X.400(84)
systems.
3.1.1. FTBP encapsulating body part
This body part utilizes
used (822.date-time). Note that the fundamental assumption in MIME parameter syntax of [CDISP]
requires that all message content can dates be legally quoted!
C-D: Modification-date
Mapped to and completely
represented by a single octet stream, from FileTransferParameters.file-attributes.date-
and-time-of-last-modification
C-D: Read-date
Mapped to and from FileTransferParameters.file-attributes.date-
and-time-of-last-read-access
C-D: Size
Mapped to and from FileTransferParameters.file-attributes.object-
size. If the "canonical
format".
The FTBP encapsulating body part value is defined by "no-value-available", the
application-reference id-mime-ftbp-data; all component is NOT
generated.
Other RFC-822 headers are
mapped
Mapped to extension in FTBP.FileTransferParameters.extensions
using the FTBP headers, including putting the
"Content-type:" header inside the FTBP ExtensionsField.
Translation rfc-822-field HEADING-EXTENSION from [MIXER].
NOTE:
The set of headers that are mapped will depend on the MIME placement of
the body part (single body part or multipart).
When it is done by:
- Undoing the content-transfer-encoding
- Setting the "FileTransferData.FTdata.value.octet-
aligned" to the resulting string only body of octets
- Putting a message, headers starting with
"content-" SHOULD be put into the appropriate parameters FTAM extension, and all other
headers should be put into the headers.
Reversing IPMS extension for the translation message.
When it is done by:
- Extracting the a single bodypart of a multipart, ALL headers
- Applying an appropriate content-transfer-encoding to on the body. If
body part are included, since there is nowhere else to put them.
Note that only headers that start with "content-" have defined
semantics in this case.
Alvestrand Standards Track [Page 9]
RFC 2157 X.400/MIME Body Mapping January 1998
EMA NOTE
The EMA profile, version 1.5, specifies that handling of
extensions is Optional for reception. This means that some reason different from non-
MIXER gateways may not implement handling of this field, and some
UAs may not have the content-transfer-encoding: header retrieved from possibility of showing the headers, content of this
field to the old one must be deleted.
This mapping is lossless, and therefore counts as "no
conversion".
Alvestrand Exp Nov 96 [Page 14]
draft X.400/MIME body mapping May 96
3.1.2. BP15 encapsulating body part
This section defines an extended body part, based on body
part 15, which may be used user.
An alternative approach using
FTBP.FileTransferParameters.environment.user-visible-string was
suggested to hold any MIME content.
mime-body-part EXTENDED-BODY-PART-TYPE
PARAMETERS MimeParameters
IDENTIFIED BY id-mime-bp-parameters
DATA OCTET STRING
::= id-mime-bp-data
MimeParameters ::=
SEQUENCE {
content-type IA5String,
content-parameters SEQUENCE OF
SEQUENCE {
parameter IA5String,
parameter-value IA5String
}
other-header-fields RFC822FieldList
}
The OBJECT IDENTIFIERS id-mime-bp-parameter EMA, and id-mime-
bp-data are defined in Appendix B. A MIME content is
mapped onto this body part. The MIME headers of the body
part are mapped as follows:
RFC822FieldList is defined EMA MAWG recommended in Appendix L its April 1996
conference that the IETF MIXER group should rather choose this
approach.
2.3.3. Summary of [MIXER].
Content-Type:
The "type/subtype" string FTBP elements generated
This is mapped to
MimeParameters.content-type.
For each "parameter=value" string create a
MimeParameters.content-parameters element. The
MimeParameters.content-Parameters.parameter field is
set to the parameter and the MimeParameters.content-
parameters.parameter-value field is set to the value.
Quoting is preserved in summary of the parameter-value.
Alvestrand Exp Nov 96 [Page 15]
draft X.400/MIME body mapping May 96
Other
Take all other headers and create
MimeParameters.other-header-fields.
The MIME-version, content-type preceding section, and content-transfer-
encoding fields are NOT copied.
NOTE: does not add new
information.
The set following elements of headers that the FTBP parameters are mapped will depend on the
placement of the body part (single body part or
multipart).
When it is the only body of a message, headers
starting with "content-" SHOULD be put into used (the
rightmost column gives their status in the
other-header-fields, and all other headers should be
put into the IPMS extension EMA profile; M=Mandatory,
O=Optional, R=Recommended for Origination/Receipt):
FileTransferParameters M/M
Related-Stored-File O/O
file-identifier
cross-reference
application-crossreference NULL
message-reference Content-ID
descriptive-relationship Used as marker
contents-type Must be unstructured-binary M/M
environment M/M
application-reference Selects mapping M/M
user-visible-string Content-description R/M
file-attributes
pathname C-D: Filename R/M
date-and-time-of-creation C-D: Creation-Date O/O
date-and-time-of-last-modification C-D: Modification-Date R/M
date-and-time-of-last-read-access C-D: Read-Date O/O
object-size C-D: Size R/M
extensions Other headers O/O
All other elements of the message.
When it FTBP parameters are discarded.
Alvestrand Standards Track [Page 10]
RFC 2157 X.400/MIME Body Mapping January 1998
NOTE: There is ongoing work on defining a single bodypart of a multipart, ALL more complete
mapping between FTBP headers on and a set of RFC-822 headers.
A gateway MAY choose to support the body part are included, since there larger set once it is
nowhere else to put them. Note that only headers that
start with "content-" have defined semantics in
available, but MUST support this
case.
The body limited set.
2.4. Information that is mapped as follows:
Convert the lost when mapping
MIME body part into its canonical form, as
specified in Appendix H defines fields which add information to MIME contents. Two of
these are "Content-ID", and "Content-Description", which have special
rules here, but MIME [MIME]. This canonical
form is used allows new fields to generate the mime-body-part.data octet
string.
The Parameter mapping may be used independently of defined at any time.
The possibilities are limited about what one can do with this
information:
(1) When using encapsulation, the
body part information can be
preserved
(2) When using mapping (e.g., in order to use a different
encoding for a mapped MIME body part).
This body part contains all of FTBP, the MIME information, and
so information can be mapped back to MIME without loss of information.
The OID id-mime-bp-data is added to the Encoded
Information Types of
preserved in the envelope.
This body part is completely compatible with RFC 1494. FileTransferParameters.extensions
defined for that purpose.
(3) When converting back mapping to a MIME single-body message, the
information can be preserved as P22 header
extensions
(4) When mapping to other body part, part types, the gateway is
responsible for:
Alvestrand Exp Nov 96 [Page 16]
draft X.400/MIME
information must be discarded.
3. Encapsulation of body parts
Where no mapping May 96
(1) Selecting an appropriate content-transfer-encoding,
and deleting any content-transfer-encoding header
from the other-header-fields
(2) Adding quotes to any parameters that need them (but
not adding quotes to parameters that are already
quoted)
(3) Removing any content-type field that is left in possible, the
RFC822FieldList gateway may choose any of the message that is redundant or
conflicting with
following alternatives:
- Discard the one from body part, leaving a "marker" saying what
happened
- Reject the mime-body-part
(4) Make sure that on multipart messages, message
- "Encapsulate" the boundary
string actually used is reflected body part, by wrapping it in a body
part defined for that purpose in the boundary=
parameter of other mail
system
The choice to be made should be configurable in the content-type header, gateway, and does not
occur within the body may
depend on both policy and knowledge of the message.
3.1.3. Encapsulation using IA5 (HARPOON)
This approach is the one taken in recipient's capabilities.
Alvestrand Standards Track [Page 11]
RFC 1496 - HARPOON - for
tunneling any 2157 X.400/MIME Body Mapping January 1998
3.1. Encapsulation of MIME in X.400
Four body part through X.400/84 networks. It
has proven rather unhelpful for bringing information parts are defined here to
X.400 users, but preserves all the information of a encapsulate MIME body part.
The following IA5Text parts in
X.400.
This externally-defined body part is made:
- Content = IA5String
- First bytes of content: (the description is in US
ASCII, backwards compatible with C escape sequences used to represent
control characters):
MIME-version: <version>\r\n
Content-type: <the proper MIME content type>\r\n
Content-transfer-encoding: <7bit, quoted-printable or base64>\r\n
<Possibly other Content headings here, terminated by\r\n>
\r\n
<Here follows the bytes of the content, encoded
in the proper encoding>
Alvestrand Exp Nov 96 [Page 17]
draft X.400/MIME RFC
1494. The FTBP body mapping May 96
All implementations MUST place part is compatible with the MIME-version: header
first EMA MAWG document
[MAWG], version 1.5, but has some extensions, in particular the one
for extra headers.
The imagined scenarios for each body part. Headers part are:
FTBP For use when sending to recipients that are placed by [MIXER]
into other parts can handle
generic FTBP, and for tunnelling MIME to a MIME UA
BP15 For use when tunnelling MIME to a MIME UA through an
X.400(88) network, or to UAs that have been written
to RFC 1494
IA5 For use when tunneling MIME to a MIME UA through an
X.400 network, where some of the message MUST NOT be placed in links may involve
X.400(84).
BP14 For use when the
MIME body part.
3.1.4. Content passing using recipient may be an X.400(84) UA
with BP14
This is described handling capability, and the loss of
information in this section because it headers is at the
same conceptual level not regarded as encapsulation. It important.
but the gateway is a lossy
transformation; free to use any method it finds appropriate in any
situation.
FTBP is impossible expected to reconstruct the MIME
type information from it.
Nevertheless, there is a demand for such functionality.
This "encapsulation" simply strips off all headers, undoes be the content-transfer-encoding, and creates a
BilaterallyDefined most useful body part (BP14) from in sending to
X.400(92) systems, while the resulting
octet stream.
No reverse translation is defined; when a BP14 arrives at
a MIXER gateway, it will be turned into an
application/octet-stream according to chap. 6.3
3.2. Encapsulating X.400 Body Parts in MIME
This section specifies a generic mechanism content passing is primarily useful
for sending to map X.400 X.400(84) systems.
3.1.1. FTBP encapsulating body parts to a MIME content. part
This allows for the body part to be tunneled through MIME. It may also utilizes the fundamental assumption in MIME that all
message content can be used
directly legally and completely represented by an appropriately configured MIME UA.
This content-type is defined to carry any X.400 extended
body part. a single
octet stream, the "canonical format".
The mapping of all standard X.400 FTBP encapsulating body parts
is defined in RFC1494bis. The content-type field is
"application/x400-bp". The parameter part is defined by the
EBNF:
mime-parameter = "bp-type=" object-identifier
The EBNF.object-identifier is set application-
reference id-mime-ftbp-data; all headers are mapped to the OBJECT IDENTIFIER FTBP
headers, including putting the "Content-type:" header inside the FTBP
ExtensionsField.
Translation from IPMS.body.externally-defined.data.direct-reference.
For example, a Videotex the MIME body part will have is done by:
- Undoing the content-transfer-encoding
Alvestrand Exp Nov 96 Standards Track [Page 18]
draft 12]
RFC 2157 X.400/MIME body mapping May 96
Content-type=application/x400-bp; bp-type=2.6.1.4.5
The body contains the raw ASN.1 IPM body octet stream,
that is, Body Mapping January 1998
- Setting the BER encoding "FileTransferData.FTdata.value.octet-
aligned" to the resulting string of octets
- Putting the IPM.Body.BodyPart,
including appropriate parameters into the initial tag octet. The content may use a
content-transfer-encoding of either base64 or quoted-
printable when carried in 7-bit MIME. It is recommended
to use headers.
Reversing the one which gives translation is done by:
- Extracting the more compact encoding of headers
- Applying an appropriate content-transfer-encoding to
the data. body. If this cannot be determined, Base64 is
recommended. No attempt is made to turn for some reason different from
the parameters of
Extended Body Parts into MIME parameters, content-transfer-encoding: header retrieved from
the headers, the old one must be deleted.
This mapping is lossless, and therefore counts as "no conversion".
Note that this cannot
be done in a general manner.
Standard X.400 body parts may mapping does not be encoded directly by
this mechanism, but may be encoded indirectly by work with multipart types; the
multipart must first
translating be mapped to the extended representation.
NOTE: RFC 1494 defined a bp-type=<integer> for encoding
standard X.400 body parts. If such ForwardedIPMessage.
3.1.2. BP15 encapsulating body parts are
encountered, RFC 1494 part
This section 6.1 should be consulted.
3.3. Encapsulating FTBP defines an extended body parts in part, based on body part 15,
which may be used to hold any MIME content.
mime-body-part EXTENDED-BODY-PART-TYPE
PARAMETERS MimeParameters
IDENTIFIED BY id-mime-bp-parameters
DATA OCTET STRING
::= id-mime-bp-data
MimeParameters ::=
SEQUENCE {
content-type IA5String,
content-parameters SEQUENCE OF
SEQUENCE {
parameter IA5String
parameter-value IA5String
}
other-header-fields RFC822FieldList
}
The File Transfer Body Part is believed to be important OBJECT IDENTIFIERS id-mime-bp-parameter and id-mime-bp-data are
defined in Appendix B. A MIME content is mapped onto this body part.
The MIME headers of the future as "the" means of carrying well-identified data
in X.400 networks.
They also share the property (at lest when limited to the
EMA MAWG functional profile) of having a well-defined data body part that is always representable are mapped as a sequence of bytes.
This conversion will have to fail, and the x400-bp
encapsulation used instead, if:
- FileTransferData has more than one element
- Contents-type follows:
RFC822FieldList is not unstructured-binary
- Parameters that are not mappable, but important, are
present (like Compression, which EMA doesn't
recommend).
Otherwise, it can be encapsulated defined in MIME by: Appendix L of [MIXER].
Alvestrand Exp Nov 96 Standards Track [Page 19]
draft 13]
RFC 2157 X.400/MIME body mapping May 96
- Creating the "content-type" value by forming the Body Mapping January 1998
Content-Type:
The "type/subtype" string "application/x-ftbp." is mapped to
MimeParameters.content-type.
For each "parameter=value" string create a
MimeParameters.content-parameters element. The
MimeParameters.content-Parameters.parameter field is
set to the parameter and appending the
numbers of MimeParameters.content-
parameters.parameter-value field is set to the OID
- Mapping value.
Quoting is preserved in the parameter-value.
Other
Take all other parameters according to the
standard FTBP parameter mapping
- Applying an appropriate content-transfer-encoding
DISCUSSION: headers and create
MimeParameters.other-header-fields.
The choice of the somewhat strange, MIME-version, content-type and by necessity
unregistered, MIME type "application/x-ftbp.n.n.n.n" is
because for any concrete example content-transfer-
encoding fields are NOT copied.
NOTE:
The set of this usage, it headers that are mapped will be
easy to configure any MIME reader to take advantage of depend on the
identification. If
placement of the MIME type registration rules are
ever changed to allow body part (single body part or
multipart).
When it is the registration only body of a namespace,
rather than just of names, the "x-" can message, headers
starting with "content-" SHOULD be deleted, and put into the types can
other-header-fields, and all other headers should be "application/ftbp.n.n.n.n".
4. User control over
put into the gateway choice
In some cases, IPMS extension for the gateway may make an inappropriate
choice when deciding what to do about message.
When it is a particular body
part.
To allow an escape clause, this chapter defines single bodypart of a way in
which the user can signal the gateway what action it finds
most appropriate.
The multipart, ALL
headers given here override any "conversion
prohibited" and "conversion with loss prohibited" on the
message.
It body part are included, since there is still the gateway's responsibility
nowhere else to put them. Note that only headers that
start with "content-" have defined semantics in this
case.
The body is mapped as follows:
Convert the
generated messages conform MIME body part into its canonical form, as specified in
Appendix H of MIME [MIME]. This canonical form is used to generate
the destination domain's
syntax rules.
DISCUSSION: mime-body-part.data octet string.
The intent Parameter mapping may be used independently of this mechanism is to allow the sender body part
mapping (e.g., in order to
efficiently get use a message through to different encoding for a single recipient
Alvestrand Exp Nov 96 [Page 20]
draft X.400/MIME mapped MIME
body part).
This body mapping May 96
when the sender has information about the recipient that
the gateway does not have.
It is not a part contains all of the minimum functionality listed in
chapter 8; a gateway does not have MIME information, and so can be
mapped back to implement this spec MIME without loss of information.
The OID id-mime-bp-data is added to be MIXER conformant, but if implemented, it should be
done like this.
The additional complexity, both in user interface and in
protocol, of making this field selectable per recipient
was not thought worthwhile;
4.1. Conversion from MIME to X.400
The header field described below specifies explicit MIXER
conversion. Comments are allowed within the field
according to Encoded Information Types of
the usual envelope.
Alvestrand Standards Track [Page 14]
RFC 822 convention.
If "x400-object-id" is omitted, "tunnel" is assumed.
mime-to-x400 = "Wanted-X400-Conversion" ":"
[ mime-from ] [ x400-object-id ]
"in" x400-encoding
x400-object-id = "to" ( object-identifier-2 / "tunnel" )
x400-encoding = "bp14" / "bp15" / "ftbp" / "ia5"
mime-from = "from" mime-type
mime-type = word
There 2157 X.400/MIME Body Mapping January 1998
This body part is no way completely compatible with RFC 1494.
When converting back to ask for a different conversion based on MIME parameters or bodypart content.
Examples:
Wanted-X400-Conversion: from application/msword
to 1.2.840.113556.4.2 (Microsoft defined ms-word)
in ftbp
This uses body part, the MAWG definitions, and leads to gateway is responsible
for:
(1) Selecting an FTBP encoding.
Wanted-X400-Conversion: appropriate content-transfer-encoding,
and deleting any content-transfer-encoding header
from application/msword the other-header-fields
(2) Adding quotes to tunnel in bp14
Alvestrand Exp Nov 96 [Page 21]
draft X.400/MIME body mapping May 96
This leads any parameters that need them (but
not adding quotes to a Body Part 14 encoding for all body parts of type
application/msword.
Wanted-X400-Conversion: in bp14
This requests parameters that this specific body part be encoded in Body Part 14.
This are already
quoted)
(3) Removing any content-type field may be used that is left in two places:
(1) In the heading
RFC822FieldList of an unstructured MIME body part.
In this case the EBNF.mime-from message that is omitted, and the
requested conversion applies to redundant or
conflicting with the body part.
(2) In a multipart. In this case, one from the body part type to
which mime-body-part
(4) Make sure that on multipart messages, the conversion applies boundary
string actually used is defined by
EBNF.mime-from, reflected in the boundary-
parameter of the content-type header, and does not
occur within the conversion applies to all body parts of this MIME type contained in the
multipart, including those contained message.
3.1.3. Encapsulation using IA5 (HARPOON)
This approach is the one taken in nested
messages and multiparts. If a contained RFC 1496 - HARPOON - for tunneling
any MIME body part through X.400/84 networks. It has its own heading, this takes precedence. Note
that proven rather
unhelpful for bringing information to X.400 users, but preserves all
the "from" parameter is mandatory when used in information of a multipart. MIME body part.
The EBNF.x400-object-id shall be present when "bp15" or
"ftbp" encoding following IA5Text body part is selected.
The value "tunnel" implies encapsulation as defined in
Chapter 3.
The "object identifier" used below is: made:
- For BP 15, it Content = IA5String
- First bytes of content: (the description is in US
ASCII, with C escape sequences used to represent
control characters):
MIME-version: <version>\r\n
Content-type: <the proper MIME content type>\r\n
Content-transfer-encoding: <7bit, quoted-printable or base64>\r\n
<Possibly other Content headings here, terminated by\r\n>
\r\n
<Here follows the value bytes of the EXTENDED-BODY-PART-
TYPE macro that defines the body part, which is found content, encoded
in ExternallyDefinedBodyPart.data.direct-reference.
- For FTBP, it is the value of proper encoding>
All implementations MUST place the MIME-version: header first in the
Environment.application-reference.
Alvestrand Exp Nov 96 [Page 22]
draft X.400/MIME
body mapping May 96
4.2. Conversion from X.400 to MIME
The IPM heading defined here shall part. Headers that are placed by [MIXER] into other parts of the
message MUST NOT be present placed in the
heading of a message. It defines the mapping for all MIME body
parts part.
Alvestrand Standards Track [Page 15]
RFC 2157 X.400/MIME Body Mapping January 1998
This encapsulation may also be applied to subtypes of the specified types, including those in nested
messages.
wanted-MIME-conversion HEADING-EXTENSION
VALUE WantedMIMEConversions
::= id-wanted-MIME-conversions
WantedMIMEConversions ::= SEQUENCE OF X400toMIMEConversion
X400toMIMEConversion ::= SEQUENCE {
x400-type X400Type,
mime-type MIMEType }
X400Type ::= CHOICE {
standard [0] INTEGER, -- standard multipart,
creating a single IA5 body part
extended [1] OBJECT IDENTIFIER, -- BP 15
ftbp [2] OBJECT IDENTIFIER} -- FTBP application-reference
MIMEType ::= SEQUENCE {
type IA5String, -- type (e.g., application/ms-word)
encoding [1] IA5String OPTIONAl -- e.g. quoted-printable
parameters [2] IA5String OPTIONAL } -- that contains a single multipart/*,
which in turn may contain multiple MIME Parameters
The heading extension includes all requested conversions,
with explicit information as to how each body part type parts.
3.1.4. Content passing using BP14
This is
encoded described in MIME.
FTBP this section because it is identified as a separate body part type, at the same
conceptual level as there
will be encapsulation. It is a need for different encodings, dependent on what lossy transformation; it
is being carried.
Encapsulation impossible to reconstruct the MIME type information from it.
Nevertheless, there is requested by asking a demand for
"application/x400-bp" or "application/ftbp" as such functionality.
This "encapsulation" simply strips off all headers, undoes the
destination type.
For FTAM
content-transfer-encoding, and creates a BilaterallyDefined body parts, the parameters will survive part
(BP14) from the
gatewaying process. For other body parts, there are three
alternatives:
Alvestrand Exp Nov 96 [Page 23]
draft X.400/MIME body mapping May 96
(1) The gateway knows resulting octet stream.
No reverse translation is defined; when a defined mapping for this
particular body part and destination type. It BP14 arrives at a MIXER
gateway, it will be used, and parameters mapped accordingly.
(2) The gateway knows how to extract turned into an OCTET STRING
from the application/octet-stream according
to chap. 6.3
3.2. Encapsulating X.400 Body Parts in MIME
This section specifies a generic mechanism to map X.400 body part, and the destination is parts to
a simple MIME body part. All information outside content. This allows for the OCTET
STRING is lost. (This body part to be tunneled through
MIME. It may also be the case for a BP14
that should end up in used directly by an application/xyzzy, for
instance).
(3) The gateway knows of no relevant mapping, and does
not know how appropriately configured
MIME UA.
This content-type is defined to simplify the carry any X.400 extended body part.
The
gateway will then proceed as if the mapping control
field had not been present.
5. of all standard X.400 body parts is defined in this
document. The equivalence registry
5.1. What information one must give about a mapping content-type field is "application/x400-bp". The following information MUST be supplied when describing
an equivalence or
parameter is defined by the EBNF:
mime-parameter = "bp-type=" ( object-identifier / 1*DIGIT=
If the body is a mapping:
MIME type name (which must be preregistered)
X.400 basic body part (often BP15 or FTAM Body Part)
If BP15 part, the bp-type parameter is used, set to the following information must be given:
(1) Object Identifier for X.400 BP15 Data
(2) Object Identifier for X.400 BP15 Parameters
(3) X.400 ASN.1 Syntax (must be an EXTENDED-BODY-PART-
TYPE macro)
number of the body part's context-specific tag, that is, the tag of
the IPMS.Body.BodyPart component.
If FTBP the body is used, an Extended Body Part, the following information must be given:
(1) Object Identifier for EBNF.object-dentifier is
set to the FTAM
Environment.application-reference OBJECT IDENTIFIER from IPMS.body.externally-
defined.data.direct-reference.
For example, a basic VideotexBodyPart will have
Content-type=application/x400-bp; bp-type=6
whilst a Extended Videotex body part will have
Alvestrand Exp Nov 96 Standards Track [Page 24]
draft 16]
RFC 2157 X.400/MIME Body Mapping January 1998
Content-type=application/x400-bp; bp-type=2.6.1.4.5
The body mapping May 96
(2) Object Identifier for contains the FTAM Contents-type, if
unstructured-binary is not used
(3) Any other special considerations
In all cases, raw ASN.1 IPM body octet stream, that is, the following must be given:
Conversion algorithms. The expected effect
BER encoding of "Conversion
prohibited" and "Conversion with loss prohibited" should
be noted.
The conversion must be specified with enough detail to
permit independent implementation; literature references
are acceptable.
An equivalence can be registered with IANA using the form
at IPM.Body.BodyPart, including the end of this document. initial tag
octet. The purpose content may use a content-transfer-encoding of the
registration either
base64 or quoted-printable when carried in 7-bit MIME. It is
recommended to achieve a greater uniformity among
gateways implementing use the same translation; there is no
requirement that a gateway must support all one which gives the more compact encoding of
the
translations that are registered with IANA. Specific
conformance requirements for MIXER are given at data. If this cannot be determined, Base64 is recommended. No
attempt is made to turn the end parameters of
this document.
5.2. Equivalence summary for known X.400 and Extended Body Parts into
MIME Types
This section itemizes the equivalences for all currently
known MIME content-types and X.400 body parts. parameters, as this cannot be done in a general manner.
For each MIME content-type/X.400 extended body part pair, the
equivalence table contains an entry with parts, the following
sections:
X.400
3.3. Encapsulating FTBP body parts in MIME
The File Transfer Body Part
This section identifies is believed to be important in the future
as "the" means of carrying well-identified data in X.400 Body Part governed networks.
They also share the property (at lest when limited to the EMA MAWG
functional profile) of having a well-defined data part that is always
representable as a sequence of bytes.
This conversion will have to fail, and the x400-bp encapsulation used
instead, if:
- FileTransferData has more than one element
- Contents-type is not unstructured-binary
- Parameters that are not mappable, but important, are
present (like Compression, which EMA doesn't
recommend).
Otherwise, it can be encapsulated in MIME by:
- Creating the "content-type" value by this Table entry. It includes any OBJECT
IDENTIFIERs or forming the
string "application/x-ftbp." and appending the
numbers of the OID found in
FileTransferParameters.environment.application-
reference.registered-identifier
- Mapping all other parameters necessary according to uniquely
identify the Body Part.
MIME Content-Type
This section identifies
standard FTBP parameter mapping
- Applying an appropriate content-transfer-encoding to
the MIME content-type data contained in FileTransferData.value.encoding
Alvestrand Exp Nov 96 Standards Track [Page 25]
draft 17]
RFC 2157 X.400/MIME body mapping May 96
governed by this Table entry. Body Mapping January 1998
DISCUSSION:
The MIME content-type
named here must be registered with choice of the IANA.
Section/document reference
Reference to section somewhat strange, and by necessity unregistered,
MIME type "application/x-ftbp.n.n.n.n" is because for any concrete
example of this document, or usage, it will be easy to configure any MIME reader
to take advantage of the
other document that describes this mapping.
The initial Equivalence Table entries in this document identification. If the MIME type
registration rules are
described using this convention.
Further registrations ever changed to allow the registration of equivalences should a
namespace, rather than just of names, the "x-" can be submitted
to deleted, and
the IANA after types can be "application/ftbp.n.n.n.n".
4. User control over the gateway choice
In some cases, the gateway may make an inappropriate choice when
deciding what to do about a public review, using particular body part.
To allow an escape clause, this chapter defines a way in which the example form
user can signal the gateway what action it finds most appropriate.
The headers given at here override any "conversion prohibited" and
"conversion with loss prohibited" on the end message.
It is still the gateway's responsibility that the generated messages
conform to the destination domain's syntax rules.
DISCUSSION:
The intent of this document.
5.3. MIME mechanism is to X.400 Table allow the sender to efficiently
get a message through to a single recipient when the sender has
information about the recipient that the gateway does not have.
It is not a part of the minimum functionality listed in chapter 8; a
gateway does not have to implement this spec to be MIXER conformant,
but if implemented, it should be done like this.
The additional complexity, both in user interface and in protocol, of
making this field selectable per recipient was not thought
worthwhile;
4.1. Conversion from MIME content-type to X.400 Body Part Section
The header field described below specifies explicit MIXER conversion.
Comments are allowed within the field according to the usual RFC 822
convention.
If "x400-object-id" is omitted, "tunnel" is assumed.
mime-to-x400 = "Wanted-X400-Conversion" ":"
[ mime-from ] [ x400-object-id ]
Alvestrand Standards Track [Page 18]
RFC 2157 X.400/MIME Body Mapping January 1998
"in" x400-encoding
x400-object-id = "to" ( object-identifier-2 / "tunnel" )
x400-encoding = "bp14" / "bp15" / "ftbp" / "ia5"
mime-from = "from" mime-type
mime-type = word
There is no way to ask for a different conversion based on MIME
parameters or bodypart content.
Examples:
Wanted-X400-Conversion: from application/msword
to 1.2.840.113556.4.2 (Microsoft defined ms-word)
in ftbp
This uses the MAWG definitions, and leads to an FTBP encoding.
Wanted-X400-Conversion: from application/msword
to tunnel in bp14
This leads to a Body Part 14 encoding for all body parts of type
application/msword.
Wanted-X400-Conversion: in bp14
This requests that this specific body part be encoded in Body Part
14.
This field may be used in two places:
(1) In the heading of an unstructured MIME body part.
In this case the EBNF.mime-from is omitted, and the
requested conversion applies to the body part.
(2) In a multipart. In this case, the body part type to
which the conversion applies is defined by
EBNF.mime-from, and the conversion applies to all
body parts of this MIME type contained in the
multipart, including those contained in nested
messages and multiparts. If a contained body part
has its own heading, this takes precedence. Note
that the "from" parameter is mandatory when used in
a multipart.
The EBNF.x400-object-id shall be present when "bp15" or
"ftbp" encoding is selected.
Alvestrand Standards Track [Page 19]
RFC 2157 X.400/MIME Body Mapping January 1998
The value "tunnel" implies encapsulation as defined in
Chapter 3.
The "object identifier" used below is:
- For BP 15, it is the value of the EXTENDED-BODY-PART-
TYPE macro that defines the body part, which is found
in ExternallyDefinedBodyPart.data.direct-reference.
- For FTBP, it is the value of the
Environment.application-reference.
4.2. Conversion from X.400 to MIME
The IPM heading defined here shall be present in the heading of a
message. It defines the mapping for all body parts of the specified
types, including those in nested messages.
wanted-MIME-conversion HEADING-EXTENSION
VALUE WantedMIMEConversions
::= id-wanted-MIME-conversions
WantedMIMEConversions ::= SEQUENCE OF X400toMIMEConversion
X400toMIMEConversion ::= SEQUENCE {
x400-type X400Type,
mime-type MIMEType }
X400Type ::= CHOICE {
standard [0] INTEGER, -- standard body part
extended [1] OBJECT IDENTIFIER, -- BP 15
ftbp [2] OBJECT IDENTIFIER} -- FTBP
-- application-reference
MIMEType ::= SEQUENCE {
type IA5String, -- type (e.g., application/ms-word)
encoding [1] IA5String OPTIONAl -- e.g. quoted-printable
parameters [2] IA5String OPTIONAL } -- MIME Parameters
The heading extension includes all requested conversions, with
explicit information as to how each body part type is encoded in
MIME.
FTBP is identified as a separate body part type, as there will be a
need for different encodings, dependent on what is being carried.
Alvestrand Standards Track [Page 20]
RFC 2157 X.400/MIME Body Mapping January 1998
Encapsulation is requested by asking for "application/x400-bp" or
"application/ftbp" as the destination type.
For FTAM body parts, the parameters will survive the gatewaying
process. For other body parts, there are three alternatives:
(1) The gateway knows a defined mapping for this
particular body part and destination type. It will be used,
and parameters mapped accordingly.
(2) The gateway knows how to extract an OCTET STRING
from the body part, and the destination is a simple MIME body
part. All information outside the OCTET STRING is lost. (This
may be the case for a BP14 that should end up in an
application/xyzzy, for instance).
(3) The gateway knows of no relevant mapping, and does
not know how to simplify the X.400 body part. The gateway
will then proceed as if the mapping control field had not
been present.
5. The equivalence registry
5.1. What information one must give about a mapping
The following information MUST be supplied when describing an
equivalence or a mapping:
MIME type name (which must be preregistered)
X.400 body part (often BP15 or FTAM Body Part)
If BP15 is used, the following information must be given:
(1) Object Identifier for X.400 BP15 Data
(2) Object Identifier for X.400 BP15 Parameters
(3) X.400 ASN.1 Syntax (must be an EXTENDED-BODY-PART-
TYPE macro)
If FTBP is used, the following information must be given:
<1) Object Identifier for the FTAM Environment.application-
reference
<2) Object Identifier for the FTAM Contents-type, if
unstructured-binary is not used
Alvestrand Standards Track [Page 21]
RFC 2157 X.400/MIME Body Mapping January 1998
(3) Any other special considerations
In all cases, the following must be given:
Conversion algorithms. The expected effect of "Conversion prohibited"
and "Conversion with loss prohibited" should be noted.
The conversion must be specified with enough detail to permit
independent implementation; literature references are acceptable.
An equivalence can be registered with IANA using the form at the end
of this document. The purpose of the registration is to achieve a
greater uniformity among gateways implementing the same translation;
there is no requirement that a gateway must support all of the
translations that are registered with IANA, and there is no
requirement that all conversions supported by a gateway are
registered with IANA. Specific conformance requirements for MIXER are
given at the end of this document.
Anyone can register an equivalence with IANA, and may update the
registered equivalence at any time, or reassign the right to update
the registry entry at any time. However, the IESG has the power to
"lock" a registration, so that changing it requires IESG approval,
and to update such a "locked" registration. All registered
equivalences defined in standards-track documents (including this
one) are locked.
5.2. Equivalence summary for known X.400 and MIME Types
This section itemizes the equivalences for all currently known MIME
content-types and X.400 body parts.
For each MIME content-type/X.400 body part pair, the equivalence
table contains an entry with the following sections:
X.400 Body Part
This section identifies the X.400 Body Part governed by this
Table entry. It includes any OBJECT IDENTIFIERs or other
parameters necessary to uniquely identify the Body Part.
MIME Content-Type
This section identifies the MIME content-type governed by this
Table entry. The MIME content-type named here must be
registered with the IANA.
Section/document reference
Reference to section of this document, or to the other document
that describes this mapping.
Alvestrand Standards Track [Page 22]
RFC 2157 X.400/MIME Body Mapping January 1998
The initial Equivalence Table entries in this document are described
using this convention.
Further registrations of equivalences should be submitted to the IANA
after a public review, using the example form given at the end of
this document.
5.3. MIME to X.400 Table
MIME content-type X.400 Body Part Section
----------------- ------------------ -------
text/plain
charset=us-ascii ia5-text 6.1
charset=ISO-8859-x EBP - GeneralText 6.2
text/richtext no mapping defined Encap
application/oda EBP - ODA [ODA]
application/octet-stream bilaterally-defined or 6.3
FTBP unknown attachment 6.4
application/postscript EBP - mime-postscript-body [POSTSCRIPT]
image/g3fax g3-facsimile [IMAGES]
image/jpeg EBP - mime-jpeg-body [IMAGES]
image/gif EBP - mime-gif-body [IMAGES]
audio/basic no mapping defined Encap
video/mpeg no mapping defined Encap
message/RFC822 ForwardedIPMessage 6.5
multipart/* ForwardedIPMessage 6.6
multipart/signed HARPOON encap 7.3
multipart/encrypted HARPOON encap 7.4
Abbreviation: EBP - Extended Body Part
Alvestrand Exp Nov 96 [Page 26]
draft X.400/MIME body mapping May 96
5.4. X.400 to MIME Table
Basic Body Parts
X.400 Basic Body Part MIME content-type Section
--------------------- -------------------- -------
ia5-text text/plain;charset=us-ascii 6.1
voice No Mapping Defined Encap
g3-facsimile image/g3fax [IMAGES]
g4-class1 no mapping defined Encap
teletex text/plain;charset=teletex 6.7
videotex no mapping defined Encap
encrypted no mapping defined Encap
bilaterally-defined application/octet-stream 6.3
nationally-defined no mapping defined Encap
externally-defined See Extended Body Parts below
Alvestrand Standards Track [Page 23]
RFC 2157 X.400/MIME Body Mapping January 1998
ForwardedIPMessage message/RFC822 or multipart 6.5,6.6
X.400 Extended Body Part MIME content-type Section
------------------------- -------------------- -------
GeneralText text/plain;charset=ISO-8859-x 6.2
ODA application/oda [ODA]
mime-postscript-body application/postscript [POSTSCRIPT]
mime-jpeg-body image/jpeg [IMAGES]
mime-gif-body image/gif [IMAGES]
FTAM various 2.3,6.4
FTAM application ID MIME content type Section
------------------- ----------------- -------
ema-unknown-attachment application/octet-stream 6.4
Alvestrand Exp Nov 96 [Page 27]
draft X.400/MIME body mapping May 96
5.5. Use of OBJECT IDENTIFIERs and ASN.1 MACROS
When one wants to define new BP15 body parts for use with
equivalences, it is important to know that X.420 dictates that
Extended Body Parts shall:
(1) use OBJECT IDENTIFIERs (OIDs) to uniquely identify
the contents, and
(2) be defined by using the ASN.1 Macro:
EXTENDED-BODY-PART-TYPE MACRO::=
BEGIN
TYPE NOTATION ::= Parameters Data
VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
Parameters ::= "PARAMETERS" type "IDENTIFIED"
"BY" value(OBJECT IDENTIFIER)
| empty;
Data ::= "DATA" type
END
To meet these requirements, this document uses the OID
mixer
defined in [MIXER], as the root OID for X.400 Extended Body Parts
defined for MIME interworking.
Each Extended Body Part contains Data and optional Parameters, each
being named by an OID. To this end, two OID subtrees are defined
under mixer-bodies, one for Data, and the other for Parameters:
Alvestrand Standards Track [Page 24]
RFC 2157 X.400/MIME Body Mapping January 1998
mixer-bp-data OBJECT IDENTIFIER ::=
{ mixer 1 }
mixer-bp-parameter OBJECT IDENTIFIER ::=
{ mixer 2 }
All definitions of extended X.400 body parts submitted to the IANA
for registration with a mapping must use the Extended Body Part Type
macro for the definition. See [IMAGES] for an example.
Alvestrand Exp Nov 96 [Page 28]
draft X.400/MIME body mapping May 96
Lastly, the IANA will use the mixer-bp-data and mixer-bp-
parameter mixer-bp-parameter
OIDs as root OIDs for any new MIME content-
type/subtypes content-type/subtypes that aren't
otherwise registered in the Equivalence Table.
NOTE: The ASN.1 for an ExternallyDefinedBodyPart is
ExternallyDefinedBodyPart ::= SEQUENCE {
parameters [0] ExternallyDefinedParameters OPTIONAL,
data ExternallyDefinedData }
ExternallyDefinedParameters ::= EXTERNAL
ExternallyDefinedData ::= EXTERNAL
The ASN.1 for EXTERNAL is (from X.208):
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}}
ObjectDescriptor ::= [UNIVERSAL 7] IMPLICIT GraphicString
There are a bit too many choices here; the common X.400 usage for
BP15 encoding is to:
(1) Always use direct-reference
(2) Omit indirect-reference and data-value-descriptor
(3) Use the single-ASN1-type encoding only
Alvestrand Standards Track [Page 25]
RFC 2157 X.400/MIME Body Mapping January 1998
Unfortunately, some implementations have chosen to use the
octet-aligned octet-
aligned choice when constructing values where the ASN.1 type is OCTET
STRING, which of course caused interoperability problems.
An attempt to specify that X.420 only allowed the single-
ASN1-type single-ASN1-type
choice in the 1996 versions is still (Sept 1995) being debated in
ISO; the end result seems to be that all
Alvestrand Exp Nov 96 [Page 29]
draft X.400/MIME body mapping May 96 agree in principle that
single-ASN1-type should be used, but that one has to allow the
generation of the octet-
aligned octet-aligned choice as being conformant.
6. Defined Equivalences
6.1. IA5Text - text/plain
X.400 Body Part: IA5Text MIME Content-type: text/plain; charset=US-ASCII charset=US-
ASCII Conversion Type: No conversion Comments:
When mapping from X.400 to MIME, the "repertoire" parameter is
ignored.
When mapping from MIME to X.400, the "repertoire" parameter is set to
IA5 (5).
NOTE: The MIME Content-type headers are omitted, when mapping from
X.400 to MIME, if and only if the IA5Text body part is the only body
part in the IPMS.Body sequence.
NOTE: IA5Text specifies the "currency" symbol in position 2/4. This
is converted without comment to the "dollar" symbol, since the author
of this document has seen many documents in which the position was
intended to indicate "dollar" while he has not yet seen one in which
the "currency" symbol is intended.
(For reference: The T.50 (1988) recommendation, which defines IA5,
talks about ISO registered set number 2, while ASCII, using the
"dollar" symbol, is ISO registered set number 6. There are no other
differences.)
NOTE: It is not uncommon, though it is a violation of the standard,
to use 8-bit character sets inside an IA5 body part. Gateways that
can expect to encounter this situation should consider implementing
something like the guidance given in RFC 1428, 1428 [MIMETRANS],
"Transition of Internet Mail from just-
send-8 just-send-8 to 8-bit SMTP/MIME",
and generate appropriate charset parameters for the MIME messages
they generate.
Alvestrand Exp Nov 96 [Page 30]
draft X.400/MIME body mapping May 96 This behavior is not required for MIXER conformance,
since it is only needed when the base standards are violated.
Alvestrand Standards Track [Page 26]
RFC 2157 X.400/MIME Body Mapping January 1998
6.2. GeneralText - text/plain (ISO-8859)
X.400 Body Part: GeneralText; CharacterSets in
6, 14, 42, 87, 100,101,109,110,126,127,138,144,148
MIME Content-Type: text/plain; charset=ISO-8859-(1-9)
or iso-2022-jp
Conversion Type: Text conversion without character change When
mapping from X.400 to MIME, the character-set is chosen from the
table below according to the value of Parameters.CharacterSets. If no
match is found, and the gateway does not support a conversion, the
character set shall be encoded as x-iso-nnn-nnn-nnn, where "nnn" is
the numbers of the Parameters.CharacterSets, sorted in numeric order.
When mapping from MIME to X.400, GeneralText is an Extended Body
Part, hence it requires an OID. The OID for the GeneralText body is
defined in [MOTIS], part 8, annex D, as {2 6 1 4 11}. The OID for the
parameters is {2 6 1 11 11}.
The Parameters.CharacterSets is set from table below according to the
value of "charset"
The following table lists the MIME character sets and the
corresponding ISO registry numbers. If no correspondence is found,
this conversion fails, and the generic body part approach is used.
MIME charset ISO IR numbers Comment
-----------------------------------------------
ISO-8859-1 6, 100 West European "8-bit ASCII"
ISO-8859-2 6, 101 East European
ISO-8859-3 6, 109 <regarded as obsolete>
ISO-8859-4 6, 110 <regarded as obsolete>
ISO-8859-5 6, 144 Cyrillic
ISO-8859-6 6, 127 Arabic
ISO-8859-7 6, 126 Greek
ISO-8859-8 6, 138 Hebrew
ISO-8859-9 6, 148 Other Latin-using languages
Alvestrand Exp Nov 96 [Page 31]
draft X.400/MIME body mapping May 96
ISO-2022-JP 6, 14, 42, 87 Japanese
When converting from MIME to X.400, generate the correct OIDs for use
in the message envelope's Encoded Information Types by looking up the
ISO IR number numbers in the above table, and then appending it each to the
id-cs-eit-authority {1 0 10021 7 1 0} OID. OID, generating 2-4 OIDs.
Similar procedures can be used with other MIME charsets that map to a
set of ISO character sets.
Alvestrand Standards Track [Page 27]
RFC 2157 X.400/MIME Body Mapping January 1998
The escape sequences to designate and invoke the relevant character
sets in their proper positions must be added to the front of the
GeneralText character string.
For ISO 8859-1, the relevant escape sequence will be:
ESC 28 42
ASCII in G0
ESC 2D 41
ISO-IR-100 in G1
ESC 21 41
High control character set in C1
ESC 7E
Locking shift 1 Right
These escape sequences are removed when converting from GeneralText
to text/plain.
Note that new character sets may be defined on both the Internet side
and the X.400 side; a gateway MAY choose to implement more
conversions in the same fashion.
DISCUSSION:
The conversion of text is a problematic one, and one in which it is
likely that gateways should be given wide latitude to make decisions
based upon their knowledge of the user's preferences. The text given
below is thought to give the best approximation to a gateway
conforming to current and anticipated usage in the MIME and X.400
worlds, and is the way recommended when no knowledge of the
recipient's capabilities exists.
The lossless changes, such as normalizing escape sequences, should
Alvestrand Exp Nov 96 [Page 32]
draft X.400/MIME body mapping May 96
not such as normalizing escape sequences, can be
done even when "conversion-prohibited" is set. If
"conversion-with-loss-prohibited" "conversion-with-
loss-prohibited" is set, translation to a character set that is not
able to encode all characters cannot be done, and the message should
be non-delivered with an appropriate non-delivery reason.
The common use of character sets in MIME is somewhat different from
the rules given by X.400; in particular, it is common in MIME to
assume that the character sets follow strict rules. For the ISO-8859-x ISO-
8859-x character sets, it is assumed that they are designated and
invoked at the beginning of the text, and that no designation or
invocation sequences occur within the body of the text.
Alvestrand Standards Track [Page 28]
RFC 2157 X.400/MIME Body Mapping January 1998
The rules for ISO-2022-JP are given in RFC 1468, 1468 [2022-JP], and are
even more particular, using a pure 7-bit encoding in which each line
of text starts in ASCII.
Therefore, the text must be "normalized" by going through the whole
message, using a state machine or similar device to remove or rewrite
all escape and shift sequences.
Appendix A gives pseudocode for such a conversion.
NOTE: In 1988, the GeneralText body part was defined in ISO 10021-8
[MOTIS], and NOT in the corresponding CCITT recommendation; this was
added later. Also, the parameters have been heavily modified; they
should be a SET OF INTEGER in the currently valid text. Use the
latest version of the standard that you can get hold of.
6.3. BilaterallyDefined - application/octet-stream
X.400 Body Part: BilaterallyDefined
MIME Content-Type: Application/Octet-Stream (no parameters)
Conversion Type: No conversion
When mapping from MIME to X.400, if there are parameters present in
the Content-Type: header field, they are removed.
DISCUSSION:
The parameters "name" "type" and "conversions" are
Alvestrand Exp Nov 96 [Page 33]
draft X.400/MIME body mapping May 96 advisory; name and
conversions are depreciated in RFC
1521. 2046.
The parameter "padding" changes the interpretation of the last byte
of the data, but it is deemed better by the WG to delete this
information than to non-deliver the body part. The "padding"
parameter is rarely used with MIME.
Use of BilaterallyDefined Body Parts is specifically deprecated in
both 1988 and 1992 X.400. It is retained solely for backward
compatibility with 1984 systems, and because it is in common use.
6.4. FTBP EMA Unknown Attachment - application/octet-stream
X.400 Body Part: FTBP EMA Unknown Attachment
MIME Content-Type: Application/Octet-Stream
Conversion Type: No conversion
Alvestrand Standards Track [Page 29]
RFC 2157 X.400/MIME Body Mapping January 1998
The OID for the Unknown Attachment is { joint-iso-ccitt(2)
country(16) us(840) organization(1) ema(113694) objects(2)
messaging(2) attachments(1) unknown(1) }, or
2.16.840.1.113694.2.2.1.1 for short.
NOTE: Previous EMA drafts gave it as { iso(1) countries(2) usa(840)
organization (1) ema (113694) objects(2) messaging(2) attachments(1)
unknown (1)}, or 1.2.840.1.113694.2.2.1.1 for short.
The parameters for this type must be mapped according to chapter 2.3,
with the following extensions for the parameters of the
application/octet-stream:
If there is no Content-Disposition parameter with a filename, and
there is a name parameter, the
FTBP.FileTransferParameters.File-attributes.pathname FTBP.FileTransferParameters.File-
attributes.pathname is generated from this parameter. Note that
RFC 1521 2046 recommends not using the "name" parameter.
The "type", "conversions" and "padding" attributes are ignored;
"type" is for human consumption; "conversions"
Alvestrand Exp Nov 96 [Page 34]
draft X.400/MIME body mapping May 96 are discouraged in RFC 1521.
2046.
The body mapping is just copying the bytes in both directions.
6.5. MessageBodyPart - message/RFC822
X.400 body part: MessageBodyPart
MIME Content-Type: message/RFC822
Conversion Type: Special
NOTE: If the headers of the X.400 MessageBodyPart contains the
"multipart-message" heading extension with the isAMessage bit set
(either explicitly or implicitly), the mapping should be to
multipart/* according to section 6.6, below.
To map an IPMS.MessageBodyPart, the full X.400 -> RFC 822 mapping is
recursively applied, to generate an RFC 822 Message. If present, the
IPMS.MessageBodyPart.parameters.delivery-envelope is used for the MTS
Abstract Service Mappings. If present, the
IPMS.MessageBodyPart.parameters.delivery-time is mapped to the
extended RFC 822 field "Delivery-Date:".
When a message/RFC822 is contained within a MIME message, it is
mapped to an IPMS.MessageBodyPart according to MIXER. specification.
Any mappings that would have been made to the MTS Abstract Service
are placed in IPMS.MessageBodyPart.parameters.delivery-envelope.
Alvestrand Standards Track [Page 30]
RFC 2157 X.400/MIME Body Mapping January 1998
6.6. MessageBodyPart - multipart/*
X.400 body part: MessageBodyPart
MIME Content-Type: multipart/*
Conversion Type: Special
NOTE: If the headers of the X.400 MessageBodyPart do not contain the
"multipart-message" heading extension with the "isAMessage" flag FALSE,
FALSE=, the mapping should be to message/RFC822.
A MIME multipart is a set of content-types and not a message with a
set of content types. When the multipart is at the outermost MIME
header, elements of the multipart are mapped directly onto
IPMS.Bodypart.
Alvestrand Exp Nov 96 [Page 35]
draft X.400/MIME body mapping May 96
When the MIME multipart is not at the outermost level, it is mapped
to an IPMS.MessageBodyPart containing an IPMS.Bodypart for each
element of the multipart.
When a nested IPMS.Message is generated from a multipart, an
IPMS.heading shall always be generated. The only mandatory field is
the IPMS.Heading.this-IPM message id, which shall be generated by the
gateway. An IPMS.Heading.subject field shall also be generated, in
order to provide useful information to non-MIME capable X.400(88) UAs
and to all X.400(84) UAs. The subject field is set as follows
according to the multipart subtype:
mixed:
"Multipart Message"
alternative:
"Alternative Body Parts containing the same information"
digest:
"Message Digest"
parallel:
"Body Parts interpreted in parallel"
other:
"Multipart Message (<subtype>)"
For other types of multipart, the multipart subtype shall be included
in the subject line.
For each multipart, the following IPMS.HeadingExtension shall be
generated, with the value set according to the subtype.
Alvestrand Standards Track [Page 31]
RFC 2157 X.400/MIME Body Mapping January 1998
If the multipart is the outermost multipart, and the subtype is
"mixed", it may be omitted.
multipart-message HEADING-EXTENSION
VALUE MultipartType
::= id-hex-multipart-message id-hex-multipart-message-v2
MultipartType ::= SEQUENCE {
subtype IA5String,
isAMessage BOOLEAN DEFAULT TRUE }
Alvestrand Exp Nov 96 [Page 36]
draft X.400/MIME body mapping May 96
The MultipartType contains the subtype, for example "digest". If
this heading is present when mapping from X.400 to MIME, the
appropriate multipart may be generated.
The isAMessage flag is needed because of the case where a message
contains a ForwardedIPMessage, which itself was generated from a MIME
message that was a Multipart; it is set whenever the multipart is the
outermost level of nesting inside a Message/RFC822.
NOTE:
When downgrading to X.400/84, the content-type SHOULD be
regenerated from this heading-extension and put into the RFC-822-HEADERS RFC-822-
HEADERS extra body part.
NOTE:
This definition is different from the one in RFC 1494, because the
RFC 1494 definition turned out to be insufficient when new
subtypes of Multipart (like Signed or Related) were defined. That
is the reason for the "-v2" part of the name of the OID.
If both the old and the new heading extensions occur on a message,
a MIXER gateway should give preference to the new one.
6.7. Teletex - Text/Plain (Teletex)
X.400 Body Part: Teletex
MIME Content-Type: text/plain; charset=Teletex
Conversion Type: Text conversion
From X.400 to RFC-822, the conversion shall take the bytes
of all the pages in the "data" part of the
TeletexBodyPart, add a FF character (0x0C, control-L) to
each part that does not already end in one, and
concatenate them together to form the body of the
Text/Plain.
Alvestrand Standards Track [Page 32]
RFC 2157 X.400/MIME Body Mapping January 1998
The character set shall be "Teletex", which is especially
registered for this purpose. Its definition is shown in an
appendix.
The parameters are discarded.
From RFC-822 to X.400, the conversion shall split the
content at each occurrence of the FF character (0x0C),
delete the character and construct the Teletex body part
as a SEQUENCE OF TeletexString, as described in X.420(88),
section 7.3.5
The TeletexParameters may, but need not, contain the
Alvestrand Exp Nov 96 [Page 37]
draft X.400/MIME body mapping May 96
number-of-pages component.
NOTE: It is recommended, but not mandated, that the data
be converted into a more widespread character set like
ISO-8859-1 or ISO-2022-JP (if applicable) if possible.
This will result in the reverse translation giving a
GeneralText body part, which will have to be dealt with
appropriately at the X.400/88 to X.400/84 downgrading
boundary, if possible, but will give a much greater chance
that the MIME recipient can actually read the message.
DISCUSSION:
The Teletex body part is frequently used in X.400(84) to
send around text with slightly extended character sets
beyond ASCII.
Its body consists of a series of "pages", separated by
ASN.1 representation. It is important to many people to
have this mapped into something that is readable to most
end-users; therefore, it is recommended to map this onto
Text/Plain; however, since this is not plain text, the
conversion must be specified.
Alvestrand Exp Nov 96 [Page 38]
draft X.400/MIME body mapping May 96
Note that the definition of Text/Plain permits only CRLF as a line
separator; the sequences "CR FF" and "CR LF LF LF.." permitted in
Teletex must be encoded as Quoted-Printable.
7. Body parts where encapsulation is recommended
Some body parts are MIME constructs, and their functionality will be
severely damaged if they are coerced into an X.400 framework.
Special care needs to be taken with these; they are described below.
Alvestrand Standards Track [Page 33]
RFC 2157 X.400/MIME Body Mapping January 1998
7.1. message/external-body
The gateway MUST support the encapsulation of this body part using
the HARPOON encapsulation (IA5).
It MAY support some kind of retrieval of the referred object.
DISCUSSION:
The message/external-body part points to an object that can be
retrieved using Internet protocols.
There are three cases to consider for the recipient's capabilities:
(1) The user has no Internet access. In this case, the
user might be grateful if the gateway fetches the body part and
inserts it into the message. If the body part is large or
dynamic, it might not be appropriate.
(2) The user has Internet access, but no UA support for
fetching external-body objects.
(3) The user has Internet access and UA support for
fetching external-body objects, based on an understanding of
this document.
Some access-types, like anonymous FTP, are easy to resolve. Others,
like the Mailserver access-type, are almost impossible to resolve at
a gateway.
Alvestrand Exp Nov 96 [Page 39]
draft X.400/MIME body mapping May 96
To support the second case above, the tunneling method chosen is the
HARPOON encapsulation described in section 3.1.3, using an IA5 body
part, inserting the string "MIME-
Version: "MIME-Version: 1.0 (generated by gateway)"
at the beginning of the body part. (The part in parentheses can be
changed at will).
This will:
(1) Maximize the chance that the user will see the
message
(2) Give the user hints that will enable him to fetch
the message using other Internet tools
(3) Identify the message as a MIME object in a reliable
fashion, allowing UAs to support the fetching of the object if
the UA implementor desires.
Alvestrand Standards Track [Page 34]
RFC 2157 X.400/MIME Body Mapping January 1998
7.2. message/partial
This represents part of a larger message, where it is only possible
to parse the complete message after getting all the pieces.
The gateway MUST support the encapsulation of this body part.
It MAY implement transparent reassembly of the message, but in this
case, it MUST support a configurable timeout
for the reassembly, defaulting back to encapsulation.
DISCUSSION:
The gateway's choices are:
(1) Wait until all the pieces arrive at the gateway,
reassemble the message, and use normal processing
(2) Encapsulate the message, using any encapsulation
method (BP15, FTAM or HARPOON).
Alvestrand Exp Nov 96 [Page 40]
draft X.400/MIME body mapping May 96
In some cases, not all pieces will arrive at the gateway; some may
have been transferred through other gateways due to route changes or
machine outages; some may have been lost in transit.
7.3. multipart/signed
A gateway MUST implement encapsulation of multipart/signed using
HARPOON.
The gateway MAY be configured to do other processing, as outlined in
the discussion below. This is outside the scope of the standard.
DISCUSSION:
Gatewaying security is a problem. The gateway can basically take
three approaches:
- Strip the multipart/signed, leaving the bare body
part unsecured, possibly with a comment that the signature was
stripped
- Attempt to check the signature and re-signing the
message using X.400 security functions, then stripping as above
- Encapsulate the message. This is the only approach
that allows end to end security, but requires MIME functionality
at the recipient.
Alvestrand Standards Track [Page 35]
RFC 2157 X.400/MIME Body Mapping January 1998
- Replace the message content with multiple body parts,
containing first an unsecured body part and then the
encapsulated multipart/signed.
All these are valid options for a MIXER gateway.
Note that the encapsulation must use HARPOON, as the signature is
computed on the ENCODED body part, not on the canonical
representation, and HARPOON is the only encapsulation that preserves
the content transfer encoding of the message.
Alvestrand Exp Nov 96 [Page 41]
draft X.400/MIME body mapping May 96
Note also that all methods except for encapsulation break end-to-end
security; the recipient can place no more trust in the integrity of
the message than he can place in the security of the gateway.
7.4. multipart/encrypted
A gateway MUST implement encapsulation of multipart/encrypted using
HARPOON.
If the implementor chooses to allow other processing at the gateway,
as outlined below, he/she is advised that there are grave security
concerns with such a solution, since it violates the general rule of
keeping decryption keys as close to the user as possible.
DISCUSSION:
There are two basic cases for a gateway:
- The gateway is trusted with the user's keys. In this
case, the gateway can decrypt the message, possibly add a note
that it has done so, and gateway the unencrypted form, possibly
applying X.400 security functions, and possibly attaching a copy
of the original, encrypted material for reference. This does
nothing to protect the transfer from gateway to recipient,
unless suitable X.400-native security is applied. It also means
that the gateway must be part of the user's trusted environment.
- The gateway is not trusted with the recipient's keys.
In this case, encapsulation is the only approach that preserves
any information at all.
The valid options for a MIXER gateway are therefore:
- Decrypt the body part
- Encapsulate the body part
Alvestrand Exp Nov 96 Standards Track [Page 42]
draft 36]
RFC 2157 X.400/MIME body mapping May 96 Body Mapping January 1998
- Drop the body part
The MIXER WG has shown strong preference for the encapsulation
alternative, and urges anyone who thinks of buying or implementing
gateway decryption to carefully evaluate this choice in light of the
company's general security policy.
8. Conformance requirements
In order to be called MIXER conformant, a gateway must implement:
- Encapsulation of MIME content in the FTBP body part
- Encapsulation of X.400 body parts in the x400-bp body
part
- Encapsulation of FTBP body parts in the
application/x-oid.n.n.n
application/x-ftbp.oid body part
- Encapsulation of security multiparts using HARPOON
- Text/plain <-> IA5Text
- Text/plain; charset=iso-8859-* <-> GeneralText
- Multipart/* <-> ForwardedIPMessage
- message/RFC822 <-> ForwardedIPMessage
- application/octet-stream <-> FTBP unknown
- application/octet-stream <-> BilaterallyDefined
- A configuration choice of which application/octet-
stream translation to use
All other parts of this specification MAY be implemented by the
gateway. If they are implemented at all, they MUST
Alvestrand Exp Nov 96 [Page 43]
draft X.400/MIME body mapping May 96 be implemented
conformant to this specification.
In this context, a feature is "implemented" in a product if it is
possible to configure the product in such a way that this feature is
used. This specification does not restrict the product to only be
configured in such a fashion.
Alvestrand Standards Track [Page 37]
RFC 2157 X.400/MIME Body Mapping January 1998
9. Security considerations Considerations
The security issues identified in this memo are:
(1) Security implications of using filenames that
arrive in body part headers (section 2.3.2)
(2) Security implications of letting a gateway handle
encrypted and/or signed content (section 7.3 and 7.4)
If a gateway fetches message/external-body on behalf of the
recipient, as described in section 7.1, it may be tricked into
performing inappropriate actions by malicious senders.
In addition, all the normal caveats that apply to sending data that
may contain executable code apply to UAs on both sides of the
gateway.
10. Author's address Address
Harald Tveit Alvestrand
UNINETT
P.O.box 6883 Elgeseter
N-7002 Trondheim
NORWAY
EMail: Harald.T.Alvestrand@uninett.no
Alvestrand Exp Nov 96 [Page 44]
draft X.400/MIME body mapping May 96
11. Acknowledgements
The author wishes to thank all the members of the MIXER WG for their
valuable input, and in particular (in no particular order):
Steve Kille, Peter Sylvester, Ned Freed, Julian Onions, Ruth Moulton,
Keith Moore, Alain Zahm, Urs Eppenberger, Kevin Jordan, Jeroen
Houttuin, Claudio Allocchio, Colin Robbins, Steven Thomson, Jim
Craigie, Efifiom Edem, David Wilson, and many others who have been
active over the long lifetime of this document.
References
[RFC-822]
D.H.
Crocker, Standard D., "Standard for the Format of ARPA Internet Text Messages. Request for Comments
Messages", STD 11, RFC 822,
(August, 1982). August, 1982.
Alvestrand Standards Track [Page 38]
RFC 2157 X.400/MIME Body Mapping January 1998
[MIME]
Freed, N. Borenstein, and N. Freed, MIME: Mechanisms Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
[MIME-HDR]
Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
Three: Message Header Extensions for
Specifying Non-ASCII Text", RFC 2047,
November 1996.
[HARPOON]
Alvestrand, H., Romaguera, J., and Describing K. Jordan, "Rules for
downgrading messages from X.400/88 to X.400/84 when MIME
content-types are present in the Format messages", RFC 1496, August
1993.
[MIMETRANS]
Vaudreuil, G., "Transition of Internet
Message Bodies. Request for Comments 1521, (June,
1992). Mail from Just-Send-8 to
8Bit-SMTP/MIME", RFC 1428, February 1993.
[MIXER]
S.E.
Kille, Mapping S., "Mapping between X.400(1988) / ISO 10021 and RFC-822. (in preparation) RFC-822",
RFC 1327, May 1992.
[T.4]
CCITT Recommendation T.4, Standardization of Group 3 Facsimile
Apparatus for Document Transmission (1988)
[T.30]
CCITT Recommendation T.30, Procedures For Document Facsimile
Transmission in the General Switched Telephone Network (1988)
[T.411]
CCITT Recommendation T.411 (1988), Open Document Architecture
(ODA) and Interchange Format, Introduction and General Principles
Alvestrand Exp Nov 96 [Page 45]
draft X.400/MIME body mapping May 96
[MOTIS]
ISO/IEC International Standard 10021, Information technology -
Text Communication - Message-Oriented Text Interchange Systems
(MOTIS) (Parts 1 to 8)
[X.400]
CCITT, Data Communication Networks - Message Handling Systems -
Recommendations X.400 - X.420 (1988 version)
Alvestrand Standards Track [Page 39]
RFC 2157 X.400/MIME Body Mapping January 1998
[X.420]
CCITT Recommendation X.420 (1988), Interpersonal Messaging System
[RFC-X400USE]
Harald Tveit
Alvestrand, X.400 H., "X.400 use of extended Character Sets, Internet Draft, June 1992 Sets", RFC 1502,
August 1993.
[MAWG]
Electronic Messaging Association Message Attachment Working Group
(MAWG): File Transfer Body Part Feasibility Project Guide -
version 1.5 - September 1995
[CDISP]
Dorner &
Troost, R., and S. Dorner, "Communicating Presentation Information
in Internet Messages: The Content-Disposition header - Header", RFC
1806 1806,
June 1995.
[POSTSCRIPT]
Harald Tveit
Alvestrand, Carrying H., "Carrying PostScript in X.400 and MIME, Work In Progress (draft-ietf-mixer-
postscript-00.txt) MIME", RFC 2160,
June 1997.
[IMAGES]
Harald Tveit
Alvestrand, X.400 image body parts, Work
In Progress (draft-ietf-mixer-images-00.txt) H., "X.400 Image Body Parts", RFC 2158, June 1997.
[ODA]
Harald Tveit
Alvestrand, A H., "A MIME body part Body Part for ODA", RFC 2161, June 1997.
[ISO 2022]
ISO/IEC 2022:1994(E): Information technology - Character code
structure and extension techniques
[ISO 8859]
ISO 8859: Information processing -- 8-bit single-byte coded
graphic character sets (various parts)
[2022-JP]
Murai, J., Crispin, M., and E. van der Poel, "Japanese Character
Encoding for Internet Messages", RFC 1468, June 1993.
[MUST]
Bradner, S., "Key words for ODA,
Work use in Progress (draft-ietf-mixer-oda-00.txt) RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
Alvestrand Exp Nov 96 Standards Track [Page 46]
draft 40]
RFC 2157 X.400/MIME body mapping May 96 Body Mapping January 1998
APPENDIXES
Appendix A: Escape code normalization
The algorithm given here in pseudocode will reduce a GeneralString
ISO-2022 unlimited use of shifts sequence to a pure 8-bit sequence
that does not use shift sequences, if possible.
Some error conditions, like EOF, are not tested for. It crashes if
asked to do something it cannot. Control character set switching is
missing.
A similar routine, albeit more complex, can be written for
normalizing to the ISO-2022-JP character set.
BEGIN: (from X.209)
g0 = 6 (should be 2, but ignore the difference)
g1 = NULL
g2 = NULL
g3 = NULL
c0 = 1 (ASCII control)
c1 = NULL
leftset = &g0 (current input set, low)
rightset = &g1 (current input set, high)
lowset = 6 (output set, low)
highset = NULL (output set, high)
charset = US-ASCII
(Init for the set tables)
chartoid[{2D,2E,2F}, 41] = 100
.....
idtoname[100] = "ISO-8859-1"
.....
WHILE (more data)
CASE head of input
{These are the locking shift sequences}
INCASE "00/14": (LS0, SO)
leftset = &g0;
INCASE "00/15": (LS1, SI)
leftset = &g
INCASE "ESC 07/14": (LS1R)
rightset = &g1;
Alvestrand Exp Nov 96 [Page 47]
draft X.400/MIME body mapping May 96
INCASE "ESC 07/13": (LS2R)
rightset = &g2;
INCASE "ESC 07/12": (LS3R)
rightset = &g3;
{There is missing code for handling the single shift function}
Alvestrand Standards Track [Page 41]
RFC 2157 X.400/MIME Body Mapping January 1998
{These are the changes of graphic character sets}
{Note that G0 can contain only 94-character charsets}
INCASE "ESC 28"
g0 = chartoid[lastchar, next character]
sethiset(g0)
INCASE "ESC 2D", "ESC 29"
g1 = chartoid[lastchar, next character]
sethiset(g1)
INCASE "ESC 2E", "ESC 2A"
g2 = chartoid[lastchar, next character]
sethiset(g2)
INCASE "ESC 2F", "ESC 2B"
g3 = chartoid[lastchar, next character]
sethiset(g3)
{control characters. There is missing code for changing these}
INCASE 00/00-01/15 {normal control}
write(char)
INCASE 08/00-09/15 {upper control}
write(char)
{Normal characters}
INCASE 02/00-07/15 (Left)
IF (*leftset == lowset)
write(char)
ELSIF (*leftset == highset)
write(char+80)
ELSE
ERROR "Shift error"
ENDIF
INCASE 10/00-15/15
IF (*rightset == highset)
write(char)
ELSIF (*rightset == lowset)
write(char-80)
ELSE
ERROR "Shift error"
ENDIF
ENDCASE
ENDWHILE
SUBROUTINE sethighset(g1)
Alvestrand Exp Nov 96 [Page 48]
draft X.400/MIME body mapping May 96
IF (highset == NULL)
charset = idtoname[g1]
highset = g1
ELSIF (highset == g1)
(it's OK)
ELSE
ERROR "Too many charsets encountered"
Alvestrand Standards Track [Page 42]
RFC 2157 X.400/MIME Body Mapping January 1998
ENDIF
ENDROUTINE
Alvestrand Standards Track [Page 43]
RFC 2157 X.400/MIME Body Mapping January 1998
Appendix B: OID Assignments
MIXER-MAPPINGS DEFINITIONS ::= BEGIN
EXPORTS -- everything --;
IMPORTS
experimental
FROM RFC1155-SMI;
mixer -- { iso(1) org(3) dod(6) internet(1) mail(7) mixer(1) }
FROM MIXER --Companion RFC--;
mixer-bp-data
mixer-headings OBJECT IDENTIFIER ::=
{ mixer 1 };
mixer-bp-parameter } -- called mime-mhs-headings in RFC 1495 --
mixer-bodies OBJECT IDENTIFIER ::=
{ mixer 2 }; } -- called mime-mhs-bodies in RFC 1495 --
-- mixer-core is defined as { mixer core(3) } in [MIXER]
mixer-bp-heading
mixer-bp-data OBJECT IDENTIFIER ::=
{ mixer 4 } mixer-bodies 1 }; -- called mime-mhs-bp-data in RFC 1494 --
mixer-bp-parameter OBJECT IDENTIFIER ::=
{ mixer-bodies 2 };
id-mime-bp-data OBJECT IDENTIFIER ::=
{ mixer-bp-data 1}; 1 };
-- for debugging: mixer-bp-data is 1.3.6.1.7.1.2.1.1
id-mime-bp-parameters OBJECT IDENTIFIER ::=
{ mixer-bp-parameter 1}; 1 };
-- the following assignments were done in RFC 1494, using
-- slightly different names, but the same numbers.
-- their defining text is now is now in other documents
id-mime-postscript-body OBJECT IDENTIFIER ::=
{ mixer-bp-data 2}
Alvestrand Exp Nov 96 [Page 49]
draft X.400/MIME body mapping May 96 2 }
id-mime-jpeg-body OBJECT IDENTIFIER ::=
{ mixer-bp-data 3} 3 }
id-mime-gif-body OBJECT IDENTIFIER ::=
{ mixer-bp-data 4}; 4 }
-- This is a new definition, and defines an FTAM application
reference,
-- not a BP15 data OID.
id-mime-ftbp-data OBJECT IDENTIFIER ::=
{ mixer-bp-data 5 mixer-bp-data 5 }
Alvestrand Standards Track [Page 44]
RFC 2157 X.400/MIME Body Mapping January 1998
-- The following heading extensions are defined
id-hex-partial-message OBJECT IDENTIFIER ::=
{ mixer-headings 1 }
id-hex-multipart-message OBJECT IDENTIFIER ::=
{ mixer-headings 2 } -- from RFC 1495; obsolete
id-hex-multipart-message-v2 OBJECT IDENTIFIER ::=
{ mixer-headings 3 }
END
Alvestrand Exp Nov 96 Standards Track [Page 50]
draft 45]
RFC 2157 X.400/MIME body mapping May 96 Body Mapping January 1998
Appendix C: Registration information for the Teletex
character set
The Teletex character set is a character set in which the ISO 2022
character set switching mechanism may be used to switch between the
following registered ISO character sets:
ISO-IR-87 - JIS_C6226-1983; a 16-bit Japanese character set
ISO-IR-102 - a fairly standard US-ASCII variant
ISO-IR-103 - Latin characters using non-spacing accents
ISO-IR-106 - Control characters for C0 use; CR, LF, FF and a few more.
ISO-IR-107 - Control characters for C1 use
Its intended use of this character set is to represent data that
comes from ISO protocols that use the ASN.1 construct "TeletexString"
or "T61string" without conversion.
The set of allowed character sets can be found in CCITT
recommendation X.208(1988), chapter 31.2 and Table 6/X.208.
The rules for encoding the data type can be found in CCITT
recommendation X.209(1988), chapter 23. It states that at the
beginning of the string, G0 is always ISO-IR-102, C0 is ISO-IR-106,
and C1 is ISO-IR-107.
The specification seems somehow to have missed the implicit
assumption that ISO-IR-103 is designated and invoked as G1 and
shifted into the upper half of the character set which seems to be
assumed at least by the X.400 and X.500 software that uses
TeletexStrings; implementors should act as if the sequence ESC 2/9
7/6 LS1R is always present at the beginning of the data. data; however,
when generating Teletex strings, implementors should include the
sequence ESC 2/9 7/6 within the string before the first occurence of
a character from ISO-IR-103.
The rules for interpreting T.61 data are found (I believe) in CCITT
recommendations T.51, T.52 and T.53 (data from the ITU WWW server):
Alvestrand Exp Nov 96 [Page 51]
draft X.400/MIME body mapping May 96
T.51 (09/92) [Rev.1] [26 pp.] [Publ.: May.93]
Latin based coded character sets for telematic services
T.52 (1993) [New] [88 pp.] [Publ.: Apr.94]
Non-Latin coded character sets for telematic services
T.53 (04/94) [New] [68 pp.] [Publ.: Jan.95]
Character coded control functions for telematic services
The Teletex character set is closely related to (but not identical
with) that specified in ISO 6937.
Alvestrand Standards Track [Page 46]
RFC 2157 X.400/MIME Body Mapping January 1998
No further restrictions are imposed by this registration; in
particular, character set switching can occur anywhere, and there is
no guarantee that the character sets will be switched "back" at the
end.
Alvestrand Exp Nov 96 Standards Track [Page 52]
draft 47]
RFC 2157 X.400/MIME body mapping May 96 Body Mapping January 1998
Appendix D: IANA Registration form for new mappings
To: IANA@isi.edu
Subject: Registration of new X.400/MIME content type mapping
MIME type name:
(this must have been registered previously with IANA)
X.400 body part:
IF BP15:
- X.400 Object Identifier for Data:
(If left empty, an OID will be assigned by IANA under mixer-bp-data)
- X.400 Object Identifier for Parameters:
(If left empty, an OID will be assigned by IANA under
mixer-bp-parameter. mixer-bp-
parameter. If it is not used, fill in the words NOT USED.)
X.400 ASN.1 Syntax:
(must be an EXTENDED-BODY-PART-TYPE macro, or refer
ence reference to a Basic
body part type)
IF FTBP:
- FTAM Object Identifier for application-reference:
- FTAM Object Identifier for contents-type:
(if left empty, unstructured-binary is assumed)
Conversion algorithm:
(must be defined completely enough for independent im
plementation. implementation. It
may be defined by reference to RFCs).
Person & email address to contact for further informa
tion:
Alvestrand Exp Nov 96 [Page 53]
draft X.400/MIME body mapping May 96 information:
INFORMATION TO THE SUBMITTER:
The accepted registrations will be listed in the "As
signed "Assigned Numbers"
series of RFCs. The information in the registration form is freely
distributable.
Table of Contents
Status of this Memo ................................ 1
1 Introduction ...................................... 2
1.1 Glossary ........................................ 2
2 Basic rules for body part conversion .............. 3
2.1 Generating the IPM Body from MIME ............... 5
2.2 Generating the MIME
Alvestrand Standards Track [Page 48]
RFC 2157 X.400/MIME Body from the IPMS.Body ..... 5
2.3 Mapping the EMA FTBP parameters ................. 7
2.3.1 Mapping GraphicStrings ........................ 7
2.3.2 Mapping specific parameters ................... 8
2.3.3 Summary January 1998
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of FTBP elements generated ............ 11
2.4 Information it may be copied and furnished to
others, and derivative works that is lost when mapping ........... 12
3 Encapsulation of body parts ....................... 13
3.1 Encapsulation comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of MIME any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in X.400 .................. 13
3.1.1 FTBP encapsulating body part .................. 14
3.1.2 BP15 encapsulating body part .................. 15
3.1.3 Encapsulation using IA5 (HARPOON) ............. 17
3.1.4 Content passing using BP14 .................... 18
3.2 Encapsulating X.400 Body Parts any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in MIME .......... 18
3.3 Encapsulating FTBP body parts which case the procedures for
copyrights defined in MIME ........... 19
4 User control over the gateway choice .............. 20
4.1 Conversion from MIME to X.400 ................... 21
4.2 Conversion from X.400 Internet Standards process must be
followed, or as required to MIME ................... 23
5 translate it into languages other than
English.
The equivalence registry .......................... 24
5.1 What information one must give about a mapping
................................................ 24
5.2 Equivalence summary for known X.400 limited permissions granted above are perpetual and MIME
Types .......................................... 25
5.3 MIME to X.400 Table ............................. 26
5.4 X.400 to MIME Table ............................. 27
5.5 Use of OBJECT IDENTIFIERs will not be
revoked by the Internet Society or its successors or assigns.
This document and ASN.1 MACROS ...... 28
6 Defined Equivalences .............................. 30
6.1 IA5Text - text/plain ............................ 30
6.2 GeneralText - text/plain (ISO-8859) ............. 31
6.3 BilaterallyDefined - application/octet-stream
Alvestrand Exp Nov 96 [Page 54]
draft X.400/MIME body mapping May 96
................................................ 33
6.4 FTBP EMA Unknown Attachment - applica
tion/octet-stream .............................. 34
6.5 MessageBodyPart - message/RFC822 ................ 35
6.6 MessageBodyPart - multipart/* ................... 35
6.7 Teletex - Text/Plain (Teletex) .................. 37
7 Body parts where encapsulation is recommended ..... 39
7.1 message/external-body ........................... 39
7.2 message/partial ................................. 40
7.3 multipart/signed ................................ 41
7.4 multipart/encrypted ............................. 42
8 Conformance requirements .......................... 43
9 Security considerations ........................... 44
10 Author's address ................................. 44
11 Acknowledgements ................................. 45
References ......................................... 45
APPENDIXES ......................................... 47
Appendix A: Escape code normalization .............. 47
Appendix B: OID Assignments ........................ 49
Appendix C: Registration information for the
Teletex character set .......................... 51
Appendix D: IANA Registration form for new map
pings .......................................... 53
Table of Contents .................................. 54 information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Alvestrand Exp Nov 96 Standards Track [Page 55] 49]
----