rfc2157.txt

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

   on the application-reference in FTBP, and is not specified here.

   However, in many cases, we expect that the translation will involve
   simply copying the octets from one format to the other; that is, "no
   conversion".

2.3.1.  Mapping GraphicStrings

   Some parameters of the EMA Profile are encoded as ASN.1
   GraphicStrings, which are troublesome because they can contain any
   ISO registered graphic character set.  To map these to ASCII for use
   in mail headers, the gateway may either:

     (1)   Use the RFC 2047 [MIME-HDR] encoding mechanism to
           create appropriate encoded-words for the headers
           involved. Note that in some cases, such as within
           Content-Disposition filenames, the encoded-words
           must be in quotes, which is not the normal usage of
           encoded-words.

     (2)   Apply the normalization procedure given in Appendix
           A to identify the ASCII characters of the string,
           and replace all non-ASCII characters with the
           question mark (?).

   Both procedures are valid for MIXER gateways; the simplified
   procedure of ignoring escape sequences and bit-stripping the result
   is NOT valid.

2.3.2.  Mapping specific parameters

   The following parameters are mapped in both directions:

   Content-ID

      The mapping of this element is complex.



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


      The Content-ID is encoded as an IPM.MessageIdentifier and entered
      into the FTBP.FileTransferParameters.related-stored-file.  file-
      identifier.cross-reference.message-reference.

      FTBP.FileTransferParameters.related-stored-file.
      relationship.descriptive-relationship is set to the string
      "Internet MIME Body Part".

      FTBP.FileTransferParameters.related-stored-file.  file-
      identifier.cross-reference.application-crossreference is set to a
      null OCTET STRING.

      The reverse mapping is only performed if the
      FTBP.FileTransferParameters.related-stored-file.
      relationship.descriptive-relationship has the string value
      "Internet MIME Body Part".

   Content-Description

      The value of this field is mapped to and from the first string in
      FTBP.FileTransferParameters.environment.user-visible-string.

   Content-Disposition

      This field is defined in [CDISP]. It has multiple components; the
      handling of each component is given below.

      The "disposition" component is ignored on MIME -> X.400 mapping,
      and is always "attachment" on X.400 -> MIME mapping.

   C-D: filename

      The filename component of the C-D header is mapped to and from
      FileTransferParameters.file-attributes.pathname.

      The EBNF.disposition-type is ignored when creating the FTBP
      pathname, and always set to "attachment" when creating the
      Content-Disposition header.  For example:

         Content-Disposition: attachment; filename=dodo.doc

      or

         Content-Disposition: attachment; filename=/etc/passwd







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


      The filename will be carried as a single incomplete-pathname
      string.  No special significance is assumed for the characters "/"
      and "\".  Note that normal security precautions MUST be taken in
      using a filename on a local file system; this should be obvious
      from the second example.

      This is done to be conformant with the EMA Profile.

   C-D: Creation-date

      Mapped to and from FileTransferParameters.file-attributes.date-
      and-time-of-creation

      For this and all other date fields, the RFC-822 date format is
      used (822.date-time). Note that the parameter syntax of [CDISP]
      requires that all dates be quoted!

   C-D: Modification-date

      Mapped to and from FileTransferParameters.file-attributes.date-
      and-time-of-last-modification

   C-D: Read-date

      Mapped to and from FileTransferParameters.file-attributes.date-
      and-time-of-last-read-access

   C-D: Size

      Mapped to and from FileTransferParameters.file-attributes.object-
      size.  If the value is "no-value-available", the component is NOT
      generated.

   Other RFC-822 headers

      Mapped to extension in FTBP.FileTransferParameters.extensions
      using the rfc-822-field HEADING-EXTENSION from [MIXER].

   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 FTAM extension, 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.



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


   EMA NOTE

      The EMA profile, version 1.5, specifies that handling of
      extensions is Optional for reception. This means that some non-
      MIXER gateways may not implement handling of this field, and some
      UAs may not have the possibility of showing the content of this
      field to the user.

      An alternative approach using
      FTBP.FileTransferParameters.environment.user-visible-string was
      suggested to EMA, and the EMA MAWG recommended in its April 1996
      conference that the IETF MIXER group should rather choose this
      approach.

2.3.3.  Summary of FTBP elements generated

   This is a summary of the preceding section, and does not add new
   information.

   The following elements of the FTBP parameters are mapped or used (the
   rightmost column gives their status in the EMA profile; M=Mandatory,
   O=Optional, R=Recommended for Origination/Receipt):

