draft               X.400/MIME body mapping             May 96

      Mapping between X.400 and RFC-822/MIME Message Bodies

                 Thu Aug 15 14:51:04 MET DST 1996

                     Harald Tveit Alvestrand

    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 an Internet Draft.  Internet Drafts
         are working documents of the Internet Engineering
         Task Force (IETF), its Areas, and its Working Groups.
         Note that other groups may also distribute working
         documents as Internet Drafts.

         Internet Drafts are draft documents valid 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."

         Please check the I-D abstract listing contained in
         each Internet Draft directory to learn the current
         status of this or any other Internet Draft.

    This document describes the translation of message body
    parts between X.400 and MIME.

    Please send comments to the MIXER mailing list:

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 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 and forwarded messages.

    A table of contents that should be quite useful for
    locating specific sections is given in the back of the

    1.1.  Glossary

    The following terms are defined in this document:

    Body part
         Part of a message that has a unique type. This term
         comes from X.400; the corresponding term in MIME (RFC
         1521) is limited to use in parts of a multipart
         message; the term "body" may correspond better.

         Type information indicating what the content of a
         body part actually is. This term comes from MIME; the
         corresponding X.400 term is "body part type".

         (noun): A description 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.

         A set of two mappings that taken together provide a
         lossless conversion between an X.400 body part and a
         MIME body part

         The process of wrapping something from one of the
         mail systems 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 body mapping             May 96

         reasonable sense of the body part, but a gateway back
         into the first system will always be able to convert
         the body part without loss back to its original

    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).

         What happens when 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.

         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 a gateway.

    2.  Basic rules for body part conversion

    The basic approach for translating body parts is described
    in section 2.1 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.


    At the moment (Sept 1995) both the MIME and the X.400
    worlds are in a state of flux with regards to carrying
    around stuff that is not text.

Alvestrand                Exp Nov 96                  [Page 3]

