[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 rfc2157                                  
draft            X.400/MIME body equivalences          July 95


      Equivalences between X.400 and RFC-822 Message Bodies

                 Fri Sep 15 18:10:48 WET DST 1995


                     Harald Tveit Alvestrand
                             UNINETT
                  Harald.T.Alvestrand@uninett.no



    Status of this Memo



    The name of this draft is draft-ietf-mixer-bodymap-02.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 is an update to RFC 1494, and will obsolete
    it once it is ready for publication.

    Please send comments to the MIXER mailing list:
    <ietf-mixer@innosoft.com>








Alvestrand, Thompson      Exp Jan 96                  [Page 1]


draft            X.400/MIME body equivalences          July 95


    1.  Introduction

    This document is a companion to [MIXER], which defines the
    principles behind interworking between MIME-based RFC-822
    mail and X.400 mail. This document describes the content
    of the "IANA MHS/MIME Equivalence table" referenced in
    [MIXER], and defines the initial configuration of this
    table.  Mappings for new MIME content-types and/or X.400
    body part types should be registered with the IANA to
    minimize redundancy and promote interoperability.

    In addition, this document describes the basic functions
    used for manipulating multipart structures and tunneling
    body parts for which no exact equivalent exists.

    NOTE: In MIME, the term "content-type" is used to refer to
    an information object contained in  the body of a message.
    In contrast, X.400 uses the term "body part type."  In
    this document, the term "body part" is used to refer to
    either.






























Alvestrand, Thompson      Exp Jan 96                  [Page 2]


draft            X.400/MIME body equivalences          July 95


    1.1.  Philosophy of 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
    stuff that is not text around.
    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 an
           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 a message with bad typing
           information (like an X.400 BP14 or FTAM "just a
           file", it may apply heuristics like looking at
           content or looking at filenames to figure out how
           to deal with the message.

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

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

    The rest of this document will, in most instances,
    document the action that should be taken in the case where
    the gateway knows nothing more about the recipient than
    the fact that its next hop is Internet SMTP or X.400/88;
    in some cases, special actions that can be applied to





Alvestrand, Thompson      Exp Jan 96                  [Page 3]


draft            X.400/MIME body equivalences          July 95


    support other cases will be mentioned.



    1.2.  Describing an equivalence

    The following information MUST be supplied when describing
    an equivalence:

    MIME type name (which must be preregistered)

    X.400 body part (often BP15 or FTAM Body Part)

    If the BP15 is used, the following information must be
    given:


     (1)   X.400 Object Identifier for Data

     (2)   X.400 Object Identifier for Parameters

     (3)   X.400 ASN.1 Syntax (must be an EXTENDED-BODY-PART-
           TYPE macro)


    Conversion algorithm. If it fits within one of the
    categories listed under "Generic conversions", this should
    be referred; if not, 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.
















Alvestrand, Thompson      Exp Jan 96                  [Page 4]


draft            X.400/MIME body equivalences          July 95


    2.  Generic conversions

    2.1.  Byte copy

    This is the trivial case, that is, no conversion at all.
    The byte stream is simply copied between MIME and X.400.

    This is the preferred conversion, since it is the
    simplest.

    Implementors and vendors will be registering OBJECT
    IDENTIFIERs and MIME content-types for their various
    objects.  They are STRONGLY ENCOURAGED to specify their
    content formats such that a gateway can use Byte Copy to
    map between them.

    Note that in some cases, it is necessary to define exactly
    which ASN.1 construct to replace with the content of the
    MIME object.

    In this case, conversion can be performed even if
    "conversion prohibited" is set in the X.400 message.


    2.2.  Text Conversion

    This type of conversion applies to text objects that
    cannot be mapped using a simple Byte Copy.  Conversion
    involves scanning and reformatting the object.  For
    example, the MIME and X.400 objects might differ in their
    encoding of nonstandard characters, or line or page
    breaks.

    In this case, "conversion prohibited" will prohibit the
    conversion, while "conversion with loss prohibited" will
    not.


    2.3.  Image Conversion

    This conversion type applies to raster images, like Group
    3 Facsimile or JPEG.  Again, it differs from Byte Copy in
    that it involves scanning reformatting the byte stream.
    It differs from Text Conversion in that it is pixel-
    oriented, rather than character-oriented.





Alvestrand, Thompson      Exp Jan 96                  [Page 5]


draft            X.400/MIME body equivalences          July 95


    In this case, "conversion prohibited" will prohibit the
    conversion, while "conversion with loss prohibited" will
    not.















































Alvestrand, Thompson      Exp Jan 96                  [Page 6]


draft            X.400/MIME body equivalences          July 95


    3.  Equivalence Table for known X.400 and MIME Types

    This section itemizes the equivalences for all currently
    known MIME content-types and X.400 body parts.

    3.1.  Equivalence Table format

    For each MIME content-type/X.400 body part pair, the
    Equivalence Table will contain 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.


    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.


    3.2.  MIME to X.400 Table

    MIME content-type          X.400 Body Part             Section
    -----------------          ------------------          -------
    text/plain
      charset=3Dus-ascii         ia5-text                     7.1
      charset=3Diso-8859-x       EBP - GeneralText            7.2





Alvestrand, Thompson      Exp Jan 96                  [Page 7]


draft            X.400/MIME body equivalences          July 95


    text/richtext              no mapping defined           Tunnel
    application/oda            EBP - ODA                    7.4
    application/octet-stream   bilaterally-defined          7.3
    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           Tunnel
    video/mpeg                 no mapping defined           Tunnel
    message/rfc822             ForwardedIPMessage             n.n
    multipart/*                ForwardedIPMessage          n.n

    Abbreviation: EBP - Extended Body Part


    3.3.  X.400 to MIME Table
                             Basic Body Parts

    X.400 Basic Body Part      MIME content-type           Section
    ---------------------      --------------------        -------
    ia5-text                   text/plain;charset=3Dus-ascii 7.1
    voice                      No Mapping Defined          Tunnel
    g3-facsimile               image/g3fax                 [IMAGES]
    g4-class1                  no mapping defined          Tunnel
    teletex                    text/plain;charset=3Dteletex  n.n
    videotex                   no mapping defined          Tunnel
    encrypted                  no mapping defined          Tunnel
    bilaterally-defined        application/octet-stream    n.n
    nationally-defined         no mapping defined          Tunnel
    externally-defined         See Extended Body Parts below
    ForwardedIPMessage     message/rfc822 or multipart n.n

    X.400 Extended Body Part   MIME content-type              Section
    -------------------------  --------------------           -------
    GeneralText                text/plain;charset=3Diso-8859-x  7.2
    ODA                        application/oda                [ODA]
    mime-postscript-body       application/postscript         [POSTSCRIPT]
    mime-jpeg-body             image/jpeg                     [IMAGES]
    mime-gif-body              image/gif                      [IMAGES]











Alvestrand, Thompson      Exp Jan 96                  [Page 8]


draft            X.400/MIME body equivalences          July 95


    4.  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::=3D
              BEGIN
                 TYPE NOTATION  ::=3D Parameters Data
                 VALUE NOTATION ::=3D value (VALUE OBJECT IDENTIFIER)

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

    To meet these requirements, this document uses the OID

       mixer-bodies

    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 ::=3D
                       { mixer-bodies 1 }

       mixer-bp-parameter OBJECT IDENTIFIER ::=3D
                       { mixer-bodies 2 }


    All definitions of X.400 body parts submitted to the IANA
    for registration must use the Extended Body Part Type
    macro for the definition.  See the next section for an
    example.





Alvestrand, Thompson      Exp Jan 96                  [Page 9]


draft            X.400/MIME body equivalences          July 95


    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 ::=3D SEQUENCE {
         parameters [0] ExternallyDefinedParameters OPTIONAL,
         data           ExternallyDefinedData }

      ExternallyDefinedParameters ::=3D EXTERNAL

      ExternallyDefinedData ::=3D EXTERNAL

    The ASN.1 for EXTERNAL is (from X.208):

      EXTERNAL ::=3D [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 ::=3D [UNIVERSAL 7] IMPLICIT GraphicString

    There are a bit too many choices here; the common X.400
    usage 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, Thompson      Exp Jan 96                 [Page 10]


draft            X.400/MIME body equivalences          July 95


    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.



    5.  Ground rules for generating the IPM Body from MIME

    X.400 and MIME  define  extensible approaches for body
    parts, and the ability to map a specific body part depends
    on the gateway's knowledge.

    Where no mapping is known by the gateway, it may choose to
    drop the body part, or reject the message.   It may also
    encapsulate the body part in a mechanism which can be used
    for any extended X.400 body part.  This is specified
    below.  The option will depend on the gateway
    configuration and its knowledge of the recipient
    capabilities.


    If the header does not contain a 822.MIME-Version field,
    then generate a IPMS.Body with a single IPMS.BodyPart of
    type IPMS.IA5TextBodyPart with
    IPMS.IA5TextBodyPart.parameters.repertoire set to the
    default (ia5) containing the body of the RFC 822 message.

         If 822.MIME-Version is present, then the body part is
    analysed as a MIME message and the body is converted
    according to the Equivalence Table.


    6.  Ground rules for generating the MIME Body from the
    IPMS.Body


    First, to support X.400(1984) mappings of Internet
    Messages, the following procedure shall be followed.

    If there is more than one body part, and the first body
    part is IA5 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
    Appedix B of MIXER.  A gateway shall check the consistency





Alvestrand, Thompson      Exp Jan 96                 [Page 11]


draft            X.400/MIME body equivalences          July 95


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


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



     (2)   All other parts are mapped according to the
           Equivalence Table.


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



    6.1.  Information that is lost when mapping

    RFC 1494bis defines mappings onto Body Part 15.  Similar
    considerations apply to body parts 1-14.   MIME defines
    fields which add information to MIME contents.  Two of
    these are "Content-ID", and "Content-Description".   When
    mapping, this information must be discarded, unless the
    specific body part 15 mapping allows it to be retained.


    6.2.  Mapping the EMA FTBP parameters

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

    New mappings are expected to use this as the mechanism for
    carrying body parts, and since it is important to have a





Alvestrand, Thompson      Exp Jan 96                 [Page 12]


draft            X.400/MIME body equivalences          July 95


    consistent mapping for the special FTBP parameters, these
    are defined here.

    The mapping of the body will depend on the attachment
    being mapped, and so cannot be defined here.  The MIME
    headers are mapped as follows.


    6.2.1.  Parameter mapping MIME to X.400


    Content-ID:
         If this is present, create an element
         FTBP.FileTransferParameters.related-stored-file.
         file-identifier.cross-reference.message-reference and
         set it to the IPM.MessageIdentifier derived from the
         "Content-ID:".

         FTBP.FileTransferParameters.related-stored-file.
         relationship.descriptive-relationship is set to the
         string "Internet MIME Body Part".

         FTBP.FileTransferParameters.related-stored-file.
         file-identifier.cross-refernce.application-
         crossreference is set to a null OCTET STRING.


    Content-Description

         This is mapped to the first string in
         FTBP.FileTransferParameters.environment.user-visible-
         string.



    6.2.2.  Parameter mapping X.400 to MIME

    X.400 specifies a file transfer body part (FTBP).  Generic
    mapping of FTBP is beyond the scope of MIXER.   EMA have
    defined a profile of FTBP to carry attachments [28].
    MIXER defines a mapping of FTBP to MIME, which is intended
    for use in conjunction with this profile.   FTBP is used
    to carry various pieces of information associated with an
    attachment.  The key mapping will be to correctly convert
    the contents of the attachment.  This specification also





Alvestrand, Thompson      Exp Jan 96                 [Page 13]


draft            X.400/MIME body equivalences          July 95


    provides a mechanism for mapping the parameters which EMA
    have recommended to be used in version 1.4 of the
    specification.  A BNF is defined below:

    ftbp-field =3D "FTBP-Object-Size" ":" integer
               / "FTBP-Creation-Date" ":" date-time
               / "FTBP-Modification-Date" ":" date-time
                 "FTBP-Read-Date" ":" date-time

         Some parameters are encoded as graphical strings.  To
    map these to ASCII, those characters that map directly are
    mapped, and others are translated to "?".   This simple
    non-reversible mapping is seen as appropriate for the
    application, and in line with the spirit of the EMA
    profile.


    Editor's note
         Is the refusal to consider extended characters
         appropriate? Can RFC 1521 be used instead?

              Mapping of the data will be dependent on the
         attachment, its encoding, and the MIME
         representation.   These cannot be specified here.

              Other FTBP Parameters are mapped as follows:


    FileTransferParameters.environment.user-visible-string
         This is mapped to the "Content-Description:" header.


    The following elements of FileTransferParameters.file-
    attributes are mapped as follows:


    pathname
         Mapped to "Content-Dispostion:", as defined in RFC
         1806 [33].  The EBNF.disposition-type is set to
         "attachment", and the filename is included as a
         parameter.  For example:

                      Content-Disposition: attachment; filename=3D/var/joe=
/dodo.doc

         It is expected that only the incomplete option will





Alvestrand, Thompson      Exp Jan 96                 [Page 14]


draft            X.400/MIME body equivalences          July 95


         be found, but the mapping is used for either variant.
         The separator between multiple components is "/".


    date-and-time-of-creation
         Mapped to "FTBP-Creation-Date:".


    date-and-time-of-last-modification
         Mapped to "FTBP-Modification-Date:".


    date-and-time-of-last-read-access
         Mapped to "FTBP-Read-Date:".


    object-size
         Mapped to "FTBP-Object-Size:".


    6.3.  Encapsulation in X.400

    Where no mapping is possible, the gateway may choose to
    discard the body part or to reject the message.  This will
    depend on gateway policy, and configuration knowledge.
    Another option is to "tunnel" the body part, by
    encapsulating it in X.400.   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-body-part-parameters
          DATA            OCTET STRING
          ::=3D id-mime-body-part

    MimeParameters ::=3D
         SEQUENCE {
                     content-type       IA5String,
                     content-parameters SEQUENCE OF
                                        SEQUENCE {
                                            parameter          IA5String,
                                            parameter-value    IA5String
                                        }
                     other-header-fields RFC822FieldList





Alvestrand, Thompson      Exp Jan 96                 [Page 15]


draft            X.400/MIME body equivalences          July 95


                 }

    The OBJECT IDENTIFIERS id-mime-body-part and id-mime-body-
    part-parameters are defined in Appendix D.  A MIME content
    is mapped onto this body part.  The MIME headers of the
    body part are mapped as follows:


    Content-Type:
         The "type/subtype" string is mapped to
         MimeParameters.content-type.

         For each "parameter=3Dvalue" 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.


    Other
         Take all other headers and create
         MimeParameters.other-header-fields, by concatenating
         them together.


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

         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-body-part is added to the Encoded
    Information Types of the envelope.











Alvestrand, Thompson      Exp Jan 96                 [Page 16]


draft            X.400/MIME body equivalences          July 95


    6.4.  Tunnelling X.400 Body Parts

    This section specifies a generic mechanism to map X.400
    body parts to a MIME content.  This allows for the body
    part to be tunnelled 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 EBNF:

            mime-parameter =3D  "bp-type=3D" 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

            Content-type=3Dapplication/x400-bp; bp-type=3D2.6.1.4.5

         The body contains the raw ASN.1 IPM.body octet
    stream, 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.


    7.  The Equivalence Table


    7.1.  IA5Text - text/plain

    X.400 Body Part: IA5Text
    MIME Content-type: text/plain; charset=3DUS-ASCII





Alvestrand, Thompson      Exp Jan 96                 [Page 17]


draft            X.400/MIME body equivalences          July 95


    Conversion Type: Byte copy
    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, "Transition of Internet Mail from just-
    send-8 to 8-bit SMTP/MIME", and generate appropriate
    charset parameters for the MIME messages they generate.
    This behaviour is not required for MIXER conformance,
    since it is only needed when the base standards are
    violated.


    7.2.  GeneralText - text/plain (ISO-8859)

    X.400 Body Part: GeneralText; CharacterSets in
                            6,100,101,109,110,126,127,138,144,148
    MIME Content-Type: text/plain; charset=3DISO-8859-(1-9)
    Conversion Type: Text conversion without character change
    Comments:






Alvestrand, Thompson      Exp Jan 96                 [Page 18]


draft            X.400/MIME body equivalences          July 95


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

    The changes, such as normalizing escape sequences, should
    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 nondelivered
    with an appropriate nondelivery reason.

    When mapping from X.400 to MIME, the character-set is
    chosen from 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
    may be encoded as x-iso-nnn-nnn-nnn, where "nnn" is the
    numbers of the Parameters.CharacterSets, sorted in numeric
    order.

    Editor's note
         This is a new idea. It gives you a fallback for all
         cases, but is it useful?

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





Alvestrand, Thompson      Exp Jan 96                 [Page 19]


draft            X.400/MIME body equivalences          July 95


         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.


    Editor's note
         I would like to have an appendix of 30 or so lines of
         C code that do this state machine walk. Does anyone
         have code lying around? (If it is 200 lines, it is
         too much to include...)

         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.

         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 ASCI=
I"
         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 languag=
es
         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





Alvestrand, Thompson      Exp Jan 96                 [Page 20]


draft            X.400/MIME body equivalences          July 95


         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.


    Editor note
         We need to describe the complete string for at least
         one example of this.



    7.3.  BilaterallyDefined - application/octet-stream

    X.400 Body Part: BilaterallyDefined
    MIME Content-Type: Application/Octet-Stream (no parameters)
    Conversion Type: Byte copy
    Comments:

    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
         advisory; name and conversions are depreciated in RFC
         1521.

         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 nondeliver
         the body part. The "padding" parameter is rarely used
         with MIME.


    Editor note:
         Is it better to recommend using FTBP with a bit-
         oriented encoding when the "padding" parameter is
         encountered? Do we care?







Alvestrand, Thompson      Exp Jan 96                 [Page 21]


draft            X.400/MIME body equivalences          July 95


    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.  1992 X.400 defines a File
    Transfer Body Part to solve this problem (i.e. binary file
    transfer through email). The standard and its regional
    profiles are not solid enough yet to exploit as a solution
    for this problem.


    7.4.  FTBP EMA Unknown Attachment -
    application/octet-stream
    X.400 Body Part: FTBP EMA Unknown Attachment
    MIME Content-Type: Application/Octet-Stream
    Conversion Type: Byte copy
    NOTE: At the time of this writing (Sept 1995), support for
    BilaterallyDefined is MUCH more widespead than support for
    the FTBP body part, and definitely more widespread than
    support for the EMA FTBP Unknown Attachment. Gateways
    should only choose to generate this body part from
    Application/OctetStream when it is believed that the
    recipient is able to handle this body part.

    The OID for the Unknown Attachment is { 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 for short.

    The parameters for this type must be mapped according to
    chapter <<<n>>>, with the following extensions for the
    parameters of the application/octet-stream:

     (1)   If there is no Content-Disposition parameter with a
           filename, and there is a name parameter, the
           FTBP.FileTransferParameters.File-
           attributes.pathname 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" are discouraged in RFC 1521.

    Editor note:
         Does there exist a bit-aligned storage to be used





Alvestrand, Thompson      Exp Jan 96                 [Page 22]


draft            X.400/MIME body equivalences          July 95


         when the "padding" parameter is present? This is not
         recommended by EMA; do we want to have it?
         Should the "type" parameter be mapped into the FTBP
         FileTransferParameters.Environment.UserVisibleString?
         It seems to be more or less the same kind of thing,
         according to EMA.

    The body mapping is just copying the bytes in both
    directions.


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

    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.


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





Alvestrand, Thompson      Exp Jan 96                 [Page 23]


draft            X.400/MIME body equivalences          July 95


    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 and is either multipart/digest or multipart/mixed,
    elements of the multipart are mapped directly onto IPMS.BodyPart.
    In other cases, a MIME multipart 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:

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

            MultipartType ::=3D SEQUENCE {





Alvestrand, Thompson      Exp Jan 96                 [Page 24]


draft            X.400/MIME body equivalences          July 95


                      subtype IA5String,
                isAMessage BOOLEAN DEFAULT TRUE }

    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.


    7.7.  ia5 <- message/external-body

    X.400 body part: ia5 MIME Content-Type: message/external-
    body Conversion Type: Special

    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.

    To support the second case above, the tunneling method





Alvestrand, Thompson      Exp Jan 96                 [Page 25]


draft            X.400/MIME body equivalences          July 95


    chosen is to represent the body part as 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 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 (in a fashion compatible with
           RFC 1496, HARPOON) as a MIME object in a reliable
           fashion, allowing UAs to support the fetching of
           the object if the UA implementor desires.


    The gateway MAY support a configuration option to
    retrieve; it MUST support the tunneling in IA5 when
    retrieval is not desired or not possible.


    This points to an external body part.  As this will not in
    general be accessible to the X.400 recipient, the body
    part shall be resolved at the gateway, unless it is
    already included in a multipart/alternative or the
    recipient UA is known to be capable of handling a
    message/external tunnelled body part.  The gateway shall
    obtain the body part and then map it as if it had been
    included.   If the expiration date of the external body
    part has expired, the gateway may tunnel the body part.


    Editor's Note:
         There has been comment that this dereference should
         be made more optional or the text changed in some
         way.  Input is solicited.










Alvestrand, Thompson      Exp Jan 96                 [Page 26]


draft            X.400/MIME body equivalences          July 95


    7.8.  ??? - message/partial

    Editor's note: This specification seems incomplete, since
    it does not specify what to do with the content of the
    body part. Input solicited!

    The following heading extension is added, derived from the
    message/partial parameters, in order to facilitate MIME
    capable X.400 UAs to handle messages of this type:

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

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



    7.9.  ???? - multipart/appledouble

    A specific mapping for multipart/appledouble is defined.
    Noting that the fileTransferData component of an FTBP is a
    SEQUENCE of EXTERNAL, the file data component of the
    multipart is mapped onto the first of two elements of the
    SEQUENCE, and the application/applefile component (the
    finder and resource info) is mapped onto the second
    element of the sequence.  Applications which don't care
    about the finder and resource info can, therefore, simply
    ignore the second element and extract the data from the
    first element.  The direct reference component of the
    first element is set to reflect the original type/subtype
    of the MIME data component, according the OID's defined in
    RFC1494bis.

    Editor's Note:
         This specification is clearly useful and needed.
    Does it
         belong in MIXER?   Comments solicited.







Alvestrand, Thompson      Exp Jan 96                 [Page 27]


draft            X.400/MIME body equivalences          July 95


    7.10.  Teletex - Text/Plain (Teletex)
    X.400 Body Part: Teletex
    MIME Content-Type: text/plain; charset=3DTeletex
    Conversion Type: Text conversion
    Comments:

    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.

    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.

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





Alvestrand, Thompson      Exp Jan 96                 [Page 28]


draft            X.400/MIME body equivalences          July 95


    boundary, if possible, but will give a much greater chance
    that the MIME recipient can actually read the message.
















































Alvestrand, Thompson      Exp Jan 96                 [Page 29]


draft            X.400/MIME body equivalences          July 95


    8.  OID Assignments
    MIXER-MAPPINGS DEFINITIONS ::=3D BEGIN
    EXPORTS -- everything --;

    IMPORTS
       experimental
           FROM RFC1155-SMI;
       mixer
           FROM MIXER --Companion RFC--;

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

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

    mime-generic-data OBJECT IDENTIFIER ::=3D
            { mixer-bp-data 1};

    mime-generic-parameters OBJECT IDENTIFIER ::=3D
            { mixer-bp-parameter 1};





























Alvestrand, Thompson      Exp Jan 96                 [Page 30]


draft            X.400/MIME body equivalences          July 95


    9.  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 nonspacing 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 datatype 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):

    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]





Alvestrand, Thompson      Exp Jan 96                 [Page 31]


draft            X.400/MIME body equivalences          July 95


       Character coded control functions for telematic services
       Note - C: 26/48/69

    (The author has not yet obtained a copy of these, even
    though they only cost SFR 70 from the ITU...)

    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.


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

    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.  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 reference to
    a Basic body part type)

    Conversion algorithm:

    (must be defined completely enough for independent





Alvestrand, Thompson      Exp Jan 96                 [Page 32]


draft            X.400/MIME body equivalences          July 95


    implementation. It may be defined by reference to RFCs).

    Person & email address to contact for further information:

    INFORMATION TO THE SUBMITTER:

    The accepted registrations will be listed in the "Assigned
    Numbers" series of RFCs.  The information in the
    registration form is freely distributable.


    11.  Changes from RFC 1494

    The following changes have been made since the publication
    of RFC 1494:

     (1)   The Teletex body part mapping was added

     (2)   The G3Fax body part had the order of bits in its
           body defined. It turned out that 2 implementations
           had done this in opposite directions. This has been
           moved to a separate, Experimental document.

     (3)   All but the essential translations were moved to
           separate documents.

     (4)   Description of tunneling, multipart and FTBP
           parameters were moved here from MIXER.

    12.  References

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

    [MIME]
         N. Borenstein, N. Freed, MIME: Mechanisms for
         Specifying and Describing the Format of Internet
         Message Bodies.  Request for Comments 1341, (June,
         1992).

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





Alvestrand, Thompson      Exp Jan 96                 [Page 33]


draft            X.400/MIME body equivalences          July 95


    [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

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

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

    [RFC-X400USE]
         Harald Tveit Alvestrand, X.400 use of extended
         Character Sets, Internet Draft, June 1992



















Alvestrand, Thompson      Exp Jan 96                 [Page 34]


draft            X.400/MIME body equivalences          July 95


    Table of Contents


     Status of this Memo ................................    1
    1 Introduction ......................................    2
    1.1 Philosophy of body part conversion ..............    3
    1.2 Describing an equivalence .......................    4
    2 Generic conversions ...............................    5
    2.1 Byte copy .......................................    5
    2.2 Text Conversion .................................    5
    2.3 Image Conversion ................................    5
    3 Equivalence Table for known X.400 and MIME Types
         ................................................    7
    3.1 Equivalence Table format ........................    7
    3.2 MIME to X.400 Table .............................    7
    3.3 X.400 to MIME Table .............................    8
    4 Use of OBJECT IDENTIFIERs and ASN.1 MACROS ........    9
    5  Ground  rules  for generating the IPM Body from
         MIME ...........................................   11
    6 Ground rules for generating the MIME  Body  from
         the IPMS.Body ..................................   11
    6.1 Information that is lost when mapping ...........   12
    6.2 Mapping the EMA FTBP parameters .................   12
    6.2.1 Parameter mapping MIME to X.400 ...............   13
    6.2.2 Parameter mapping X.400 to MIME ...............   13
    6.3 Encapsulation in X.400 ..........................   15
    6.4 Tunnelling X.400 Body Parts .....................   17
    7 The Equivalence Table .............................   17
    7.1 IA5Text - text/plain ............................   17
    7.2 GeneralText - text/plain (ISO-8859) .............   18
    7.3  BilaterallyDefined - application/octet-stream
         ................................................   21
    7.4  FTBP  EMA  Unknown  Attachment   -   applica=AD
         tion/octet-stream ..............................   22
    7.5 MessageBodyPart - message/rfc822 ................   23
    7.6 MessageBodyPart - multipart/* ...................   23
    7.7 ia5 <- message/external-body ....................   25
    7.8 ??? - message/partial ...........................   27
    7.9 ???? - multipart/appledouble ....................   27
    7.10 Teletex - Text/Plain (Teletex) .................   28
    8 OID Assignments ...................................   30
    9 Registration information for the Teletex charac=AD
         ter set ........................................   31
    10 IANA Registration form for new mappings ..........   32
    11 Changes from RFC 1494 ............................   33





Alvestrand, Thompson      Exp Jan 96                 [Page 35]


draft            X.400/MIME body equivalences          July 95


    12 References .......................................   33

















































Alvestrand, Thompson      Exp Jan 96                 [Page 36]