FileTransferParameters                                             M/M
  Related-Stored-File                                              O/O
    file-identifier
      cross-reference
        application-crossreference         NULL
        message-reference                  Content-ID
    descriptive-relationship               Used as marker
  contents-type                    Must be unstructured-binary     M/M
  environment                                                      M/M
    application-reference                  Selects mapping         M/M
    user-visible-string                    Content-description     R/M
  file-attributes
    pathname                               C-D: Filename           R/M
    date-and-time-of-creation              C-D: Creation-Date      O/O
    date-and-time-of-last-modification     C-D: Modification-Date  R/M
    date-and-time-of-last-read-access      C-D: Read-Date          O/O
    object-size                            C-D: Size               R/M
  extensions                     Other headers       O/O

   All other elements of the FTBP parameters are discarded.








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


   NOTE: There is ongoing work on defining a more complete
   mapping between FTBP headers and a set of RFC-822 headers.
   A gateway MAY choose to support the larger set once it is
   available, but MUST support this limited set.

2.4.  Information that is lost when mapping

   MIME defines fields which add information to MIME contents.  Two of
   these are "Content-ID", and "Content-Description", which have special
   rules here, but MIME allows new fields to be defined at any time.

   The possibilities are limited about what one can do with this
   information:

   (1)   When using encapsulation, the information can be
         preserved

   (2)   When using mapping to FTBP, the information can be
         preserved in the FileTransferParameters.extensions
         defined for that purpose.

   (3)   When mapping to a single-body message, the
         information can be preserved as P22 header
         extensions

   (4)   When mapping to other body part types, the
         information must be discarded.

3.  Encapsulation of body parts

   Where no mapping is possible, the gateway may choose any of the
   following alternatives:

   -    Discard the body part, leaving a "marker" saying what
        happened

   -    Reject the message

   -    "Encapsulate" the body part, by wrapping it in a body
        part defined for that purpose in the other mail
        system

   The choice to be made should be configurable in the gateway, and may
   depend on both policy and knowledge of the recipient's capabilities.







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


3.1.  Encapsulation of MIME in X.400

   Four body parts are defined here to encapsulate MIME body parts in
   X.400.

   This externally-defined body part is backwards compatible with RFC
   1494. The FTBP body part is compatible with the EMA MAWG document
   [MAWG], version 1.5, but has some extensions, in particular the one
   for extra headers.

   The imagined scenarios for each body part are:

   FTBP For use when sending to recipients that can handle
        generic FTBP, and for tunnelling MIME to a MIME UA

   BP15 For use when tunnelling MIME to a MIME UA through an
        X.400(88) network, or to UAs that have been written
        to RFC 1494

   IA5  For use when tunneling MIME to a MIME UA through an
        X.400 network, where some of the links may involve
        X.400(84).

   BP14 For use when the recipient may be an X.400(84) UA
        with BP14 handling capability, and the loss of
        information in headers is not regarded as important.

   but the gateway is free to use any method it finds appropriate in any
   situation.

   FTBP is expected to be the most useful body part in sending to
   X.400(92) systems, while the BP14 content passing is primarily useful
   for sending to X.400(84) systems.

3.1.1.  FTBP encapsulating body part

   This body part utilizes the fundamental assumption in MIME that all
   message content can be legally and completely represented by a single
   octet stream, the "canonical format".

   The FTBP encapsulating body part is defined by the application-
   reference id-mime-ftbp-data; all headers are mapped to the FTBP
   headers, including putting the "Content-type:" header inside the FTBP
   ExtensionsField.

   Translation from the MIME body part is done by:

   -    Undoing the content-transfer-encoding



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


   -    Setting the "FileTransferData.FTdata.value.octet-
        aligned" to the resulting string of octets

   -    Putting the appropriate parameters into the headers.

   Reversing the translation is done by:

   -    Extracting the headers

   -    Applying an appropriate content-transfer-encoding to
        the body. If this is for some reason different from
        the content-transfer-encoding: header retrieved from
        the headers, the old one must be deleted.

   This mapping is lossless, and therefore counts as "no conversion".

   Note that this mapping does not work with multipart types; the
   multipart must first be mapped to a ForwardedIPMessage.

3.1.2.  BP15 encapsulating body part

   This section defines an extended body part, based on body part 15,
   which may be used to hold any MIME content.

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