rfc2157.txt

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

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

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

   RFC822FieldList is defined in Appendix L of [MIXER].





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


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

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

        Quoting is preserved in the parameter-value.

    Other
        Take all other headers and create
        MimeParameters.other-header-fields.
        The MIME-version, content-type and content-transfer-
        encoding fields are NOT copied.

   NOTE:
        The set of headers that are mapped will depend on the
        placement of the body part (single body part or
        multipart).
        When it is the only body of a message, headers
        starting with "content-" SHOULD be put into the
        other-header-fields, and all other headers should be
        put into the IPMS extension for the message.
        When it is a single bodypart of a multipart, ALL
        headers on the body part are included, since there is
        nowhere else to put them. Note that only headers that
        start with "content-" have defined semantics in this
        case.

   The body is mapped as follows:

   Convert the MIME body part into its canonical form, as specified in
   Appendix H of MIME [MIME].  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-bp-data is added to the Encoded Information Types of
   the envelope.




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


   This body part is completely compatible with RFC 1494.

   When converting back to a MIME body part, the gateway is responsible
   for:

   (1)   Selecting an appropriate content-transfer-encoding,
         and deleting any content-transfer-encoding header
         from the other-header-fields

   (2)   Adding quotes to any parameters that need them (but
         not adding quotes to parameters that are already
         quoted)

   (3)   Removing any content-type field that is left in the
         RFC822FieldList of the message that is redundant or
         conflicting with the one from the mime-body-part

   (4)   Make sure that on multipart messages, the boundary
         string actually used is reflected in the boundary-
         parameter of the content-type header, and does not
         occur within the body of the message.

