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

Versions: 00 01 02 03 04 05 06 rfc2157                                  
    Equivalences between 1988 X.400 and RFC-822 Message Bodies

                 Tue May 16 13:42:18 MET DST 1995

                     Harald Tveit Alvestrand

                        Steven J. Thompson
                        Soft*Switch, Inc.

    Status of this Memo

    The name of this draft is draft-ietf-mixer-bodymap-01.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.

draft            X.400/MIME body equivalences          July 95

    Please send comments to the MIXER mailing list:

Alvestrand, Thompson      Exp Jan 96                  [Page 2]

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 the
    companion document, 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 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

Alvestrand, Thompson      Exp Jan 96                  [Page 3]

draft            X.400/MIME body equivalences          July 95

    2.  Equivalence Table Definition

    For each MIME content-type/X.400 body part pair, the
    Equivalence Table will contain 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
         governed by this Table entry.  The MIME content-type
         named here must be registered with the IANA.

    Conversion Type
         This section identifies the type of conversion
         applied.  See the section on Generic Conversions for
         an explanation of the possible values.

    Comments (optional)
         This section gives any additional commentary that
         might be useful in understanding the mapping between
         the X.400 and MIME representations.

    The initial Equivalence Table entries in this document are
    described using this convention.  Any future submissions
    to the IANA should follow this format.

Alvestrand, Thompson      Exp Jan 96                  [Page 4]

draft            X.400/MIME body equivalences          July 95

    3.  Generic conversions

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

    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.

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

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

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

Alvestrand, Thompson      Exp Jan 96                  [Page 5]

draft            X.400/MIME body equivalences          July 95

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

    4.1.  MIME to X.400 Table

    MIME content-type          X.400 Body Part             Section
    -----------------          ------------------          -------
      charset=3Dus-ascii         ia5-text                     7.1
      charset=3Diso-8859-x       EBP - GeneralText            7.2
    text/richtext              no mapping defined           MIXER
    application/oda            EBP - ODA                    7.4
    application/octet-stream   bilaterally-defined          7.3
    application/postscript     EBP - mime-postscript-body   5.4, 7.6
    image/g3fax                g3-facsimile                 6.2, 7.5
    image/jpeg                 EBP - mime-jpeg-body         5.5, 7.7
    image/gif                  EBP - mime-gif-body          5.6, 7.8
    audio/basic                no mapping defined           MIXER
    video/mpeg                 no mapping defined           MIXER
    message/rfc822             ForwardedIPMessage             MIXER

    Abbreviation: EBP - Extended Body Part

    4.2.  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          MIXER
    g3-facsimile               image/g3fax                 6.2, 7.5
    g4-class1                  no mapping defined          MIXER
    teletex                    no mapping defined          MIXER
    videotex                   no mapping defined          MIXER
    encrypted                  no mapping defined          MIXER
    bilaterally-defined        application/octet-stream    7.3
    nationally-defined         no mapping defined          MIXER
    externally-defined         See Extended Body Parts below
    ForwardedIPMessage     message/rfc822 or multi     MIXER

    X.400 Extended Body Part   MIME content-type              Section

Alvestrand, Thompson      Exp Jan 96                  [Page 6]

draft            X.400/MIME body equivalences          July 95

    -------------------------  --------------------           -------
    GeneralText                text/plain;charset=3Diso-8859-x  7.2
    ODA                        application/oda                7.4
    mime-postscript-body       application/postscript         5.3, 7.6
    mime-jpeg-body             image/jpeg                     5.4, 7.7
    mime-gif-body              image/gif                      5.5, 7.8

Alvestrand, Thompson      Exp Jan 96                  [Page 7]

