rfc2157.txt

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

Network Working Group                                      H. Alvestrand
Request for Comments: 2157                                       UNINETT
Category: Standards Track                                   January 1998


         Mapping between X.400 and RFC-822/MIME Message Bodies

Status of this Memo

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

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Table of Contents

   1 Introduction ...........................................    2
   1.1 Glossary .............................................    3
   2 Basic rules for body part conversion ...................    4
   2.1 Generating the IPM Body from MIME ....................    5
   2.2 Generating the MIME Body from the IPMS.Body ..........    6
   2.3 Mapping the EMA FTBP parameters ......................    7
   2.3.1 Mapping GraphicStrings .............................    7
   2.3.2 Mapping specific parameters ........................    7
   2.3.3 Summary of FTBP elements generated .................   10
   2.4 Information that is lost when mapping ................   11
   3 Encapsulation of body parts ............................   11
   3.1 Encapsulation of MIME in X.400 .......................   12
   3.1.1 FTBP encapsulating body part .......................   12
   3.1.2 BP15 encapsulating body part .......................   13
   3.1.3 Encapsulation using IA5 (HARPOON) ..................   15
   3.1.4 Content passing using BP14 .........................   16
   3.2 Encapsulating X.400 Body Parts in MIME ...............   16
   3.3 Encapsulating FTBP body parts in MIME ................   17
   4 User control over the gateway choice ...................   18
   4.1 Conversion from MIME to X.400 ........................   18
   4.2 Conversion from X.400 to MIME ........................   20
   5 The equivalence registry ...............................   21
   5.1 What information one must give about a mapping
        .....................................................   21
   5.2 Equivalence summary for known X.400  and  MIME
       Types ................................................   22
   5.3 MIME to X.400 Table ..................................   23



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


   5.4 X.400 to MIME Table ..................................   23
   5.5 Use of OBJECT IDENTIFIERs and ASN.1 MACROS ...........   24
   6 Defined Equivalences ...................................   26
   6.1 IA5Text - text/plain .................................   26
   6.2 GeneralText - text/plain (ISO-8859) ..................   27
   6.3 BilaterallyDefined - application/octet-stream
       ......................................................   29
   6.4 FTBP  EMA  Unknown  Attachment   -
       application/octet-stream .............................   29
   6.5 MessageBodyPart - message/RFC822 .....................   30
   6.6 MessageBodyPart - multipart/* ........................   31
   6.7 Teletex - Text/Plain (Teletex) .......................   32
   7 Body parts where encapsulation is recommended ..........   33
   7.1 message/external-body ................................   34
   7.2 message/partial ......................................   35
   7.3 multipart/signed .....................................   35
   7.4 multipart/encrypted ..................................   36
   8 Conformance requirements ...............................   37
   9 Security Considerations ................................   38
   10 Author's Address ......................................   38
   11 Acknowledgements ......................................   38
    References ..............................................   38
    APPENDIXES ..............................................   41
    Appendix A: Escape code normalization ...................   41
    Appendix B: OID Assignments .............................   44
    Appendix  C:  Registration information for the
        Teletex character set ...............................   46
    Appendix  D:  IANA Registration form for new
    mappings ................................................   48
    Full Copyright Statement .................................  49

1.  Introduction

   This document is a companion to [MIXER], which defines the principles
   and translation of headers for interworking between MIME-based RFC-
   822 mail and X.400 mail.

   This document defines how to map body parts of X.400 messages into
   MIME entities and vice versa, including the handling of multipart
   messages and forwarded messages.











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


1.1.  Glossary

   The following terms are defined in this document:

   Body part
      Part of a message that has a unique type. This term comes from
      X.400; the corresponding term in MIME (RFC 2046) is limited to use
      in parts of a multipart message; the term "body" may correspond
      better.

   Content-type
      Type information indicating what the content of a body part
      actually is. This term comes from MIME; the corresponding X.400
      term is "body part type".

   Mapping
      (noun): A description of how to transform an X.400 body part into
      a MIME body part, or how to transform a MIME body part into an
      X.400 body part.

   Equivalence
      A set of two mappings that taken together provide a lossless
      conversion between an X.400 body part and a MIME body part

   Encapsulation
      The process of wrapping something from one of the mail systems in
      such a way that it can be carried inside the other mail system.
      When encapsulating, it is not expected that the other mail system
      can make reasonable sense of the body part, but a gateway back
      into the first system will always be able to convert the body part
      without loss back to its original format.

   HARPOON encapsulation
      The encapsulating of a MIME body part by putting it inside an IA5
      body with all headers and encoding intact. First described in RFC
      1496 [HARPOON].

   Tunneling
      What happens when one gateway encapsulates a message and sends it
      to another gateway that decapsulates it.  The hope is that this
      will cause minimal damage to the message in transit.

   DISCUSSION
      At many points in this document, the author has found it useful to
      include material that explains part of the reasoning behind the
      specification. These sections all start with DISCUSSION: and
      continue to the next numbered section heading; they do not dictate
      any additional requirements on a gateway.



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


   The words MUST, SHOULD and MAY, when capitalized, are used as defined
   in RFC 2119 [MUST].

2.  Basic rules for body part conversion

   The basic approach for translating body parts is described in section
   2.1 and 2.2.

   Chapter 3 gives details on "encapsulation", which allows you to be
   certain that no information is lost even when unknown types are
   encountered.

   Chapter 6 gives the core mappings for various body parts.

   The conformance requirements in chapter 8 describe what the minimum
   conformance for a MIXER gateway is with respect to body part
   conversion.

   DISCUSSION:

   At the moment both the MIME and the X.400 worlds seem to be in a
   stable state of flux with regards to carrying around stuff that is
   not text.  In such a situation, there is little chance of defining a
   mapping between them that is the best for all people, all of the
   time.  For this reason, this specification allows a gateway
   considerable latitude in deciding exactly what conversion to apply.

   The decision taken by the gateway may be based on various information
   sources:

   (1)   If the gateway knows what body parts or content
         types the recipient is able to handle, or has
         registered a particular set of preferences for a
         user, and knows how to convert the message
         reasonably to those body parts, the gateway may
         choose to convert body parts in the message to
         those types only.

   (2)   If the gateway gets indications (via special
         headers or heading-extensions defined for the
         purpose) that the sender wanted a particular
         representation on the "other side", and the gateway
         is able to satisfy the request, it may do so. Such
         a mechanism is defined in chapter 4 of this
         document.






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


   (3)   If the gateway gets a message that might be
         appropriate to send as one out of several types,
         but where the typing information does not tell you
         which one to use (like an X.400 BP14, FTAM "just a
         file", or MIME application/octet-stream), it may
         apply heuristics like looking at content or looking
         at filenames to figure out how to deal with the
         message.

   (4)   If the gateway knows that the next hop for the
         message has limited capabilities (like X.400/84),
         it may choose to perform conversions appropriate
         for that medium.

   (5)   Where no mapping is known by  the  gateway,  it
         may  choose  to  drop the body part, reject the
         message, or encapsulate the body  part  as
         described  in  chapter 3.  The choice may be
         configurable, but a conformant MIXER gateway  MUST
         be able to be configured for encapsulation.

   In many cases, a message that goes SMTP->X.400->SMTP will arrive
   without loss of information.

   In some cases, the reverse translation may not be possible, or two
   gateways may choose to apply different translations, based on the
   criteria above, leading to an apparently inconsistent service.

   In addition, service will vary because some gateways will have
   implemented conversions not implemented by other gateways.

   This is believed to be unavoidable.

2.1.  Generating the IPM Body from MIME

   When converting the body of a message from MIME to X.400, the
   following steps are taken:

   If the header does not contain a 822.MIME-Version field, then
   generate an IPMS.Body with a single IPMS.BodyPart of type
   IPMS.IA5TextBodyPart containing the body of the RFC 822 message with
   IPMS.IA5TextBodyPart.parameters.repertoire set to the default (IA5).

   If 822.MIME-Version is present, the body is analyzed as a MIME
   message and the body is converted according to the mappings
   configured and implemented in the gateway.





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


2.2.  Generating the MIME Body from the IPMS.Body

   When converting the body of a message from X.400 to MIME, the
   following steps are taken:

   If there is more than one body part, and the first body part is IA5
   and starts with the string "RFC-822-Headers:"  as the first line,
   then the remainder of this body part shall be appended to the RFC 822
   header.  This relies upon the theory that this body part has been
   generated according to Appendix B of MIXER.  A gateway shall check
   the consistency and syntax of this body part, to ensure that the
   resulting message is conformant with RFC 822.

   If the remaining IPMS.Body consists of a single IPMS.Bodypart, there
   are three possibilities.

   (1)   If it is of type IPMS.IA5Text, and the first line
         is "MIME-Version: 1.0", it is assumed to be a
         HARPOON-encapsulated body part. The complete body
         content is then appended to the headers; the
         separating blank line is inside the message. If an
         RFC 822 syntax error is discovered inside the
         message, it may be mapped directly as described
         below instead.


   (2)   If it is of type IPMS.IA5Text, then this is mapped
         directly and the default MIME encoding (7bit) is
         used, unless very long lines or non-ASCII or
         control characters are found in the body part, in
         which case Quoted-Printable SHOULD be used.


   (3)   All other types are mapped according to the
         mappings configured and implemented in the gateway.


   If the IPMS.Body contains multiple IPMS.Bodypart fields, then a MIME
   message of content type multipart is generated.  If all of the body
   parts are messages, then this is multipart/digest.  Otherwise it is
   multipart/mixed.  The components of the multipart are generated in
   the same order as in the IPMS.Body.

   Each component is mapped according to the mappings configured and
   implemented in the gateway; any IA5 body parts are checked to see if
   they are HARPOON mappings, as described above.





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


2.3.  Mapping the EMA FTBP parameters

   DISCUSSION:

   EMA has defined a profile for use of the File Transfer Body Part
   (FTBP). [MAWG]

   New mappings are expected to use this as the mechanism for carrying
   body parts, and since it is important to have a consistent mapping
   for the special FTBP parameters, these are defined here.

   The mapping of the body will depend on the content-type in MIME and