3.1.3.  Encapsulation using IA5 (HARPOON)

   This approach is the one taken in RFC 1496 - HARPOON - for tunneling
   any MIME body part through X.400/84 networks. It has proven rather
   unhelpful for bringing information to X.400 users, but preserves all
   the information of a MIME body part.

   The following IA5Text body part is made:

   -    Content = IA5String

   -    First bytes of content: (the description is in US
        ASCII, with C escape sequences used to represent
        control characters):

        MIME-version: <version>\r\n
        Content-type: <the proper MIME content type>\r\n
        Content-transfer-encoding: <7bit, quoted-printable or base64>\r\n
        <Possibly other Content headings here, terminated by\r\n>
         \r\n
        <Here follows the bytes of the content, encoded
         in the proper encoding>

   All implementations MUST place the MIME-version: header first in the
   body part. Headers that are placed by [MIXER] into other parts of the
   message MUST NOT be placed in the MIME body part.



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


   This encapsulation may also be applied to subtypes of multipart,
   creating a single IA5 body part that contains a single multipart/*,
   which in turn may contain multiple MIME body parts.

3.1.4.  Content passing using BP14

   This is described in this section because it is at the same
   conceptual level as encapsulation. It is a lossy transformation; it
   is impossible to reconstruct the MIME type information from it.

   Nevertheless, there is a demand for such functionality.

   This "encapsulation" simply strips off all headers, undoes the
   content-transfer-encoding, and creates a BilaterallyDefined body part
   (BP14) from the resulting octet stream.

   No reverse translation is defined; when a BP14 arrives at a MIXER
   gateway, it will be turned into an application/octet-stream according
   to chap. 6.3

3.2.  Encapsulating X.400 Body Parts in MIME

   This section specifies a generic mechanism to map X.400 body parts to
   a MIME content.  This allows for the body part to be tunneled 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 this
   document.  The content-type field is "application/x400-bp".  The
   parameter is defined by the EBNF:

       mime-parameter =  "bp-type=" ( object-identifier / 1*DIGIT=

   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 EBNF.object-dentifier is
   set to the OBJECT IDENTIFIER from IPMS.body.externally-
   defined.data.direct-reference.

   For example, a basic VideotexBodyPart will have

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

   whilst a Extended Videotex body part will have




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


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

   The body contains the raw ASN.1 IPM body octet stream, that is, the
   BER encoding of the IPM.Body.BodyPart, 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.

   For extended body parts, the

3.3.  Encapsulating FTBP body parts in MIME

   The File Transfer Body Part is believed to be important in the future
   as "the" means of carrying well-identified data in X.400 networks.

   They also share the property (at lest when limited to the EMA MAWG
   functional profile) of having a well-defined data part that is always
   representable as a sequence of bytes.

   This conversion will have to fail, and the x400-bp encapsulation used
   instead, if:

   -    FileTransferData has more than one element

   -    Contents-type is not unstructured-binary

   -    Parameters that are not mappable, but important, are
        present (like Compression, which EMA doesn't
        recommend).

   Otherwise, it can be encapsulated in MIME by:

   -    Creating the "content-type" value by forming the
        string "application/x-ftbp." and appending the
        numbers of the OID found in
        FileTransferParameters.environment.application-
        reference.registered-identifier

   -    Mapping all other parameters according to the
        standard FTBP parameter mapping

   -    Applying an appropriate content-transfer-encoding to
        the data contained in FileTransferData.value.encoding





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


   DISCUSSION:

   The choice of the somewhat strange, and by necessity unregistered,
   MIME type "application/x-ftbp.n.n.n.n" is because for any concrete
   example of this usage, it will be easy to configure any MIME reader
   to take advantage of the identification. If the MIME type
   registration rules are ever changed to allow the registration of a
   namespace, rather than just of names, the "x-" can be deleted, and
   the types can be "application/ftbp.n.n.n.n".

4.  User control over the gateway choice

   In some cases, the gateway may make an inappropriate choice when
   deciding what to do about a particular body part.

   To allow an escape clause, this chapter defines a way in which the
   user can signal the gateway what action it finds most appropriate.

   The headers given here override any "conversion prohibited" and
   "conversion with loss prohibited" on the message.

   It is still the gateway's responsibility that the generated messages
   conform to the destination domain's syntax rules.

   DISCUSSION:

   The intent of this mechanism is to allow the sender to efficiently
   get a message through to a single recipient when the sender has
   information about the recipient that the gateway does not have.

   It is not a part of the minimum functionality listed in chapter 8; a
   gateway does not have to implement this spec to be MIXER conformant,
   but if implemented, it should be done like this.

   The additional complexity, both in user interface and in protocol, of
   making this field selectable per recipient was not thought
   worthwhile;

4.1.  Conversion from MIME to X.400

   The header field described below specifies explicit MIXER conversion.
   Comments are allowed within the field according to the usual RFC 822
   convention.

   If "x400-object-id" is omitted, "tunnel" is assumed.

      mime-to-x400 = "Wanted-X400-Conversion" ":"
                      [ mime-from ]  [ x400-object-id ]



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


                      "in" x400-encoding

      x400-object-id =  "to" ( object-identifier-2 / "tunnel" )
      x400-encoding = "bp14" / "bp15" / "ftbp" / "ia5"
      mime-from = "from" mime-type
      mime-type = word

   There is no way to ask for a different conversion based on MIME
   parameters or bodypart content.

   Examples:

   Wanted-X400-Conversion: from application/msword
                   to 1.2.840.113556.4.2 (Microsoft defined ms-word)
                   in ftbp

   This uses the MAWG definitions, and leads to an FTBP encoding.

   Wanted-X400-Conversion: from application/msword
                  to tunnel in bp14

   This leads to a Body Part 14 encoding for all body parts of type
   application/msword.

   Wanted-X400-Conversion: in bp14

   This requests that this specific body part be encoded in Body Part
   14.

   This field may be used in two places:

      (1)   In the heading of an unstructured MIME body part.
            In this case the EBNF.mime-from is omitted, and the
            requested conversion applies to the body part.

      (2)   In a multipart. In this case, the body part type to
            which the conversion applies is defined by
            EBNF.mime-from, and the conversion applies to all
            body parts of this MIME type contained in the
            multipart, including those contained in nested
            messages and multiparts. If a contained body part
            has its own heading, this takes precedence. Note
            that the "from" parameter is mandatory when used in
            a multipart.

   The EBNF.x400-object-id shall be present when "bp15" or
   "ftbp" encoding is selected.