draft            X.400/MIME body equivalences          July 95

    In all cases where "MIXER" is named in the third column,
    the fallback conversion described in [MIXER] is applied.
    This conversion is not a "conversion" as defined in X.400,
    so will be allowed no matter what is forbidden in the
    X.400 per message flags.

    5.  Newly defined X.400 Body Parts

    This section defines new X.400 Body Parts for the purposes
    of interworking with MIME.

    All new X.400 Body Parts defined here will be Extended
    Body Parts, as defined in CCITT Recommendation X.420

    5.1.  Use of OBJECT IDENTIFIERs and ASN.1 MACROS

    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  ::=3D Parameters Data

                 Parameters     ::=3D  "PARAMETERS" type "IDENTIFIED"
                                     "BY" value(OBJECT IDENTIFIER)
                                   | empty;
                 Data           ::=3D "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

Alvestrand, Thompson      Exp Jan 96                  [Page 8]

draft            X.400/MIME body equivalences          July 95

    Parameters, each being named by an OID.  To this end, two
    OID subtrees are defined under mime-mhs-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

    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.

    5.2.  The PostScript body part

    The following Extended Body Part is defined for PostScript
    data streams.  It has no parameters.

      postscript-body-part EXTENDED-BODY-PART-TYPE
        DATA             OCTET STRING
        ::=3D mime-postscript-body

      mime-postscript-body OBJECT IDENTIFIER ::=3D
                { mixer-bp-data 2 }

    5.3.  The JPEG body part

    The following Extended Body Part is defined for JPEG data
    streams.  It has no parameters.

       jpeg-body-part EXTENDED-BODY-PART-TYPE
         DATA            OCTET STRING
         ::=3D mime-jpeg-body

Alvestrand, Thompson      Exp Jan 96                  [Page 9]

draft            X.400/MIME body equivalences          July 95

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

    5.4.  The GIF body part

    The following Extended Body Part is defined for GIF data
    streams.  It has no parameters.

       gif-body-part EXTENDED-BODY-PART-TYPE
         DATA            OCTET STRING
         ::=3D mime-gif-body

       mime-gif-body OBJECT IDENTIFIER ::=3D
               { mixer-bp-data 4 }

Alvestrand, Thompson      Exp Jan 96                 [Page 10]

draft            X.400/MIME body equivalences          July 95

    6.  Newly defined MIME content-types

    This section defines new MIME content-types for the
    purposes of interworking with X.400.

    6.1.  The image/g3fax content-type

    This content-type is defined to carry G3 Facsimile byte

    In general, a G3Fax image contains 3 pieces of

     (1)   A set of flags indicating the particular coding
           scheme.  CCITT Recommendation T.30 defines how the
           flags are transmitted over telephones.  In this
           medium, the flags are carried as parameters in the
           MIME content-type header field.

     (2)   A structure that divides the bits into pages.
           CCITT recommendation T.4 describes a "return to
           command mode" string; this is used here to indicate
           page breaks.

     (3)   For each page, a sequence of bits that form the
           encoding of the image.  CCITT recommendation T.4
           defines the bit image format.  This is used without
           change.  The highest bit of the first byte is the
           first bit of the T.4 bitstream.

    6.1.1.  G3Fax Parameters

    The following parameters are defined:

     (1)   page-length - possible values: A4, B4 and Unlimited

     (2)   page-width - possible values: A3, A4, B4

     (3)   encoding - possible values: 1-dimensional,
           2-dimensional, Uncompressed

     (4)   resolution - possible values: Fine, Coarse

Alvestrand, Thompson      Exp Jan 96                 [Page 11]

draft            X.400/MIME body equivalences          July 95

     (5)   DCS - a bit string, represented in Base64.

     (6)   pages - an integer, giving the number of pages in
           the document

    If nothing is specified, the default parameter settings


    It is possible (but misleading) to view the representation
    of these values as single-bit flags. They correspond to
    the following bits of the T.30 control string and X.400

    Parameter               T.30 bit        X.400 bit

    page-length=3DA4             no bit set
    page-length=3DB4          19              21
    page-length=3DUnlimited   20              20

    page-width=3DA4              no bit set
    page-width=3DA3           18              22
    page-width=3DB4           17              23

    encoding=3D1-dimensional     no bit set
    encoding=3D2-dimensional  16              8
    encoding=3DUncompressed   26              30

    resolution=3DCoarse          no bit set
    resolution=3DFine         15              9

    The reason for the different bit numbers is that X.400
    counts bits in an octet from the MSB down to the LSB,
    while T.30 uses the opposite numbering scheme.

    If any bit but these are set in the Device Control String,
    the DCS parameter should be supplied.

