rfc1494.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

            header-fields structure. Note that this can only
            occur when the MIME content-type occurs as part of a
            "multipart" content-type.

   The mapping from the X.400 mime-body-part to a MIME content-type is
   the inverse of the above steps.

5.3.  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
           ::= mime-postscript-body

         mime-postscript-body OBJECT IDENTIFIER ::=
                   { mime-mhs-bp-data 2 }

5.4.  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
            ::= mime-jpeg-body

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






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


5.5.  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
            ::= mime-gif-body

          mime-gif-body OBJECT IDENTIFIER ::=
                  { mime-mhs-bp-data 4 }

6.  Newly defined MIME content-types

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

6.1.  The application/x400-bp content-type

   This content-type is defined to carry any X.400(88) body part for
   which there is no registered IANA mapping.

       The content-type field is

         application/x400-bp

       The parameters are:

             bp-type=<INTEGER or OBJECT IDENTIFIER>

   The body contains the raw ASN.1 IPM.body octet stream, including the
   initial tag octet.

   If the body is a basic body part, the bp-type parameter is set to the
   number of the body part's context-specific tag, that is, the tag of
   the IPMS.Body.BodyPart component.

   If the body is an Extended Body Part, the bp-type parameter is set to
   the OBJECT IDENTIFIER from

            IPMS.body.externally-defined.data.direct-reference

   No attempt is made to turn the parameters of Extended Body Parts into
   MIME parameters.  (This task is the responsibility of the recipient's
   UA).

   For example, a basic VideotexBodyPart will have




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


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

   whilst a Extended Videotex body part will have

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

   application/x400-bp will need a content-transfer-encoding of base64
   or quoted-printable when carried in 7-bit MIME.  Since there is no
   way to know beforehand the content, it is recommended to just inspect
   the first 1 KByte or so of data and choose the one that seems to
   produce the more compact encoding.

   If this is not feasible, Base64 is recommended.

6.2.  The image/g3fax content-type

   This content-type is defined to carry G3 Facsimile byte streams.

   In general, a G3Fax image contains 3 pieces of information:

       (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.30 describes how to define page
            boundaries.  A page break algorithm is defined here
            that is independent of how the image data is
            conveyed.

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

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




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


       (4)  resolution - possible values: Fine, Coarse

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

         page-length=A4
         page-width=A4
         encoding=1-dimensional
         resolution=Coarse

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

       Parameter               T.30 bit        X.400 bit

       page-length=A4             no bit set
       page-length=B4          19              21
       page-length=Unlimited   20              20

       page-width=A4              no bit set
       page-width=A3           18              22
       page-width=B4           17              23

       encoding=1-dimensional     no bit set
       encoding=2-dimensional  16              8
       encoding=Uncompressed   26              30

       resolution=Coarse          no bit set
       resolution=Fine         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.

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



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


   honored in the MIME representation.

   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
   as needed to achieve this alignment.

   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.3.  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 [4] 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 values.

   Thus an appropriate header field  might look like this:

       Content-Type:  application/oda; profile=Q112;
       class=formatted

   Consult the ODA standard [4] 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=US-ASCII



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


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

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=ISO-8859-(1-9)
   Conversion Type: Byte copy
   Comments:

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

   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 [5], 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 [5], 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.



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


   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-8      6, 148                  Other Latin-using languages

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

   When mapping from MIME to X.400, if there are parameters present in
   the Content-Type: header field, the conversion fails since the