draft               X.400/MIME body mapping             May 96

    In such a situation, there is little chance of defining a
    mapping between them that is the best for all people, all
    of the time.
    For this reason, this specification allows a gateway
    considerable latitude in deciding exactly what conversion
    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 the recipient is able to handle, or has
           registered a particular set of preferences for a
           user, and knows how to convert the message
           reasonably to those body parts, the gateway may
           choose to convert body parts in the message to
           those types only.

     (2)   If the gateway gets indications (via special
           headers or heading-extensions defined for the
           purpose) that the sender wanted a particular
           representation on the "other side", and the gateway
           is able to satisfy the request, it may do so. Such
           a mechanism is defined in chapter 4 of this

     (3)   If the gateway gets a message that might be
           appropriate to send as one out of several types,
           but where the typing information does not tell you
           which one to use (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

     (4)   If the gateway knows that the next hop for the
           message has limited capabilities (like X.400/84),
           it may choose to perform conversions appropriate
           for 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 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
           be able to be configured for encapsulation.

    In many cases, a message that goes SMTP->X.400->SMTP will
    arrive 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

    This is believed to be unavoidable.

    2.1.  Generating the IPM Body from MIME

    When converting the body 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 an IPMS.Body with a single IPMS.BodyPart of
    type IPMS.IA5TextBodyPart containing the 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 a
    MIME message and the body is converted according to the
    mappings configured and implemented in the gateway.

    2.2.  Generating the MIME Body from the IPMS.Body

    When converting the body of a message from X.400 to MIME,
    the following steps are taken:

Alvestrand                Exp Nov 96                  [Page 5]

draft               X.400/MIME body mapping             May 96

    If there is more than one body part, and the first body
    part is IA5 and starts with the string "RFC-822-Headers:"
    as the first line, then the remainder of this body part
    shall be appended to the RFC 822 header.  This relies upon
    the theory that this body part has been generated
    according to Appendix B of MIXER.  A gateway shall check
    the consistency and syntax of this body part, to ensure
    that the resulting message is conformant with RFC 822.

    If the remaining IPMS.Body consists of a single
    IPMS.Bodypart, there are three possibilities.

     (1)   If it is of type IPMS.IA5Text, and the first line
           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 the message. If an
           RFC 822 syntax error is discovered inside the
           message, it may be mapped directly as described
           below instead.

     (2)   If it is of type IPMS.IA5Text, then this is mapped
           directly and no MIME encoding is used.

     (3)   All other types are mapped according to the
           mappings configured and implemented in the gateway.

    If the IPMS.Body contains multiple IPMS.Bodypart fields,
    then a MIME message of content type multipart is
    generated.  If all of the body parts are messages, then
    this is multipart/digest.  Otherwise it is
    multipart/mixed.  The components of the multipart are
    generated in the same order as in the IPMS.Body.

    Each component is mapped according to the mappings
    configured and implemented in the gateway; any IA5 body
    parts are checked to see if they are HARPOON mappings.

Alvestrand                Exp Nov 96                  [Page 6]

draft               X.400/MIME body mapping             May 96

    2.3.  Mapping the EMA FTBP parameters


    EMA has defined a profile for use of the File Transfer
    Body Part (FTBP). [MAWG]

    New mappings are expected to use this as the mechanism for
    carrying body parts, and since it is important to have a
    consistent mapping for the special FTBP parameters, these
    are defined here.

    The mapping of the body will depend on the content-type in
    MIME and on the application-reference in FTBP, and is not
    specified here.

    However, in many cases, we expect that the translation
    will involve simply copying the octets from one format to
    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 to ASCII for use in mail headers, the gateway
    may either:

     (1)   Use the RFC 1522 encoding mechanism to create
           appropriate encoded-words for the headers involved.
           Note that in some cases, such as within Content-
           Disposition filenames, the encoded-words must be in
           quotes, which is not the normal usage of encoded-

     (2)   Apply the normalization procedure given in Appendix
           A to identify the ASCII characters of the string,
           and replace all non-ASCII characters with the
           question mark (?).

Alvestrand                Exp Nov 96                  [Page 7]

draft               X.400/MIME body mapping             May 96

    Both procedures are valid for MIXER gateways; the
    simplified procedure of ignoring escape sequences and bit-
    stripping the result is NOT valid.

    2.3.2.  Mapping specific parameters

    The following parameters are mapped in both directions:


         The mapping of this element is complex.

         The Content-ID is encoded as an IPM.MessageIdentifier
         and entered into the

         relationship.descriptive-relationship is set to the
         string "Internet MIME Body Part".

         crossreference is set to a null OCTET STRING.

         The reverse mapping is only performed if the
         relationship.descriptive-relationship has the string
         value "Internet MIME Body Part".


         The value of this field is mapped to and from the
         first string in

Alvestrand                Exp Nov 96                  [Page 8]

draft               X.400/MIME body mapping             May 96


         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 ->
         X.400 mapping, and is always "attachment" on X.400 ->
         MIME mapping.

         NOTE: RFC 1806 gives only the "filename" component.
         The other components are expected to be added to the
         next version of RFC 1806.

    C-D: filename

         The filename component of the C-D header is mapped to
         and from FileTransferParameters.file-

         The EBNF.disposition-type is ignored when creating
         the FTBP pathname, and always set to "attachment"
         when creating the Content-Disposition header.  For

           Content-Disposition: attachment; filename=dodo.doc


           Content-Disposition: attachment; filename=/etc/passwd

         The filename will be carried as a single incomplete-
         pathname string. No special significance is assumed
         for the characters "/" and "\". Note that normal
         security precautions MUST be taken in using a
         filename on a local file system; this should be
         obvious from the second example.

         This is done to be conformant with 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-

         For this and all other date fields, the RFC-822 date
         format is used (822.date-time). Note that the
         parameter syntax of RFC 1806 requires that all dates
         be quoted!

    C-D: Modification-date

         Mapped to and from FileTransferParameters.file-

    C-D: Read-date

         Mapped to and from FileTransferParameters.file-

    C-D: Size

         Mapped to and from FileTransferParameters.file-
         attributes.object-size. If the value is "no-value-
         available", the component is NOT generated.

    Other RFC-822 headers

         Mapped to  extension in
         FTBP.FileTransferParameters.extensions using the
         rfc-822-field HEADING-EXTENSION from [MIXER].

         The set of headers that are mapped will depend on the
         placement of the body part (single body part or
         When it is the only body of a message, headers
         starting with "content-" SHOULD be put into the FTAM
         extension, 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 it is a single bodypart of a multipart, ALL
         headers on the 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


         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 of showing the content of this field to
         the user.

         An alternative approach using
         string was suggested to EMA, and the EMA MAWG
         recommended in its April 1996 conference that the
         IETF MIXER group should rather choose this approach.

    2.3.3.  Summary of FTBP elements generated

    This is a summary of the preceding section, and does not
    add new information.

    The following elements of the FTBP parameters are mapped
    or used (the rightmost column gives their status in the
    EMA profile; M=Mandatory, O=Optional, R=Recommended for

    FileTransferParameters                                             M/M
      Related-Stored-File                                              O/O
            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

Alvestrand                Exp Nov 96                 [Page 11]

draft               X.400/MIME body mapping             May 96

        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 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 set.

    2.4.  Information that is lost when mapping

    MIME defines fields which add information to MIME
    contents.  Two of 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:

     (1)   When using encapsulation, the information can be

     (2)   When using mapping to FTBP, the information can be
           preserved in the FileTransferParameters.extensions
           defined for that purpose.

     (3)   When mapping to a single-body message, the
           information can be preserved as P22 header

     (4)   When mapping to other body part types, 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
    of the following alternatives:

    -    Discard the body part, leaving a "marker" saying what

    -    Reject the message

    -    "Encapsulate" the body part, by wrapping it in a body
         part defined for that purpose in the other mail

    The choice to be made should be configurable in the
    gateway, and may depend on both policy and knowledge of
    the recipient's capabilities.

    3.1.  Encapsulation of MIME in X.400

    Four body parts are defined here to encapsulate MIME body
    parts in X.400.

    The BP15 body part is backwards compatible with RFC 1494.
    The FTBP body part is compatible with the 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 are:

    FTBP For use when sending to recipients that 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 links may involve

    BP14 For use when the recipient may be an X.400(84) UA
         with BP14 handling capability, and the loss of
         information in headers is not regarded as important.

Alvestrand                Exp Nov 96                 [Page 13]

draft               X.400/MIME body mapping             May 96

    but the gateway is free to use any method it finds
    appropriate in any situation.

    FTBP is expected to be the most useful body part in
    sending to X.400(92) systems, while the BP14 content
    passing is primarily useful for sending to X.400(84)

    3.1.1.  FTBP encapsulating body part

    This body part utilizes the fundamental assumption in MIME
    that all message content can be legally and completely
    represented by a single octet stream, the "canonical

    The FTBP encapsulating body part is defined by the
    application-reference id-mime-ftbp-data; all headers are
    mapped to the FTBP headers, including putting the
    "Content-type:" header inside the FTBP ExtensionsField.

    Translation from the MIME body part is done by:

    -    Undoing the content-transfer-encoding

    -    Setting the "FileTransferData.FTdata.value.octet-
         aligned" to the resulting string of octets

    -    Putting the appropriate parameters into the headers.

    Reversing the translation is done by:

    -    Extracting the headers

    -    Applying an appropriate content-transfer-encoding to
         the body. If this is for some reason different from
         the content-transfer-encoding: header retrieved from
         the headers, the old one must be deleted.

    This mapping is lossless, and therefore counts as "no

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 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 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 in Appendix L of [MIXER].

         The "type/subtype" string is mapped to

         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 the parameter-value.

Alvestrand                Exp Nov 96                 [Page 15]

draft               X.400/MIME body mapping             May 96

         Take all other headers and create

         The MIME-version, content-type and content-transfer-
         encoding fields are NOT copied.

         The set of headers that are mapped will depend on the
         placement of the body part (single body part or
         When it is the only body of a message, headers
         starting with "content-" SHOULD be put into the
         other-header-fields, and all other headers should be
         put into the IPMS extension for the message.
         When it is a single bodypart of a multipart, ALL
         headers on the 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

    The body is mapped as follows:

    Convert the MIME body part into its canonical form, as
    specified in Appendix H of MIME [MIME].  This canonical
    form is used to generate the mime-body-part.data octet

    The Parameter mapping may be used independently of the
    body part mapping (e.g., in order to use a different
    encoding for a mapped MIME body part).

    This body part contains all of the MIME information, and
    so can be mapped back to MIME without loss of information.

    The OID id-mime-bp-data is added to the Encoded
    Information Types of the envelope.

    This body part is completely compatible with RFC 1494.

    When converting back to a MIME body part, the gateway is
    responsible for:

Alvestrand                Exp Nov 96                 [Page 16]

draft               X.400/MIME body 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

     (3)   Removing any content-type field that is left in the
           RFC822FieldList of the message that is redundant or
           conflicting with the one from the mime-body-part

     (4)   Make sure that on multipart messages, the boundary
           string actually used is reflected in the boundary=
           parameter of the content-type header, and does not
           occur within the body of the message.

    3.1.3.  Encapsulation using IA5 (HARPOON)

    This approach is the one taken in RFC 1496 - HARPOON - for
    tunneling any MIME body part through X.400/84 networks. It
    has proven rather unhelpful for bringing information to
    X.400 users, but preserves all the information of a MIME
    body part.

    The following IA5Text body part is made:

    -    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>
         <Here follows the bytes of the content, encoded
         in the proper encoding>

Alvestrand                Exp Nov 96                 [Page 17]

draft               X.400/MIME body mapping             May 96

    All implementations MUST place the MIME-version: header
    first in the body part. Headers that are placed by [MIXER]
    into other parts of the message MUST NOT be placed in the
    MIME body part.

    3.1.4.  Content passing using BP14

    This is described in this section because it is at the
    same conceptual level as encapsulation. It is a lossy
    transformation; it is impossible to reconstruct the MIME
    type information from it.

    Nevertheless, there is a demand for such functionality.

    This "encapsulation" simply strips off all headers, undoes
    the content-transfer-encoding, and creates a
    BilaterallyDefined body part (BP14) from 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 to map X.400
    body parts to a MIME content.  This allows for the body
    part to be tunneled through MIME.   It may also be used
    directly by an appropriately configured MIME UA.

    This content-type is defined to carry any X.400 extended
    body part.  The mapping of all standard X.400 body parts
    is defined in RFC1494bis.  The content-type field is
    "application/x400-bp".  The parameter is defined by the

            mime-parameter =  "bp-type=" object-identifier

    The EBNF.object-identifier is set to the OBJECT IDENTIFIER
    from IPMS.body.externally-defined.data.direct-reference.

    For example, a Videotex body part will have

Alvestrand                Exp Nov 96                 [Page 18]

draft               X.400/MIME body mapping             May 96

            Content-type=application/x400-bp; bp-type=

    The body contains the raw ASN.1 IPM body octet stream,
    that is, the BER encoding of the IPM.Body.BodyPart,
    including 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 the one which gives the more compact encoding of
    the data.  If this cannot be determined, Base64 is
    recommended.  No attempt is made to turn the parameters of
    Extended Body Parts into MIME parameters, as this cannot
    be done in a general manner.

    Standard X.400 body parts may not be encoded directly by
    this mechanism, but may be encoded indirectly by first
    translating to the extended representation.

    NOTE: RFC 1494 defined a bp-type=<integer> for encoding
    standard X.400 body parts. If such body parts are
    encountered, RFC 1494 section 6.1 should be consulted.

    3.3.  Encapsulating FTBP body parts in MIME

    The File Transfer Body Part is believed to be important in
    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
    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

    Otherwise, it can be encapsulated in MIME by:

Alvestrand                Exp Nov 96                 [Page 19]

draft               X.400/MIME body mapping             May 96

    -    Creating the "content-type" value by forming the
         string "application/x-ftbp." and appending the
         numbers of the OID

    -    Mapping all other parameters according to the
         standard FTBP parameter mapping

    -    Applying an appropriate content-transfer-encoding


    The choice of the somewhat strange, and by necessity
    unregistered, MIME type "application/x-ftbp.n.n.n.n" is
    because for any concrete example of this usage, it will be
    easy to configure any MIME reader to take advantage of the
    identification. If the MIME type registration rules are
    ever changed to allow the registration of a namespace,
    rather than just of names, the "x-" can be deleted, and
    the 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 particular body

    To allow an escape clause, this chapter defines a way in
    which the user can signal the gateway what action it finds
    most appropriate.

    The headers given here override any "conversion
    prohibited" and "conversion with loss prohibited" on the

    It is still the gateway's responsibility that the
    generated messages conform to the destination domain's
    syntax rules.


    The intent of this mechanism is to allow the sender to
    efficiently get a message through to a single recipient

Alvestrand                Exp Nov 96                 [Page 20]

draft               X.400/MIME body mapping             May 96

    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 to X.400

    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 ]
                    "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.


    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

Alvestrand                Exp Nov 96                 [Page 21]

draft               X.400/MIME body mapping             May 96

    This leads to a Body Part 14 encoding for all body parts of type

    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.

    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

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 be present in the
    heading of a message. It defines the mapping for all body
    parts of the specified types, including those in nested

    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.

    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

Alvestrand                Exp Nov 96                 [Page 23]

draft               X.400/MIME body mapping             May 96

     (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

     (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

Alvestrand                Exp Nov 96                 [Page 24]

draft               X.400/MIME body mapping             May 96

     (2)   Object Identifier for the FTAM Contents-type, if
           unstructured-binary is not used

     (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. Specific
    conformance requirements for MIXER are given at the end of
    this document.

    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

    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

Alvestrand                Exp Nov 96                 [Page 25]

draft               X.400/MIME body mapping             May 96

         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.

    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
    -----------------          ------------------          -------
      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
    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:

                 TYPE NOTATION  ::= Parameters Data

                 Parameters     ::=  "PARAMETERS" type "IDENTIFIED"
                                     "BY" value(OBJECT IDENTIFIER)
                                   | empty;
                 Data           ::= "DATA" type

    To meet these requirements, this document uses the OID


    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:

       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 OIDs as root OIDs for any new MIME 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):

      {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

    Unfortunately, some implementations have chosen to use the
    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 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 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
    Conversion Type: No conversion

    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, "Transition of Internet Mail from 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.

    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

    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 in the above table,
    and then appending it to the id-cs-eit-authority {1 0
    10021 7 1 0} OID.

    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.


    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 changes, such as normalizing escape sequences, should

Alvestrand                Exp Nov 96                 [Page 32]

draft               X.400/MIME body mapping             May 96

    not be done when "conversion-prohibited" is set. If
    "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 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.
    The rules for ISO-2022-JP are given in RFC 1468, 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 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


    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

    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 -

    X.400 Body Part: FTBP EMA Unknown Attachment
    MIME Content-Type: Application/Octet-Stream
    Conversion Type: No conversion

    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. 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. 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
         is generated from this parameter. Note that RFC 1521
         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.

    The body mapping is just copying the bytes in both

    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

    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,
    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

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:

         "Multipart Message"

         "Alternative Body Parts containing the same

         "Message Digest"

         "Body Parts interpreted in parallel"

         "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
    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

            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.

         When downgrading to X.400/84, the content-type SHOULD
         be regenerated from this heading-extension and put
         into the RFC-822-HEADERS extra body part.

    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

    The character set shall be "Teletex", which is especially
    registered for this purpose. Its definition is shown in an

    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.


    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

    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.

    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


    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

     (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

     (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: 1.0 (generated by gateway)" at the beginning of
    the body part. (The part in parentheses can be changed at

    This will:

     (1)   Maximize the chance that the user will see the

     (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.

    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

    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.


    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.


    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.

    -    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.


    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                 [Page 42]

draft               X.400/MIME body mapping             May 96

    -    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

    -    Encapsulation of MIME content in the FTBP body part

    -    Encapsulation of X.400 body parts in the x400-bp body

    -    Encapsulation of FTBP body parts in the
         application/x-oid.n.n.n 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

    9.  Security 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

    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

    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

    Harald Tveit Alvestrand
    P.O.box 6883 Elgeseter
    N-7002 Trondheim


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,

    and many others who have been active over the long
    lifetime of this document.


         D.H. Crocker, Standard for the Format of ARPA
         Internet Text Messages.  Request for Comments 822,
         (August, 1982).

         N. Borenstein, N. Freed, MIME: Mechanisms for
         Specifying and Describing the Format of Internet
         Message Bodies.  Request for Comments 1521, (June,

         S.E. Kille, Mapping between X.400(1988) / ISO 10021
         and RFC-822. (in preparation)

         CCITT Recommendation T.4, Standardization of Group 3
         Facsimile Apparatus for Document Transmission (1988)

         CCITT Recommendation T.30, Procedures For Document
         Facsimile Transmission in the General Switched
         Telephone Network (1988)

         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

         ISO/IEC International Standard 10021, Information
         technology - Text Communication - Message-Oriented
         Text Interchange Systems (MOTIS) (Parts 1 to 8)

         CCITT, Data Communication Networks - Message Handling
         Systems - Recommendations X.400 - X.420 (1988

         CCITT Recommendation X.420 (1988), Interpersonal
         Messaging System

         Harald Tveit Alvestrand, X.400 use of extended
         Character Sets, Internet Draft, June 1992

         Electronic Messaging Association Message Attachment
         Working Group (MAWG): File Transfer Body Part
         Feasibility Project Guide - version 1.5 - September

         Dorner & Troost, The Content-Disposition header - RFC

         Harald Tveit Alvestrand, Carrying PostScript in X.400
         and MIME, Work In Progress (draft-ietf-mixer-

         Harald Tveit Alvestrand, X.400 image body parts, Work
         In Progress (draft-ietf-mixer-images-00.txt)

         Harald Tveit Alvestrand, A MIME body part for ODA,
         Work in Progress (draft-ietf-mixer-oda-00.txt)

Alvestrand                Exp Nov 96                 [Page 46]

draft               X.400/MIME body mapping             May 96


    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}
        {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]
        INCASE "ESC 2D", "ESC 29"
            g1 = chartoid[lastchar, next character]
        INCASE "ESC 2E", "ESC 2A"
            g2 = chartoid[lastchar, next character]
        INCASE "ESC 2F", "ESC 2B"
            g3 = chartoid[lastchar, next character]
        {control characters. There is missing code for changing these}
        INCASE 00/00-01/15 {normal control}
        INCASE 08/00-09/15 {upper control}
        {Normal characters}
        INCASE 02/00-07/15 (Left)
            IF (*leftset == lowset)
            ELSIF (*leftset == highset)
                ERROR "Shift error"
        INCASE 10/00-15/15
            IF (*rightset == highset)
            ELSIF (*rightset == lowset)
                ERROR "Shift error"

    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)
                ERROR "Too many charsets encountered"


    Appendix B: OID Assignments
    EXPORTS -- everything --;

           FROM RFC1155-SMI;
       mixer -- { iso(1) org(3) dod(6) internet(1) mail(7) mixer(1) }
           FROM MIXER --Companion RFC--;

    mixer-bp-data OBJECT IDENTIFIER ::=
            { mixer 1 };

    mixer-bp-parameter OBJECT IDENTIFIER ::=
            { mixer 2 };

    -- mixer-core is defined as { mixer core(3) } in [MIXER]
    mixer-bp-heading OBJECT IDENTIFIER ::=
            { mixer 4 }

    id-mime-bp-data OBJECT IDENTIFIER ::=
            { mixer-bp-data 1};

    id-mime-bp-parameters OBJECT IDENTIFIER ::=
            { mixer-bp-parameter 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

    id-mime-jpeg-body OBJECT IDENTIFIER ::=
                   { mixer-bp-data 3}

    id-mime-gif-body OBJECT IDENTIFIER ::=
                   { mixer-bp-data 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 }

Alvestrand                Exp Nov 96                 [Page 50]

draft               X.400/MIME body mapping             May 96

    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

    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

    The set of allowed character sets can be found in CCITT
    recommendation X.208(1988), chapter 31.2 and Table

    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.

    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.

    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                 [Page 52]

draft               X.400/MIME body mapping             May 96

    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

    - X.400 Object Identifier for Parameters:

    (If  left empty, an OID will be assigned by IANA under
    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 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. It may be defined by reference to RFCs).

    Person & email address to contact for further informa­

Alvestrand                Exp Nov 96                 [Page 53]

draft               X.400/MIME body mapping             May 96


    The  accepted registrations will be listed in the "As­
    signed 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 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 of FTBP elements generated ............   11
    2.4 Information that is lost when mapping ...........   12
    3 Encapsulation of body parts .......................   13
    3.1 Encapsulation of MIME 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 in MIME ..........   18
    3.3 Encapsulating FTBP body parts 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 to MIME ...................   23
    5 The equivalence registry ..........................   24
    5.1 What information one must give about a mapping
         ................................................   24
    5.2 Equivalence summary for known X.400  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 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

Alvestrand                Exp Nov 96                 [Page 55]