Alvestrand, Thompson      Exp Jan 96                 [Page 12]

draft            X.400/MIME body equivalences          July 95

    6.1.2.  Content Encoding

    X.400 defines the g3-facsimile data stream as a SEQUENCE
    of BIT STRINGs. Each BIT STRING is a page of facsimile
    image data, encoded as defined by Recommendation T.4.  The
    following content encoding is reversible between MIME and
    X.400 and ensures that page breaks are honored in the MIME

    An EOL is defined as a bit sequence of

       000000000001 (eleven zeroes and a one).

    Each page of the message is delimited by a sequence of six
    (6) EOLs that MUST start on a byte boundary.  The image
    bit stream is padded with zeroes as needed to achieve this

    Searching for the boundary is a matter of searching for
    the byte sequence (HEX) 00 10 01 00 10 01 00 10 01, which
    cannot occur inside the image.

    See Section 7.5 for the algorithm on conversion between
    this encoding and the X.400 encoding.

    The Base64 content-transfer-encoding is appropriate for
    carrying this content-type.

    6.2.  The Application/ODA content-type

    The "ODA" subtype of application is used to indicate that
    a body  contains  information  encoded according to the
    Office Document  Architecture  [ODA]   standards,  using
    the  ODIF representation  format.   For  application/oda,
    the Content- Type line should also specify an
    attribute/value  pair  that indicates  the document
    application profile (DAP), using the key word "profile",
    and the document class, using the keyword "class".

    For the keyword "class", the values "formatted",
    "processable" and "formatted-processable" are legal

Alvestrand, Thompson      Exp Jan 96                 [Page 13]

draft            X.400/MIME body equivalences          July 95

    Thus an appropriate header field  might look like this:

    Content-Type:  application/oda; profile=3DQ112;

    Consult the ODA standard [ODA] for further information.

    The Base64 content-transfer-encoding is appropriate for
    carrying ODA.

    7.  Equivalence Definitions

    7.1.  IA5Text - text/plain

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

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

Alvestrand, Thompson      Exp Jan 96                 [Page 14]

draft            X.400/MIME body equivalences          July 95

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

    X.400 Body Part: GeneralText; CharacterSets in
    MIME Content-Type: text/plain; charset=3DISO-8859-(1-9)
    Conversion Type: Byte copy

    When mapping from X.400 to MIME, the character-set chosen
    from table below according to the value of

    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"

    NOTE: The GeneralText body part is defined in ISO 10021-8
    [MOTIS], and NOT in the corresponding CCITT
    recommendation. Its parameters were heavily modified in a
    defect report, and will be a SET OF INTEGER (indicating
    the ISO registry numbers of all the used sets) in the next
    version of the standard.

    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, Thompson      Exp Jan 96                 [Page 15]

draft            X.400/MIME body equivalences          July 95

    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.

    7.3.  BilaterallyDefined - application/octet-stream

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

    When mapping from MIME to X.400, if there are parameters
    present in the Content-Type: header field, the conversion
    fails since the BilaterallyDefined Body Part does not have
    any corresponding ASN.1 parameters.

    DISCUSSION: The parameters "name" "type" and "conversions"
    are advisory, but may in some cases give vital hints on
    the expected handling of the file. The parameter
    "conversions" is not fully defined, but it is expected
    that it will be useful, so we cannot drop it and expect
    people to be satisfied.

    The parameter "padding" changes the interpretation of the
    last byte of the data, and so cannot be deleted.

    An option is to prepend an IA5 body part that contains the
    parameter text; this will aid unmodified readers, and can
    probably be made reversible with suitable chicanery, but
    is it worth it????

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

Alvestrand, Thompson      Exp Jan 96                 [Page 16]

