rfc1494.txt

<VC++网络游戏建摸与实现>源代码

Network Working Group                                      H. Alvestrand
Request for Comments: 1494                                  SINTEF DELAB
                                                             S. Thompson
                                                       Soft*Switch, Inc.
                                                             August 1993

       Equivalences between 1988 X.400 and RFC-822 Message Bodies

Status of this Memo

   This RFC specifies an IAB standards track protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

Table of Contents

   1.  Introduction .............................................    2
   2.  Equivalence Table Definition .............................    2
   3.  Generic conversions ......................................    3
   3.1.  Byte copy ..............................................    3
   3.2.  Text Conversion ........................................    3
   3.3.  Image Conversion .......................................    3
   3.4.  Tunneling ..............................................    3
   4.  Conversion Table for known X.400 and MIME  Types .........    4
   4.1.  MIME to X.400 Table ....................................    4
   4.2.  X.400 to MIME Table ....................................    4
   5.  Newly defined X.400 Body Parts ...........................    5
   5.1.  Use of OBJECT IDENTIFIERs and ASN.1 MACROS .............    5
   5.2.  The Generic MIME Extended Body Part ....................    6
   5.3.  The PostScript body part ...............................    7
   5.4.  The JPEG body part .....................................    7
   5.5.  The GIF body part ......................................    8
   6.  Newly defined MIME content-types .........................    8
   6.1.  The application/x400-bp content-type ...................    8
   6.2.  The image/g3fax content-type ...........................    9
   6.2.1.  G3Fax Parameters .....................................    9
   6.2.2.  Content Encoding .....................................   10
   6.3.  The Application/ODA content-type .......................   11
   7. Equivalence Definitions ...................................   11
   7.1. IA5Text - text/plain ....................................   11
   7.2. GeneralText - text/plain (ISO-8859) .....................   12
   7.3. BilaterallyDefined -  application/octet-stream ..........   13
   7.4. ODA - application/oda ...................................   14
   7.5. g3-facsimile - image/g3fax ..............................   15
   7.6. application/postscript -  postscript-body-part ..........   16
   7.7. application/jpeg - jpeg-body-part .......................   16



Alvestrand & Thompson                                           [Page 1]

RFC 1494              X.400/MIME Body Equivalences           August 1993


   7.8. image/gif - gif-body-part ...............................   16
   8. OID Assignments ...........................................   17
   9. IANA Registration form for new mappings ...................   17
   10. Security Considerations ..................................   18
   11. Authors' Addresses .......................................   18
   12. References ...............................................   19

1.  Introduction

   This document is a companion to [1], 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 either.

   Please send comments to the MIME-MHS mailing list:
   <[e-mail]>.

2.  Equivalence Table Definition

   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.

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







Alvestrand & Thompson                                           [Page 2]

RFC 1494              X.400/MIME Body Equivalences           August 1993


   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.

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

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

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.

3.4.  Tunneling

   This is not a conversion at all, but an encapsulation of the object.
   This is the fallback conversion, used when no explicit mapping
   applies.




Alvestrand & Thompson                                           [Page 3]

RFC 1494              X.400/MIME Body Equivalences           August 1993


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
       -----------------          ------------------          -------
       text/plain
         charset=us-ascii         ia5-text                     7.1
         charset=iso-8859-x       EBP - GeneralText            7.2
       text/richtext              no mapping defined           5.2
       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           5.2
       video/mpeg                 no mapping defined           5.2

       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=us-ascii 7.1
       voice                      No Mapping Defined          6.1
       g3-facsimile               image/g3fax                 6.2, 7.5
       g4-class1                  no mapping defined          6.1
       teletex                    no mapping defined          6.1
       videotex                   no mapping defined          6.1
       encrypted                  no mapping defined          6.1
       bilaterally-defined        application/octet-stream    7.3
       nationally-defined         no mapping defined          6.1
       externally-defined         See Extended Body Parts     6.1

       X.400 Extended Body Part  MIME content-type              Section
       ------------------------- --------------------           -------
       GeneralText               text/plain;charset=iso-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                                           [Page 4]

RFC 1494              X.400/MIME Body Equivalences           August 1993


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 [2].

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:

               EXTENDED-BODY-PART-TYPE MACRO::=
               BEGIN
                  TYPE NOTATION  ::= Parameters Data
                  VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)

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

   To meet these requirements, this document uses the OID

      mime-mhs-bodies

   defined in [1], 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 mime-mhs-bodies, one for Data, and the other for Parameters:

          mime-mhs-bp-data  OBJECT IDENTIFIER ::=
                          { mime-mhs-bodies 1 }
          mime-mhs-bp-parameter OBJECT IDENTIFIER ::=
                          { mime-mhs-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                                           [Page 5]

RFC 1494              X.400/MIME Body Equivalences           August 1993


   Lastly, the IANA will use the mime-mhs-bp-data and mime-mhs-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 Generic MIME Extended Body Part

   The following X.400 Body Part is defined to carry any MIME content-
   type for which there is no explicit IANA registered mapping.

         mime-body-part EXTENDED-BODY-PART-TYPE
            PARAMETERS MimeParameters
               IDENTIFIED BY mime-generic-parameters
            DATA            OCTET STRING
            ::= mime-generic-data

         MimeParameters ::=
             SEQUENCE {
                 content-type       IA5String,
                 content-parameters SEQUENCE OF
                                    SEQUENCE {
                                        parameter          IA5String,
                                        parameter-value    IA5String
                                    }

                                    -- from RFC-1327, sec. 5.1.12
                 other-header-fields RFC822FieldList
             }

         mime-generic-parameters OBJECT IDENTIFIER ::=
             { mime-mhs-bp-parameter 1 }
         mime-generic-data       OBJECT IDENTIFIER ::=
             { mime-mhs-bp-data  1 }

   To convert the MIME content-type into the X.400 mime- body-part:

       (1)  Copy the "type/subtype" string from the MIME
            Content-Type: header field into
            MimeParameters.content-type

       (2)  For each "parameter=value" string in the MIME
            Content-Type header field, create a
            MimeParameters.content-parameters structure, and copy
            the "parameter" string into MimeParameters.content-
            parameters.parameter field and the "value" string
            into the paired MimeParameters.content-
            parameters.parameter-value field.

       (3)  Convert the MIME body part into its canonical form.



Alvestrand & Thompson                                           [Page 6]

RFC 1494              X.400/MIME Body Equivalences           August 1993


            (See appendix H of RFC 1341 [3] for a discussion
            of canonical in this context.) Said another way,
            reverse the transfer encoding to recover the original
            byte stream.

       (4)  Copy the canonical byte stream into the mime-body-
            part.data octet string.

       (5)  Remove the Content-type and the Content-transfer-
            encoding header fields from the MIME body part's
            RFC822 header.

       (6)  Any header fields starting with "Content-" in the
            MIME body part is placed in the optional other-