rfc2157.txt

中、英文RFC文档大全打包下载完全版 .

Alvestrand                  Standards Track                    [Page 19]

RFC 2157                X.400/MIME Body Mapping             January 1998


   The value "tunnel" implies encapsulation as defined in
   Chapter 3.

   The "object identifier" used below is:

   -    For BP 15, it is the value of the EXTENDED-BODY-PART-
        TYPE macro that defines the body part, which is found
        in ExternallyDefinedBodyPart.data.direct-reference.

   -    For FTBP, it is the value of the
        Environment.application-reference.

4.2.  Conversion from X.400 to MIME

   The IPM heading defined here shall be present in the heading of a
   message. It defines the mapping for all body parts of the specified
   types, including those in nested messages.

   wanted-MIME-conversion HEADING-EXTENSION
           VALUE WantedMIMEConversions
           ::= id-wanted-MIME-conversions


   WantedMIMEConversions ::= SEQUENCE OF X400toMIMEConversion

   X400toMIMEConversion ::= SEQUENCE {
           x400-type X400Type,
           mime-type MIMEType }


   X400Type ::= CHOICE {
           standard [0] INTEGER,           -- standard body part
           extended [1] OBJECT IDENTIFIER,  -- BP 15
           ftbp     [2] OBJECT IDENTIFIER}     -- FTBP
                                               -- application-reference

   MIMEType ::= SEQUENCE {
           type IA5String,         -- type (e.g., application/ms-word)
           encoding [1] IA5String OPTIONAl -- e.g. quoted-printable
           parameters [2] IA5String OPTIONAL }     -- MIME Parameters

   The heading extension includes all requested conversions, with
   explicit information as to how each body part type is encoded in
   MIME.

   FTBP is identified as a separate body part type, as there will be a
   need for different encodings, dependent on what is being carried.




Alvestrand                  Standards Track                    [Page 20]

RFC 2157                X.400/MIME Body Mapping             January 1998


   Encapsulation is requested by asking for "application/x400-bp" or
   "application/ftbp" as the destination type.

   For FTAM body parts, the parameters will survive the gatewaying
   process. For other body parts, there are three alternatives:

      (1)   The gateway knows a defined mapping for this
           particular body part and destination type. It will be used,
           and parameters mapped accordingly.

      (2)   The gateway knows how to extract an OCTET STRING
           from the body part, and the destination is a simple MIME body
           part. All information outside the OCTET STRING is lost. (This
           may be the case for a BP14 that should end up in an
           application/xyzzy, for instance).

      (3)   The gateway knows of no relevant mapping, and does
           not know how to simplify the X.400 body part. The gateway
           will then proceed as if the mapping control field had not
           been present.

5.  The equivalence registry

5.1.  What information one must give about a mapping

   The following information MUST be supplied when describing an
   equivalence or a mapping:

   MIME type name (which must be preregistered)

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

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

      (1)   Object Identifier for X.400 BP15 Data

      (2)   Object Identifier for X.400 BP15 Parameters

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

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

      <1)   Object Identifier for the FTAM Environment.application-
      reference

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



Alvestrand                  Standards Track                    [Page 21]

RFC 2157                X.400/MIME Body Mapping             January 1998


      (3)   Any other special considerations

   In all cases, the following must be given:

   Conversion algorithms. The expected effect of "Conversion prohibited"
   and "Conversion with loss prohibited" should be noted.

   The conversion must be specified with enough detail to permit
   independent implementation; literature references are acceptable.

   An equivalence can be registered with IANA using the form at the end
   of this document. The purpose of the registration is to achieve a
   greater uniformity among gateways implementing the same translation;
   there is no requirement that a gateway must support all of the
   translations that are registered with IANA, and there is no
   requirement that all conversions supported by a gateway are
   registered with IANA. Specific conformance requirements for MIXER are
   given at the end of this document.

   Anyone can register an equivalence with IANA, and may update the
   registered equivalence at any time, or reassign the right to update
   the registry entry at any time.  However, the IESG has the power to
   "lock" a registration, so that changing it requires IESG approval,
   and to update such a "locked" registration. All registered
   equivalences defined in standards-track documents (including this
   one) are locked.

5.2.  Equivalence summary for known X.400 and MIME Types

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

   For each MIME content-type/X.400 body part pair, the equivalence
   table contains an entry with the following 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.



Alvestrand                  Standards Track                    [Page 22]