draft            X.400/MIME body equivalences          July 95

    7.4.  ODA - application/oda

    X.400 Body Part: ODA
    MIME Content-Type: application/oda
    Conversion Type: Byte copy

    The ODA body part is defined in the CCITT document T.411
    [T.411], appendix E, section E.2, "ODA identification in
    the P2 protocol of MHS"

    An abbreviated version of its ASN.1 definition is:

    oda-body-part EXTENDED-BODY-PART-TYPE
            PARAMETERS      OdaBodyPartParameters
            DATA            OdaData
            ::=3D id-et-oda

    OdaBodyPartParameters ::=3D SET {
            document-application-profile    [0] OBJECT IDENTIFIER
            document-architecture-class     [1] INTEGER {
                                            formatted (0)
                                            processable (1)

    id-et-oda OBJECT IDENTIFIER ::=3D { 2 8 1 0 1 }

    Mapping from X.400 to MIME, the following is done:

    The Parameters.document-application-profile is mapped onto
    the MIME parameter "profile" according to the table below.

    Profile         OBJECT IDENTIFIER

    Q112            { iso (1) identified-organization (3) ewos (16)
                      eg (2) oda (6) profile (0)  q112 (1) }

    The Parameters.document-architecture-class is mapped onto
    the MIME parameter "class" according to the table below

    String                  Integer

    formatted               formatted(0)
    processable             processable(1)

Alvestrand, Thompson      Exp Jan 96                 [Page 17]

draft            X.400/MIME body equivalences          July 95

    formatted-processable   formatted-processable(2)

    NOTE: This parameter is not defined in RFC 1341.

    The body of the MIME content-type is the Data part of the
    ODA body part.

    When mapping from MIME to X.400, the following steps are

    The Parameters.document-application-profile and
    Parameters.document-architecture-class are set from the
    tables above.  If any of the parameters are missing, the
    values for Q112 and formatted-processable are used.

    It is an option for the gateway implementor to try to
    access them from inside the document, where they are
    defined as



    Gateways are NOT required to do this, since the document-
    characteristics are optional parameters.  If a gateway
    does not, it simply uses the defaulting rules defined

    The OBJECT IDENTIFIERs for the document application
    profile and for ODA {2 8 0 0} must be added to the Encoded
    Information Types parameter of the message envelope.

    7.5.  g3-facsimile - image/g3fax

    X.400 Body part: g3-facsimile
    MIME Content-Type: image/g3fax
    Conversion Type: nearly Byte copy

    The Parameters of the X.400 G3Fax body part are mapped to
    the corresponding Parameters on the MIME Image/G3Fax body
    part and vice versa.  Note that:

Alvestrand, Thompson      Exp Jan 96                 [Page 18]

draft            X.400/MIME body equivalences          July 95

     (1)   If fineResolution is not specified, pixels will be
           twice as tall as they are wide

     (2)   If any bit not corresponding to a specially named
           option is set in the G3Fax NonBasicParameters, the
           "DCS" parameter must be used.

     (3)   Interworking is not guaranteed if any bit apart
           from those specially named are used in the

    From X.400 to G3Fax, the body is created in the following

     (1)   Any trailing EOL markers on each bitstring is
           removed. The bit order is changed to conform to the
           most common Internet encoding (highest bit of first
           byte =3D first bit of the G3Fax). The bitstring is
           padded to a byte boundary.

     (2)   6 consecutive EOL markers are appended to each

     (3)   The padded bitstrings are concatenated together

    An EOL marker is the bit sequence 000000000001 (11 zeroes
    and a one).

    From G3Fax to X.400, the body is created in the following

     (1)   The body is split into bitstrings at each
           occurrence of 6 consecutive EOL markers. Trailing
           EOLs must NOT be removed, since the X.400
           Implementor Guide recommends that each page should
           end with 6 consecutive EOLs.  (This is a change
           from RFC 1494).

     (2)   Each bitstring is made into an ASN.1 BITSTRING,
           reversing the order of bits within each byte to
           conforom to the X.400 Implementors Guide
           recommendation for bit order in the G3Fax body

Alvestrand, Thompson      Exp Jan 96                 [Page 19]

draft            X.400/MIME body equivalences          July 95

     (3)   The bitstrings are made into an ASN.1 SEQUENCE,
           which forms the body of the G3Fax body part.

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

    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

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

Alvestrand, Thompson      Exp Jan 96                 [Page 20]

draft            X.400/MIME body equivalences          July 95

    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.

    7.7.  application/postscript - postscript-body-part

    X.400 Body Part: Extended Body Part, OID postscript-body-part
    MIME Content-Type: application/postscript
    Conversion Type: Byte Copy

    7.8.  image/jpeg - jpeg-body-part

    X.400 Body Part: Extended Body Part, OID jpeg-body-part
    MIME Content-Type: image/jpeg
    Conversion Type: Byte Copy

    7.9.  image/gif - gif-body-part

    X.400 Body Part: Extended Body Part, OID gif-body-part
    MIME Content-Type: image/gif
    Conversion Type: Byte Copy

Alvestrand, Thompson      Exp Jan 96                 [Page 21]

draft            X.400/MIME body equivalences          July 95

    8.  OID Assignments
    EXPORTS -- everything --;

           FROM RFC1155-SMI;
           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};

    mime-postscript-body OBJECT IDENTIFIER ::=3D
            { mixer-bp-data 2};

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

    mime-gif-body OBJECT IDENTIFIER ::=3D
            { mixer-bp-data 4};

Alvestrand, Thompson      Exp Jan 96                 [Page 22]

draft            X.400/MIME body equivalences          July 95

    9.  Registration information for the Teletex character

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

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

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

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

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:


    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.

    12.  References

         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 1341, (June,

         S.E. Hardcastle-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

Alvestrand, Thompson      Exp Jan 96                 [Page 25]

draft            X.400/MIME body equivalences          July 95

         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

         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

Alvestrand, Thompson      Exp Jan 96                 [Page 26]

draft            X.400/MIME body equivalences          July 95

    Table of Contents

     Status of this Memo ................................    1
    1 Introduction ......................................    3
    2 Equivalence Table Definition ......................    4
    3 Generic conversions ...............................    5
    3.1 Byte copy .......................................    5
    3.2 Text Conversion .................................    5
    3.3 Image Conversion ................................    5
    4 Conversion Table for known X.400 and MIME  Types
         ................................................    6
    4.1 MIME to X.400 Table .............................    6
    4.2 X.400 to MIME Table .............................    6
    5 Newly defined X.400 Body Parts ....................    8
    5.1 Use of OBJECT IDENTIFIERs and ASN.1 MACROS ......    8
    5.2 The PostScript body part ........................    9
    5.3 The JPEG body part ..............................    9
    5.4 The GIF body part ...............................   10
    6 Newly defined MIME content-types ..................   11
    6.1 The image/g3fax content-type ....................   11
    6.1.1 G3Fax Parameters ..............................   11
    6.1.2 Content Encoding ..............................   13
    6.2 The Application/ODA content-type ................   13
    7 Equivalence Definitions ...........................   14
    7.1 IA5Text - text/plain ............................   14
    7.2 GeneralText - text/plain (ISO-8859) .............   15
    7.3  BilaterallyDefined - application/octet-stream
         ................................................   16
    7.4 ODA - application/oda ...........................   17
    7.5 g3-facsimile - image/g3fax ......................   18
    7.6 Teletex - Text/Plain (Teletex) ..................   20
    7.7 application/postscript -  postscript-body-part
         ................................................   21
    7.8 image/jpeg - jpeg-body-part .....................   21
    7.9 image/gif - gif-body-part .......................   21
    8 OID Assignments ...................................   22
    9 Registration information for the Teletex charac=AD
         ter set ........................................   23
    10 IANA Registration form for new mappings ..........   24
    11 Changes from RFC 1494 ............................   25
    12 References .......................................   25

Alvestrand, Thompson      Exp Jan 96                 [Page 27]