RFC 2157                X.400/MIME Body Mapping             January 1998


   The initial Equivalence Table entries in this document are described
   using this convention.

   Further registrations of equivalences should be submitted to the IANA
   after a public review, using the example form given at the end of
   this document.

5.3.  MIME to X.400 Table

   MIME content-type          X.400 Body Part             Section
   -----------------          ------------------          -------
   text/plain
     charset=us-ascii         ia5-text                     6.1
     charset=ISO-8859-x       EBP - GeneralText            6.2
   text/richtext              no mapping defined           Encap
   application/oda            EBP - ODA                    [ODA]
   application/octet-stream   bilaterally-defined or       6.3
                              FTBP unknown attachment      6.4
   application/postscript     EBP - mime-postscript-body   [POSTSCRIPT]
   image/g3fax                g3-facsimile                 [IMAGES]
   image/jpeg                 EBP - mime-jpeg-body         [IMAGES]
   image/gif                  EBP - mime-gif-body          [IMAGES]
   audio/basic                no mapping defined           Encap
   video/mpeg                 no mapping defined           Encap
   message/RFC822             ForwardedIPMessage           6.5
   multipart/*                ForwardedIPMessage           6.6
   multipart/signed           HARPOON encap                7.3
   multipart/encrypted        HARPOON encap                7.4

   Abbreviation: EBP - Extended Body Part


5.4.  X.400 to MIME Table

                             Basic Body Parts

   X.400 Basic Body Part      MIME content-type           Section
   ---------------------      --------------------        -------
   ia5-text                   text/plain;charset=us-ascii 6.1
   voice                      No Mapping Defined          Encap
   g3-facsimile               image/g3fax                 [IMAGES]
   g4-class1                  no mapping defined          Encap
   teletex                    text/plain;charset=teletex  6.7
   videotex                   no mapping defined          Encap
   encrypted                  no mapping defined          Encap
   bilaterally-defined        application/octet-stream    6.3
   nationally-defined         no mapping defined          Encap
   externally-defined         See Extended Body Parts below



Alvestrand                  Standards Track                    [Page 23]

RFC 2157                X.400/MIME Body Mapping             January 1998


   ForwardedIPMessage         message/RFC822 or multipart 6.5,6.6

   X.400 Extended Body Part   MIME content-type             Section
   -------------------------  --------------------          -------
   GeneralText                text/plain;charset=ISO-8859-x  6.2
   ODA                        application/oda               [ODA]
   mime-postscript-body       application/postscript        [POSTSCRIPT]
   mime-jpeg-body             image/jpeg                    [IMAGES]
   mime-gif-body              image/gif                     [IMAGES]
   FTAM                       various                       2.3,6.4

   FTAM application ID        MIME content type              Section
   -------------------        -----------------              -------
   ema-unknown-attachment     application/octet-stream       6.4

5.5.  Use of OBJECT IDENTIFIERs and ASN.1 MACROS

   When one wants to define new BP15 body parts for use with
   equivalences, it is important to know that X.420 dictates that
   Extended Body Parts shall:

   (1)   use OBJECT IDENTIFIERs (OIDs) to uniquely identify
         the contents, and

   (2)   be defined by using the ASN.1 Macro:

              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

      mixer

   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:




Alvestrand                  Standards Track                    [Page 24]

RFC 2157                X.400/MIME Body Mapping             January 1998


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

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

   All definitions of extended X.400 body parts submitted to the IANA
   for registration with a mapping must use the Extended Body Part Type
   macro for the definition.  See [IMAGES] for an example.

   Lastly, the IANA will use the mixer-bp-data and mixer-bp-parameter
   OIDs as root OIDs for any new MIME content-type/subtypes that aren't
   otherwise registered in the Equivalence Table.

   NOTE: The ASN.1 for an ExternallyDefinedBodyPart is

      ExternallyDefinedBodyPart ::= SEQUENCE {
        parameters [0] ExternallyDefinedParameters OPTIONAL,
        data           ExternallyDefinedData }

      ExternallyDefinedParameters ::= EXTERNAL

      ExternallyDefinedData ::= EXTERNAL

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

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

   There are a bit too many choices here; the common X.400 usage for
   BP15 encoding is to:

   (1)   Always use direct-reference

   (2)   Omit indirect-reference and data-value-descriptor

   (3)   Use the single-ASN1-type encoding only






Alvestrand                  Standards Track                    [Page 25]

RFC 2157                X.400/MIME Body Mapping             January 1998


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