home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-mixer-bodymap-06.txt < prev    next >
Text File  |  1996-08-16  |  90KB  |  3,026 lines
  1. draft               X.400/MIME body mapping             May 96
  2.  
  3.  
  4.       Mapping between X.400 and RFC-822/MIME Message Bodies
  5.  
  6.                  Thu Aug 15 14:51:04 MET DST 1996
  7.  
  8.  
  9.                      Harald Tveit Alvestrand
  10.                              UNINETT
  11.                   Harald.T.Alvestrand@uninett.no
  12.  
  13.  
  14.  
  15.     Status of this Memo
  16.  
  17.  
  18.  
  19.     The name of this draft is draft-ietf-mixer-bodymap-06.txt.
  20.  
  21.     The following text is required for all drafts:
  22.  
  23.          This document is an Internet Draft.  Internet Drafts
  24.          are working documents of the Internet Engineering
  25.          Task Force (IETF), its Areas, and its Working Groups.
  26.          Note that other groups may also distribute working
  27.          documents as Internet Drafts.
  28.  
  29.          Internet Drafts are draft documents valid for a
  30.          maximum of six months. Internet Drafts may be
  31.          updated, replaced, or obsoleted by other documents at
  32.          any time.  It is not appropriate to use Internet
  33.          Drafts as reference material or to cite them other
  34.          than as a "working draft" or "work in progress."
  35.  
  36.          Please check the I-D abstract listing contained in
  37.          each Internet Draft directory to learn the current
  38.          status of this or any other Internet Draft.
  39.  
  40.  
  41.     This document describes the translation of message body
  42.     parts between X.400 and MIME.
  43.  
  44.     Please send comments to the MIXER mailing list:
  45.     <ietf-mixer@innosoft.com>
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54. Alvestrand                Exp Nov 96                  [Page 1]
  55.  
  56. draft               X.400/MIME body mapping             May 96
  57.  
  58.  
  59.     1.  Introduction
  60.  
  61.     This document is a companion to [MIXER], which defines the
  62.     principles and translation of headers for interworking
  63.     between MIME-based RFC-822 mail and X.400 mail.
  64.  
  65.     This document defines how to map body parts of X.400
  66.     messages into MIME entities and vice versa, including the
  67.     handling of multipart messages and forwarded messages.
  68.  
  69.     A table of contents that should be quite useful for
  70.     locating specific sections is given in the back of the
  71.     document.
  72.  
  73.  
  74.     1.1.  Glossary
  75.  
  76.     The following terms are defined in this document:
  77.  
  78.     Body part
  79.          Part of a message that has a unique type. This term
  80.          comes from X.400; the corresponding term in MIME (RFC
  81.          1521) is limited to use in parts of a multipart
  82.          message; the term "body" may correspond better.
  83.  
  84.     Content-type
  85.          Type information indicating what the content of a
  86.          body part actually is. This term comes from MIME; the
  87.          corresponding X.400 term is "body part type".
  88.  
  89.     Mapping
  90.          (noun): A description of how to transform an X.400
  91.          body part into a MIME body part, or how to transform
  92.          a MIME body part into an X.400 body part.
  93.  
  94.     Equivalence
  95.          A set of two mappings that taken together provide a
  96.          lossless conversion between an X.400 body part and a
  97.          MIME body part
  98.  
  99.     Encapsulation
  100.          The process of wrapping something from one of the
  101.          mail systems in such a way that it can be carried
  102.          inside the other mail system. When encapsulating, it
  103.          is not expected that the other mail system can make
  104.  
  105.  
  106.  
  107.  
  108.  
  109. Alvestrand                Exp Nov 96                  [Page 2]
  110.  
  111. draft               X.400/MIME body mapping             May 96
  112.  
  113.  
  114.          reasonable sense of the body part, but a gateway back
  115.          into the first system will always be able to convert
  116.          the body part without loss back to its original
  117.          format.
  118.  
  119.     HARPOON encapsulation
  120.          The encapsulating of a MIME body part by putting it
  121.          inside an IA5 body with all headers and encoding
  122.          intact. First described in RFC 1496 (HARPOON).
  123.  
  124.     Tunneling
  125.          What happens when one gateway encapsulates a message
  126.          and sends it to another gateway that decapsulates it.
  127.          The hope is that this will cause minimal damage to
  128.          the message in transit.
  129.  
  130.     DISCUSSION
  131.          At many points in this document, the author has found
  132.          it useful to include material that explains part of
  133.          the reasoning behind the specification. These
  134.          sections all start with DISCUSSION: and continue to
  135.          the next numbered section heading; they do not
  136.          dictate any additional requirements on a gateway.
  137.  
  138.  
  139.     2.  Basic rules for body part conversion
  140.  
  141.     The basic approach for translating body parts is described
  142.     in section 2.1 and 2.2.
  143.  
  144.     Chapter 3 gives details on "encapsulation", which allows
  145.     you to be certain that no information is lost even when
  146.     unknown types are encountered.
  147.  
  148.     Chapter 6 gives the core mappings for various body parts.
  149.  
  150.     The conformance requirements in chapter 8 describe what
  151.     the minimum conformance for a MIXER gateway is with
  152.     respect to body part conversion.
  153.  
  154.     DISCUSSION:
  155.  
  156.     At the moment (Sept 1995) both the MIME and the X.400
  157.     worlds are in a state of flux with regards to carrying
  158.     around stuff that is not text.
  159.  
  160.  
  161.  
  162.  
  163.  
  164. Alvestrand                Exp Nov 96                  [Page 3]
  165.  
  166. draft               X.400/MIME body mapping             May 96
  167.  
  168.  
  169.     In such a situation, there is little chance of defining a
  170.     mapping between them that is the best for all people, all
  171.     of the time.
  172.     For this reason, this specification allows a gateway
  173.     considerable latitude in deciding exactly what conversion
  174.     to apply.
  175.  
  176.     The decision taken by the gateway may be based on various
  177.     information sources:
  178.  
  179.      (1)   If the gateway knows what body parts or content
  180.            types the recipient is able to handle, or has
  181.            registered a particular set of preferences for a
  182.            user, and knows how to convert the message
  183.            reasonably to those body parts, the gateway may
  184.            choose to convert body parts in the message to
  185.            those types only.
  186.  
  187.      (2)   If the gateway gets indications (via special
  188.            headers or heading-extensions defined for the
  189.            purpose) that the sender wanted a particular
  190.            representation on the "other side", and the gateway
  191.            is able to satisfy the request, it may do so. Such
  192.            a mechanism is defined in chapter 4 of this
  193.            document.
  194.  
  195.      (3)   If the gateway gets a message that might be
  196.            appropriate to send as one out of several types,
  197.            but where the typing information does not tell you
  198.            which one to use (like an X.400 BP14, FTAM "just a
  199.            file", or MIME application/octet-stream), it may
  200.            apply heuristics like looking at content or looking
  201.            at filenames to figure out how to deal with the
  202.            message.
  203.  
  204.      (4)   If the gateway knows that the next hop for the
  205.            message has limited capabilities (like X.400/84),
  206.            it may choose to perform conversions appropriate
  207.            for that medium.
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219. Alvestrand                Exp Nov 96                  [Page 4]
  220.  
  221. draft               X.400/MIME body mapping             May 96
  222.  
  223.  
  224.  
  225.      (5)   Where  no  mapping  is known by the gateway, it
  226.            may choose to drop the body  part,  reject  the
  227.            message,  or  encapsulate  the body part as de¡
  228.            scribed in chapter 3.  The choice may  be  con¡
  229.            figurable,  but a conformant MIXER gateway MUST
  230.            be able to be configured for encapsulation.
  231.  
  232.  
  233.     In many cases, a message that goes SMTP->X.400->SMTP will
  234.     arrive without loss of information.
  235.  
  236.     In some cases, the reverse translation may not be
  237.     possible, or two gateways may choose to apply different
  238.     translations, based on the criteria above, leading to an
  239.     apparently inconsistent service.
  240.  
  241.     In addition, service will vary because some gateways will
  242.     have implemented conversions not implemented by other
  243.     gateways.
  244.  
  245.     This is believed to be unavoidable.
  246.  
  247.  
  248.     2.1.  Generating the IPM Body from MIME
  249.  
  250.     When converting the body of a message from MIME to X.400,
  251.     the following steps are taken:
  252.  
  253.     If the header does not contain a 822.MIME-Version field,
  254.     then generate an IPMS.Body with a single IPMS.BodyPart of
  255.     type IPMS.IA5TextBodyPart containing the body of the RFC
  256.     822 message with
  257.     IPMS.IA5TextBodyPart.parameters.repertoire set to the
  258.     default (IA5).
  259.  
  260.     If 822.MIME-Version is present, the body is analyzed as a
  261.     MIME message and the body is converted according to the
  262.     mappings configured and implemented in the gateway.
  263.  
  264.  
  265.     2.2.  Generating the MIME Body from the IPMS.Body
  266.  
  267.     When converting the body of a message from X.400 to MIME,
  268.     the following steps are taken:
  269.  
  270.  
  271.  
  272.  
  273.  
  274. Alvestrand                Exp Nov 96                  [Page 5]
  275.  
  276. draft               X.400/MIME body mapping             May 96
  277.  
  278.  
  279.     If there is more than one body part, and the first body
  280.     part is IA5 and starts with the string "RFC-822-Headers:"
  281.     as the first line, then the remainder of this body part
  282.     shall be appended to the RFC 822 header.  This relies upon
  283.     the theory that this body part has been generated
  284.     according to Appendix B of MIXER.  A gateway shall check
  285.     the consistency and syntax of this body part, to ensure
  286.     that the resulting message is conformant with RFC 822.
  287.  
  288.     If the remaining IPMS.Body consists of a single
  289.     IPMS.Bodypart, there are three possibilities.
  290.  
  291.  
  292.      (1)   If it is of type IPMS.IA5Text, and the first line
  293.            is "MIME-Version: 1.0", it is assumed to be a
  294.            HARPOON-encapsulated body part. The complete body
  295.            content is then appended to the headers; the
  296.            separating blank line is inside the message. If an
  297.            RFC 822 syntax error is discovered inside the
  298.            message, it may be mapped directly as described
  299.            below instead.
  300.  
  301.  
  302.      (2)   If it is of type IPMS.IA5Text, then this is mapped
  303.            directly and no MIME encoding is used.
  304.  
  305.  
  306.      (3)   All other types are mapped according to the
  307.            mappings configured and implemented in the gateway.
  308.  
  309.  
  310.     If the IPMS.Body contains multiple IPMS.Bodypart fields,
  311.     then a MIME message of content type multipart is
  312.     generated.  If all of the body parts are messages, then
  313.     this is multipart/digest.  Otherwise it is
  314.     multipart/mixed.  The components of the multipart are
  315.     generated in the same order as in the IPMS.Body.
  316.  
  317.     Each component is mapped according to the mappings
  318.     configured and implemented in the gateway; any IA5 body
  319.     parts are checked to see if they are HARPOON mappings.
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329. Alvestrand                Exp Nov 96                  [Page 6]
  330.  
  331. draft               X.400/MIME body mapping             May 96
  332.  
  333.  
  334.  
  335.     2.3.  Mapping the EMA FTBP parameters
  336.  
  337.     DISCUSSION:
  338.  
  339.     EMA has defined a profile for use of the File Transfer
  340.     Body Part (FTBP). [MAWG]
  341.  
  342.  
  343.     New mappings are expected to use this as the mechanism for
  344.     carrying body parts, and since it is important to have a
  345.     consistent mapping for the special FTBP parameters, these
  346.     are defined here.
  347.  
  348.     The mapping of the body will depend on the content-type in
  349.     MIME and on the application-reference in FTBP, and is not
  350.     specified here.
  351.  
  352.     However, in many cases, we expect that the translation
  353.     will involve simply copying the octets from one format to
  354.     the other; that is, "no conversion".
  355.  
  356.  
  357.  
  358.     2.3.1.  Mapping GraphicStrings
  359.  
  360.     Some parameters of the EMA Profile are encoded as ASN.1
  361.     GraphicStrings, which are troublesome because they can
  362.     contain any ISO registered graphic character set.
  363.     To map these to ASCII for use in mail headers, the gateway
  364.     may either:
  365.  
  366.      (1)   Use the RFC 1522 encoding mechanism to create
  367.            appropriate encoded-words for the headers involved.
  368.            Note that in some cases, such as within Content-
  369.            Disposition filenames, the encoded-words must be in
  370.            quotes, which is not the normal usage of encoded-
  371.            words.
  372.  
  373.      (2)   Apply the normalization procedure given in Appendix
  374.            A to identify the ASCII characters of the string,
  375.            and replace all non-ASCII characters with the
  376.            question mark (?).
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384. Alvestrand                Exp Nov 96                  [Page 7]
  385.  
  386. draft               X.400/MIME body mapping             May 96
  387.  
  388.  
  389.     Both procedures are valid for MIXER gateways; the
  390.     simplified procedure of ignoring escape sequences and bit-
  391.     stripping the result is NOT valid.
  392.  
  393.  
  394.     2.3.2.  Mapping specific parameters
  395.  
  396.     The following parameters are mapped in both directions:
  397.  
  398.  
  399.     Content-ID
  400.  
  401.          The mapping of this element is complex.
  402.  
  403.          The Content-ID is encoded as an IPM.MessageIdentifier
  404.          and entered into the
  405.          FTBP.FileTransferParameters.related-stored-file.
  406.          file-identifier.cross-reference.message-reference.
  407.  
  408.          FTBP.FileTransferParameters.related-stored-file.
  409.          relationship.descriptive-relationship is set to the
  410.          string "Internet MIME Body Part".
  411.  
  412.          FTBP.FileTransferParameters.related-stored-file.
  413.          file-identifier.cross-reference.application-
  414.          crossreference is set to a null OCTET STRING.
  415.  
  416.          The reverse mapping is only performed if the
  417.          FTBP.FileTransferParameters.related-stored-file.
  418.          relationship.descriptive-relationship has the string
  419.          value "Internet MIME Body Part".
  420.  
  421.  
  422.  
  423.     Content-Description
  424.  
  425.          The value of this field is mapped to and from the
  426.          first string in
  427.          FTBP.FileTransferParameters.environment.user-visible-
  428.          string.
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439. Alvestrand                Exp Nov 96                  [Page 8]
  440.  
  441. draft               X.400/MIME body mapping             May 96
  442.  
  443.  
  444.  
  445.     Content-Disposition
  446.  
  447.          This field is defined in [CDISP]. It has multiple
  448.          components;  the  handling  of  each component is
  449.          given below.
  450.  
  451.  
  452.          The "disposition" component is ignored on MIME ->
  453.          X.400 mapping, and is always "attachment" on X.400 ->
  454.          MIME mapping.
  455.  
  456.          NOTE: RFC 1806 gives only the "filename" component.
  457.          The other components are expected to be added to the
  458.          next version of RFC 1806.
  459.  
  460.  
  461.     C-D: filename
  462.  
  463.          The filename component of the C-D header is mapped to
  464.          and from FileTransferParameters.file-
  465.          attributes.pathname.
  466.  
  467.          The EBNF.disposition-type is ignored when creating
  468.          the FTBP pathname, and always set to "attachment"
  469.          when creating the Content-Disposition header.  For
  470.          example:
  471.  
  472.            Content-Disposition: attachment; filename=dodo.doc
  473.  
  474.          or
  475.  
  476.            Content-Disposition: attachment; filename=/etc/passwd
  477.  
  478.          The filename will be carried as a single incomplete-
  479.          pathname string. No special significance is assumed
  480.          for the characters "/" and "\". Note that normal
  481.          security precautions MUST be taken in using a
  482.          filename on a local file system; this should be
  483.          obvious from the second example.
  484.  
  485.          This is done to be conformant with the EMA Profile.
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494. Alvestrand                Exp Nov 96                  [Page 9]
  495.  
  496. draft               X.400/MIME body mapping             May 96
  497.  
  498.  
  499.     C-D: Creation-date
  500.  
  501.          Mapped to and from FileTransferParameters.file-
  502.          attributes.date-and-time-of-creation
  503.  
  504.          For this and all other date fields, the RFC-822 date
  505.          format is used (822.date-time). Note that the
  506.          parameter syntax of RFC 1806 requires that all dates
  507.          be quoted!
  508.  
  509.  
  510.     C-D: Modification-date
  511.  
  512.          Mapped to and from FileTransferParameters.file-
  513.          attributes.date-and-time-of-last-modification
  514.  
  515.  
  516.  
  517.     C-D: Read-date
  518.  
  519.          Mapped to and from FileTransferParameters.file-
  520.          attributes.date-and-time-of-last-read-access
  521.  
  522.  
  523.     C-D: Size
  524.  
  525.          Mapped to and from FileTransferParameters.file-
  526.          attributes.object-size. If the value is "no-value-
  527.          available", the component is NOT generated.
  528.  
  529.  
  530.     Other RFC-822 headers
  531.  
  532.          Mapped to  extension in
  533.          FTBP.FileTransferParameters.extensions using the
  534.          rfc-822-field HEADING-EXTENSION from [MIXER].
  535.  
  536.  
  537.     NOTE:
  538.          The set of headers that are mapped will depend on the
  539.          placement of the body part (single body part or
  540.          multipart).
  541.          When it is the only body of a message, headers
  542.          starting with "content-" SHOULD be put into the FTAM
  543.          extension, and all other headers should be put into
  544.  
  545.  
  546.  
  547.  
  548.  
  549. Alvestrand                Exp Nov 96                 [Page 10]
  550.  
  551. draft               X.400/MIME body mapping             May 96
  552.  
  553.  
  554.          the IPMS extension for the message.
  555.          When it is a single bodypart of a multipart, ALL
  556.          headers on the body part are included, since there is
  557.          nowhere else to put them. Note that only headers that
  558.          start with "content-" have defined semantics in this
  559.          case.
  560.  
  561.  
  562.     EMA NOTE
  563.  
  564.          The EMA profile, version 1.5, specifies that handling
  565.          of extensions is Optional for reception. This means
  566.          that some non-MIXER gateways may not implement
  567.          handling of this field, and some UAs may not have the
  568.          possibility of showing the content of this field to
  569.          the user.
  570.  
  571.          An alternative approach using
  572.          FTBP.FileTransferParameters.environment.user-visible-
  573.          string was suggested to EMA, and the EMA MAWG
  574.          recommended in its April 1996 conference that the
  575.          IETF MIXER group should rather choose this approach.
  576.  
  577.  
  578.     2.3.3.  Summary of FTBP elements generated
  579.  
  580.     This is a summary of the preceding section, and does not
  581.     add new information.
  582.  
  583.     The following elements of the FTBP parameters are mapped
  584.     or used (the rightmost column gives their status in the
  585.     EMA profile; M=Mandatory, O=Optional, R=Recommended for
  586.     Origination/Receipt):
  587.  
  588.     FileTransferParameters                                             M/M
  589.       Related-Stored-File                                              O/O
  590.         file-identifier
  591.           cross-reference
  592.             application-crossreference         NULL
  593.             message-reference                  Content-ID
  594.         descriptive-relationship               Used as marker
  595.       contents-type                    Must be unstructured-binary     M/M
  596.       environment                                                      M/M
  597.         application-reference                  Selects mapping         M/M
  598.         user-visible-string                    Content-description     R/M
  599.  
  600.  
  601.  
  602.  
  603.  
  604. Alvestrand                Exp Nov 96                 [Page 11]
  605.  
  606. draft               X.400/MIME body mapping             May 96
  607.  
  608.  
  609.       file-attributes
  610.         pathname                               C-D: Filename           R/M
  611.         date-and-time-of-creation              C-D: Creation-Date      O/O
  612.         date-and-time-of-last-modification     C-D: Modification-Date  R/M
  613.         date-and-time-of-last-read-access      C-D: Read-Date          O/O
  614.         object-size                            C-D: Size               R/M
  615.       extensions                     Other headers       O/O
  616.  
  617.  
  618.     All other elements of the FTBP parameters are discarded.
  619.  
  620.     NOTE: There is ongoing work on defining a more complete
  621.     mapping between FTBP headers and a set of RFC-822 headers.
  622.     A gateway MAY choose to support the larger set once it is
  623.     available, but MUST support this limited set.
  624.  
  625.  
  626.     2.4.  Information that is lost when mapping
  627.  
  628.     MIME defines fields which add information to MIME
  629.     contents.  Two of these are "Content-ID", and "Content-
  630.     Description", which have special rules here, but MIME
  631.     allows new fields to be defined at any time.
  632.  
  633.     The possibilities are limited about what one can do with
  634.     this information:
  635.  
  636.      (1)   When using encapsulation, the information can be
  637.            preserved
  638.  
  639.      (2)   When using mapping to FTBP, the information can be
  640.            preserved in the FileTransferParameters.extensions
  641.            defined for that purpose.
  642.  
  643.      (3)   When mapping to a single-body message, the
  644.            information can be preserved as P22 header
  645.            extensions
  646.  
  647.      (4)   When mapping to other body part types, the
  648.            information must be discarded.
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659. Alvestrand                Exp Nov 96                 [Page 12]
  660.  
  661. draft               X.400/MIME body mapping             May 96
  662.  
  663.  
  664.     3.  Encapsulation of body parts
  665.  
  666.     Where no mapping is possible, the gateway may choose any
  667.     of the following alternatives:
  668.  
  669.     -    Discard the body part, leaving a "marker" saying what
  670.          happened
  671.  
  672.     -    Reject the message
  673.  
  674.     -    "Encapsulate" the body part, by wrapping it in a body
  675.          part defined for that purpose in the other mail
  676.          system
  677.  
  678.     The choice to be made should be configurable in the
  679.     gateway, and may depend on both policy and knowledge of
  680.     the recipient's capabilities.
  681.  
  682.  
  683.     3.1.  Encapsulation of MIME in X.400
  684.  
  685.     Four body parts are defined here to encapsulate MIME body
  686.     parts in X.400.
  687.  
  688.     The BP15 body part is backwards compatible with RFC 1494.
  689.     The FTBP body part is compatible with the EMA MAWG
  690.     document [MAWG], version 1.5, but has some extensions, in
  691.     particular the one for extra headers.
  692.  
  693.     The imagined scenarios for each body part are:
  694.  
  695.     FTBP For use when sending to recipients that can handle
  696.          generic FTBP, and for tunnelling MIME to a MIME UA
  697.  
  698.     BP15 For use when tunnelling MIME to a MIME UA through an
  699.          X.400(88) network, or to UAs that have been written
  700.          to RFC 1494
  701.  
  702.     IA5  For use when tunneling MIME to a MIME UA through an
  703.          X.400 network, where some of the links may involve
  704.          X.400(84).
  705.  
  706.     BP14 For use when the recipient may be an X.400(84) UA
  707.          with BP14 handling capability, and the loss of
  708.          information in headers is not regarded as important.
  709.  
  710.  
  711.  
  712.  
  713.  
  714. Alvestrand                Exp Nov 96                 [Page 13]
  715.  
  716. draft               X.400/MIME body mapping             May 96
  717.  
  718.  
  719.     but the gateway is free to use any method it finds
  720.     appropriate in any situation.
  721.  
  722.     FTBP is expected to be the most useful body part in
  723.     sending to X.400(92) systems, while the BP14 content
  724.     passing is primarily useful for sending to X.400(84)
  725.     systems.
  726.  
  727.  
  728.     3.1.1.  FTBP encapsulating body part
  729.  
  730.     This body part utilizes the fundamental assumption in MIME
  731.     that all message content can be legally and completely
  732.     represented by a single octet stream, the "canonical
  733.     format".
  734.  
  735.     The FTBP encapsulating body part is defined by the
  736.     application-reference id-mime-ftbp-data; all headers are
  737.     mapped to the FTBP headers, including putting the
  738.     "Content-type:" header inside the FTBP ExtensionsField.
  739.  
  740.  
  741.     Translation from the MIME body part is done by:
  742.  
  743.     -    Undoing the content-transfer-encoding
  744.  
  745.     -    Setting the "FileTransferData.FTdata.value.octet-
  746.          aligned" to the resulting string of octets
  747.  
  748.     -    Putting the appropriate parameters into the headers.
  749.  
  750.     Reversing the translation is done by:
  751.  
  752.     -    Extracting the headers
  753.  
  754.     -    Applying an appropriate content-transfer-encoding to
  755.          the body. If this is for some reason different from
  756.          the content-transfer-encoding: header retrieved from
  757.          the headers, the old one must be deleted.
  758.  
  759.     This mapping is lossless, and therefore counts as "no
  760.     conversion".
  761.  
  762.  
  763.  
  764.  
  765.  
  766.  
  767.  
  768.  
  769. Alvestrand                Exp Nov 96                 [Page 14]
  770.  
  771. draft               X.400/MIME body mapping             May 96
  772.  
  773.  
  774.     3.1.2.  BP15 encapsulating body part
  775.  
  776.     This section defines an extended body part, based on body
  777.     part 15, which may be used to hold any MIME content.
  778.  
  779.  
  780.         mime-body-part EXTENDED-BODY-PART-TYPE
  781.               PARAMETERS MimeParameters
  782.                        IDENTIFIED BY id-mime-bp-parameters
  783.               DATA            OCTET STRING
  784.               ::= id-mime-bp-data
  785.  
  786.         MimeParameters ::=
  787.              SEQUENCE {
  788.                          content-type       IA5String,
  789.                          content-parameters SEQUENCE OF
  790.                                             SEQUENCE {
  791.                                                 parameter          IA5String,
  792.                                                 parameter-value    IA5String
  793.                                             }
  794.                          other-header-fields RFC822FieldList
  795.                      }
  796.  
  797.  
  798.     The OBJECT IDENTIFIERS id-mime-bp-parameter and id-mime-
  799.     bp-data are defined in Appendix B.  A MIME content is
  800.     mapped onto this body part.  The MIME headers of the body
  801.     part are mapped as follows:
  802.  
  803.     RFC822FieldList is defined in Appendix L of [MIXER].
  804.  
  805.  
  806.     Content-Type:
  807.          The "type/subtype" string is mapped to
  808.          MimeParameters.content-type.
  809.  
  810.          For each "parameter=value" string create a
  811.          MimeParameters.content-parameters element. The
  812.          MimeParameters.content-Parameters.parameter field is
  813.          set to the parameter and the MimeParameters.content-
  814.          parameters.parameter-value field is set to the value.
  815.  
  816.          Quoting is preserved in the parameter-value.
  817.  
  818.  
  819.  
  820.  
  821.  
  822.  
  823.  
  824. Alvestrand                Exp Nov 96                 [Page 15]
  825.  
  826. draft               X.400/MIME body mapping             May 96
  827.  
  828.  
  829.     Other
  830.          Take all other headers and create
  831.          MimeParameters.other-header-fields.
  832.  
  833.          The MIME-version, content-type and content-transfer-
  834.          encoding fields are NOT copied.
  835.  
  836.  
  837.     NOTE:
  838.          The set of headers that are mapped will depend on the
  839.          placement of the body part (single body part or
  840.          multipart).
  841.          When it is the only body of a message, headers
  842.          starting with "content-" SHOULD be put into the
  843.          other-header-fields, and all other headers should be
  844.          put into the IPMS extension for the message.
  845.          When it is a single bodypart of a multipart, ALL
  846.          headers on the body part are included, since there is
  847.          nowhere else to put them. Note that only headers that
  848.          start with "content-" have defined semantics in this
  849.          case.
  850.  
  851.  
  852.     The body is mapped as follows:
  853.  
  854.     Convert the MIME body part into its canonical form, as
  855.     specified in Appendix H of MIME [MIME].  This canonical
  856.     form is used to generate the mime-body-part.data octet
  857.     string.
  858.  
  859.     The Parameter mapping may be used independently of the
  860.     body part mapping (e.g., in order to use a different
  861.     encoding for a mapped MIME body part).
  862.  
  863.     This body part contains all of the MIME information, and
  864.     so can be mapped back to MIME without loss of information.
  865.  
  866.     The OID id-mime-bp-data is added to the Encoded
  867.     Information Types of the envelope.
  868.  
  869.     This body part is completely compatible with RFC 1494.
  870.  
  871.     When converting back to a MIME body part, the gateway is
  872.     responsible for:
  873.  
  874.  
  875.  
  876.  
  877.  
  878.  
  879. Alvestrand                Exp Nov 96                 [Page 16]
  880.  
  881. draft               X.400/MIME body mapping             May 96
  882.  
  883.  
  884.      (1)   Selecting an appropriate content-transfer-encoding,
  885.            and deleting any content-transfer-encoding header
  886.            from the other-header-fields
  887.  
  888.      (2)   Adding quotes to any parameters that need them (but
  889.            not adding quotes to parameters that are already
  890.            quoted)
  891.  
  892.      (3)   Removing any content-type field that is left in the
  893.            RFC822FieldList of the message that is redundant or
  894.            conflicting with the one from the mime-body-part
  895.  
  896.      (4)   Make sure that on multipart messages, the boundary
  897.            string actually used is reflected in the boundary=
  898.            parameter of the content-type header, and does not
  899.            occur within the body of the message.
  900.  
  901.  
  902.     3.1.3.  Encapsulation using IA5 (HARPOON)
  903.  
  904.     This approach is the one taken in RFC 1496 - HARPOON - for
  905.     tunneling any MIME body part through X.400/84 networks. It
  906.     has proven rather unhelpful for bringing information to
  907.     X.400 users, but preserves all the information of a MIME
  908.     body part.
  909.  
  910.     The following IA5Text body part is made:
  911.  
  912.  
  913.     -    Content = IA5String
  914.  
  915.     -    First bytes of content: (the description is in US
  916.          ASCII, with C escape sequences used to represent
  917.          control characters):
  918.  
  919.          MIME-version: <version>\r\n
  920.          Content-type: <the proper MIME content type>\r\n
  921.          Content-transfer-encoding: <7bit, quoted-printable or base64>\r\n
  922.          <Possibly other Content headings here, terminated by\r\n>
  923.          \r\n
  924.          <Here follows the bytes of the content, encoded
  925.          in the proper encoding>
  926.  
  927.  
  928.  
  929.  
  930.  
  931.  
  932.  
  933.  
  934. Alvestrand                Exp Nov 96                 [Page 17]
  935.  
  936. draft               X.400/MIME body mapping             May 96
  937.  
  938.  
  939.     All implementations MUST place the MIME-version: header
  940.     first in the body part. Headers that are placed by [MIXER]
  941.     into other parts of the message MUST NOT be placed in the
  942.     MIME body part.
  943.  
  944.  
  945.     3.1.4.  Content passing using BP14
  946.  
  947.     This is described in this section because it is at the
  948.     same conceptual level as encapsulation. It is a lossy
  949.     transformation; it is impossible to reconstruct the MIME
  950.     type information from it.
  951.  
  952.     Nevertheless, there is a demand for such functionality.
  953.  
  954.     This "encapsulation" simply strips off all headers, undoes
  955.     the content-transfer-encoding, and creates a
  956.     BilaterallyDefined body part (BP14) from the resulting
  957.     octet stream.
  958.  
  959.     No reverse translation is defined; when a BP14 arrives at
  960.     a MIXER gateway, it will be turned into an
  961.     application/octet-stream according to chap. 6.3
  962.  
  963.  
  964.     3.2.  Encapsulating X.400 Body Parts in MIME
  965.  
  966.     This section specifies a generic mechanism to map X.400
  967.     body parts to a MIME content.  This allows for the body
  968.     part to be tunneled through MIME.   It may also be used
  969.     directly by an appropriately configured MIME UA.
  970.  
  971.     This content-type is defined to carry any X.400 extended
  972.     body part.  The mapping of all standard X.400 body parts
  973.     is defined in RFC1494bis.  The content-type field is
  974.     "application/x400-bp".  The parameter is defined by the
  975.     EBNF:
  976.  
  977.             mime-parameter =  "bp-type=" object-identifier
  978.  
  979.     The EBNF.object-identifier is set to the OBJECT IDENTIFIER
  980.     from IPMS.body.externally-defined.data.direct-reference.
  981.  
  982.     For example, a Videotex body part will have
  983.  
  984.  
  985.  
  986.  
  987.  
  988.  
  989. Alvestrand                Exp Nov 96                 [Page 18]
  990.  
  991. draft               X.400/MIME body mapping             May 96
  992.  
  993.  
  994.             Content-type=application/x400-bp; bp-type=2.6.1.4.5
  995.  
  996.     The body contains the raw ASN.1 IPM body octet stream,
  997.     that is, the BER encoding of the IPM.Body.BodyPart,
  998.     including the initial tag octet.  The content may use a
  999.     content-transfer-encoding of either base64 or quoted-
  1000.     printable when carried in 7-bit MIME.  It is recommended
  1001.     to use the one which gives the more compact encoding of
  1002.     the data.  If this cannot be determined, Base64 is
  1003.     recommended.  No attempt is made to turn the parameters of
  1004.     Extended Body Parts into MIME parameters, as this cannot
  1005.     be done in a general manner.
  1006.  
  1007.     Standard X.400 body parts may not be encoded directly by
  1008.     this mechanism, but may be encoded indirectly by first
  1009.     translating to the extended representation.
  1010.  
  1011.     NOTE: RFC 1494 defined a bp-type=<integer> for encoding
  1012.     standard X.400 body parts. If such body parts are
  1013.     encountered, RFC 1494 section 6.1 should be consulted.
  1014.  
  1015.  
  1016.     3.3.  Encapsulating FTBP body parts in MIME
  1017.  
  1018.     The File Transfer Body Part is believed to be important in
  1019.     the future as "the" means of carrying well-identified data
  1020.     in X.400 networks.
  1021.  
  1022.     They also share the property (at lest when limited to the
  1023.     EMA MAWG functional profile) of having a well-defined data
  1024.     part that is always representable as a sequence of bytes.
  1025.  
  1026.     This conversion will have to fail, and the x400-bp
  1027.     encapsulation used instead, if:
  1028.  
  1029.     -    FileTransferData has more than one element
  1030.  
  1031.     -    Contents-type is not unstructured-binary
  1032.  
  1033.     -    Parameters that are not mappable, but important, are
  1034.          present (like Compression, which EMA doesn't
  1035.          recommend).
  1036.  
  1037.     Otherwise, it can be encapsulated in MIME by:
  1038.  
  1039.  
  1040.  
  1041.  
  1042.  
  1043.  
  1044. Alvestrand                Exp Nov 96                 [Page 19]
  1045.  
  1046. draft               X.400/MIME body mapping             May 96
  1047.  
  1048.  
  1049.     -    Creating the "content-type" value by forming the
  1050.          string "application/x-ftbp." and appending the
  1051.          numbers of the OID
  1052.  
  1053.     -    Mapping all other parameters according to the
  1054.          standard FTBP parameter mapping
  1055.  
  1056.     -    Applying an appropriate content-transfer-encoding
  1057.  
  1058.     DISCUSSION:
  1059.  
  1060.     The choice of the somewhat strange, and by necessity
  1061.     unregistered, MIME type "application/x-ftbp.n.n.n.n" is
  1062.     because for any concrete example of this usage, it will be
  1063.     easy to configure any MIME reader to take advantage of the
  1064.     identification. If the MIME type registration rules are
  1065.     ever changed to allow the registration of a namespace,
  1066.     rather than just of names, the "x-" can be deleted, and
  1067.     the types can be "application/ftbp.n.n.n.n".
  1068.  
  1069.  
  1070.  
  1071.  
  1072.     4.  User control over the gateway choice
  1073.  
  1074.     In some cases, the gateway may make an inappropriate
  1075.     choice when deciding what to do about a particular body
  1076.     part.
  1077.  
  1078.     To allow an escape clause, this chapter defines a way in
  1079.     which the user can signal the gateway what action it finds
  1080.     most appropriate.
  1081.  
  1082.     The headers given here override any "conversion
  1083.     prohibited" and "conversion with loss prohibited" on the
  1084.     message.
  1085.  
  1086.     It is still the gateway's responsibility that the
  1087.     generated messages conform to the destination domain's
  1088.     syntax rules.
  1089.  
  1090.     DISCUSSION:
  1091.  
  1092.     The intent of this mechanism is to allow the sender to
  1093.     efficiently get a message through to a single recipient
  1094.  
  1095.  
  1096.  
  1097.  
  1098.  
  1099. Alvestrand                Exp Nov 96                 [Page 20]
  1100.  
  1101. draft               X.400/MIME body mapping             May 96
  1102.  
  1103.  
  1104.     when the sender has information about the recipient that
  1105.     the gateway does not have.
  1106.  
  1107.     It is not a part of the minimum functionality listed in
  1108.     chapter 8; a gateway does not have to implement this spec
  1109.     to be MIXER conformant, but if implemented, it should be
  1110.     done like this.
  1111.  
  1112.     The additional complexity, both in user interface and in
  1113.     protocol, of making this field selectable per recipient
  1114.     was not thought worthwhile;
  1115.  
  1116.  
  1117.     4.1.  Conversion from MIME to X.400
  1118.  
  1119.  
  1120.     The header field described below specifies explicit MIXER
  1121.     conversion. Comments are allowed within the field
  1122.     according to the usual RFC 822 convention.
  1123.  
  1124.     If "x400-object-id" is omitted, "tunnel" is assumed.
  1125.  
  1126.     mime-to-x400 = "Wanted-X400-Conversion" ":"
  1127.                     [ mime-from ]  [ x400-object-id ]
  1128.                     "in" x400-encoding
  1129.  
  1130.     x400-object-id =  "to" ( object-identifier-2 / "tunnel" )
  1131.     x400-encoding = "bp14" / "bp15" / "ftbp" / "ia5"
  1132.     mime-from = "from" mime-type
  1133.     mime-type = word
  1134.  
  1135.     There is no way to ask for a different conversion based on
  1136.     MIME parameters or bodypart content.
  1137.  
  1138.     Examples:
  1139.  
  1140.     Wanted-X400-Conversion: from application/msword
  1141.                     to 1.2.840.113556.4.2 (Microsoft defined ms-word)
  1142.                     in ftbp
  1143.  
  1144.     This uses the MAWG definitions, and leads to an FTBP encoding.
  1145.  
  1146.     Wanted-X400-Conversion: from application/msword
  1147.                     to tunnel in bp14
  1148.  
  1149.  
  1150.  
  1151.  
  1152.  
  1153.  
  1154. Alvestrand                Exp Nov 96                 [Page 21]
  1155.  
  1156. draft               X.400/MIME body mapping             May 96
  1157.  
  1158.  
  1159.     This leads to a Body Part 14 encoding for all body parts of type
  1160.     application/msword.
  1161.  
  1162.     Wanted-X400-Conversion: in bp14
  1163.  
  1164.     This requests that this specific body part be encoded in Body Part 14.
  1165.  
  1166.  
  1167.     This field may be used in two places:
  1168.  
  1169.      (1)   In the heading of an unstructured MIME body part.
  1170.            In this case the EBNF.mime-from is omitted, and the
  1171.            requested conversion applies to the body part.
  1172.  
  1173.  
  1174.  
  1175.      (2)   In a multipart. In this case, the body part type to
  1176.            which the conversion applies is defined by
  1177.            EBNF.mime-from, and the conversion applies to all
  1178.            body parts of this MIME type contained in the
  1179.            multipart, including those contained in nested
  1180.            messages and multiparts. If a contained body part
  1181.            has its own heading, this takes precedence. Note
  1182.            that the "from" parameter is mandatory when used in
  1183.            a multipart.
  1184.  
  1185.  
  1186.     The EBNF.x400-object-id shall be present when "bp15" or
  1187.     "ftbp" encoding is selected.
  1188.  
  1189.     The value "tunnel" implies encapsulation as defined in
  1190.     Chapter 3.
  1191.  
  1192.     The "object identifier" used below is:
  1193.  
  1194.     -    For BP 15, it is the value of the EXTENDED-BODY-PART-
  1195.          TYPE macro that defines the body part, which is found
  1196.          in ExternallyDefinedBodyPart.data.direct-reference.
  1197.  
  1198.     -    For FTBP, it is the value of the
  1199.          Environment.application-reference.
  1200.  
  1201.  
  1202.  
  1203.  
  1204.  
  1205.  
  1206.  
  1207.  
  1208.  
  1209. Alvestrand                Exp Nov 96                 [Page 22]
  1210.  
  1211. draft               X.400/MIME body mapping             May 96
  1212.  
  1213.  
  1214.     4.2.  Conversion from X.400 to MIME
  1215.  
  1216.  
  1217.     The IPM heading defined here shall be present in the
  1218.     heading of a message. It defines the mapping for all body
  1219.     parts of the specified types, including those in nested
  1220.     messages.
  1221.  
  1222.     wanted-MIME-conversion HEADING-EXTENSION
  1223.             VALUE WantedMIMEConversions
  1224.             ::= id-wanted-MIME-conversions
  1225.  
  1226.  
  1227.     WantedMIMEConversions ::= SEQUENCE OF X400toMIMEConversion
  1228.  
  1229.  
  1230.     X400toMIMEConversion ::= SEQUENCE {
  1231.             x400-type X400Type,
  1232.             mime-type MIMEType }
  1233.  
  1234.     X400Type ::= CHOICE {
  1235.             standard [0] INTEGER,           -- standard body part
  1236.             extended [1] OBJECT IDENTIFIER,  -- BP 15
  1237.             ftbp     [2] OBJECT IDENTIFIER}     -- FTBP application-reference
  1238.  
  1239.     MIMEType ::= SEQUENCE {
  1240.             type IA5String,         -- type (e.g., application/ms-word)
  1241.             encoding [1] IA5String OPTIONAl -- e.g. quoted-printable
  1242.             parameters [2] IA5String OPTIONAL }     -- MIME Parameters
  1243.  
  1244.     The heading extension includes all requested conversions,
  1245.     with explicit information as to how each body part type is
  1246.     encoded in MIME.
  1247.  
  1248.     FTBP is identified as a separate body part type, as there
  1249.     will be a need for different encodings, dependent on what
  1250.     is being carried.
  1251.  
  1252.     Encapsulation is requested by asking for
  1253.     "application/x400-bp" or "application/ftbp" as the
  1254.     destination type.
  1255.  
  1256.     For FTAM body parts, the parameters will survive the
  1257.     gatewaying process. For other body parts, there are three
  1258.     alternatives:
  1259.  
  1260.  
  1261.  
  1262.  
  1263.  
  1264. Alvestrand                Exp Nov 96                 [Page 23]
  1265.  
  1266. draft               X.400/MIME body mapping             May 96
  1267.  
  1268.  
  1269.      (1)   The gateway knows a defined mapping for this
  1270.            particular body part and destination type. It will
  1271.            be used, and parameters mapped accordingly.
  1272.  
  1273.      (2)   The gateway knows how to extract an OCTET STRING
  1274.            from the body part, and the destination is a simple
  1275.            MIME body part. All information outside the OCTET
  1276.            STRING is lost. (This may be the case for a BP14
  1277.            that should end up in an application/xyzzy, for
  1278.            instance).
  1279.  
  1280.      (3)   The gateway knows of no relevant mapping, and does
  1281.            not know how to simplify the X.400 body part. The
  1282.            gateway will then proceed as if the mapping control
  1283.            field had not been present.
  1284.  
  1285.     5.  The equivalence registry
  1286.  
  1287.  
  1288.     5.1.  What information one must give about a mapping
  1289.  
  1290.     The following information MUST be supplied when describing
  1291.     an equivalence or a mapping:
  1292.  
  1293.     MIME type name (which must be preregistered)
  1294.  
  1295.     X.400 body part (often BP15 or FTAM Body Part)
  1296.  
  1297.     If BP15 is used, the following information must be given:
  1298.  
  1299.  
  1300.      (1)   Object Identifier for X.400 BP15 Data
  1301.  
  1302.      (2)   Object Identifier for X.400 BP15 Parameters
  1303.  
  1304.      (3)   X.400 ASN.1 Syntax (must be an EXTENDED-BODY-PART-
  1305.            TYPE macro)
  1306.  
  1307.  
  1308.     If FTBP is used, the following information must be given:
  1309.  
  1310.  
  1311.      (1)   Object Identifier for the FTAM
  1312.            Environment.application-reference
  1313.  
  1314.  
  1315.  
  1316.  
  1317.  
  1318.  
  1319. Alvestrand                Exp Nov 96                 [Page 24]
  1320.  
  1321. draft               X.400/MIME body mapping             May 96
  1322.  
  1323.  
  1324.      (2)   Object Identifier for the FTAM Contents-type, if
  1325.            unstructured-binary is not used
  1326.  
  1327.      (3)   Any other special considerations
  1328.  
  1329.  
  1330.     In all cases, the following must be given:
  1331.  
  1332.     Conversion algorithms. The expected effect of "Conversion
  1333.     prohibited" and "Conversion with loss prohibited" should
  1334.     be noted.
  1335.  
  1336.     The conversion must be specified with enough detail to
  1337.     permit independent implementation; literature references
  1338.     are acceptable.
  1339.  
  1340.     An equivalence can be registered with IANA using the form
  1341.     at the end of this document. The purpose of the
  1342.     registration is to achieve a greater uniformity among
  1343.     gateways implementing the same translation; there is no
  1344.     requirement that a gateway must support all of the
  1345.     translations that are registered with IANA. Specific
  1346.     conformance requirements for MIXER are given at the end of
  1347.     this document.
  1348.  
  1349.  
  1350.     5.2.  Equivalence summary for known X.400 and MIME Types
  1351.  
  1352.     This section itemizes the equivalences for all currently
  1353.     known MIME content-types and X.400 body parts.
  1354.  
  1355.     For each MIME content-type/X.400 body part pair, the
  1356.     equivalence table contains an entry with the following
  1357.     sections:
  1358.  
  1359.  
  1360.     X.400 Body Part
  1361.          This section identifies the X.400 Body Part governed
  1362.          by this Table entry. It includes any OBJECT
  1363.          IDENTIFIERs or other parameters necessary to uniquely
  1364.          identify the Body Part.
  1365.  
  1366.  
  1367.     MIME Content-Type
  1368.          This section identifies the MIME content-type
  1369.  
  1370.  
  1371.  
  1372.  
  1373.  
  1374. Alvestrand                Exp Nov 96                 [Page 25]
  1375.  
  1376. draft               X.400/MIME body mapping             May 96
  1377.  
  1378.  
  1379.          governed by this Table entry.  The MIME content-type
  1380.          named here must be registered with the IANA.
  1381.  
  1382.  
  1383.     Section/document reference
  1384.          Reference to section of this document, or to the
  1385.          other document that describes this mapping.
  1386.  
  1387.  
  1388.     The initial Equivalence Table entries in this document are
  1389.     described using this convention.
  1390.  
  1391.     Further registrations of equivalences should be submitted
  1392.     to the IANA after a public review, using the example form
  1393.     given at the end of this document.
  1394.  
  1395.  
  1396.     5.3.  MIME to X.400 Table
  1397.  
  1398.     MIME content-type          X.400 Body Part             Section
  1399.     -----------------          ------------------          -------
  1400.     text/plain
  1401.       charset=us-ascii         ia5-text                     6.1
  1402.       charset=ISO-8859-x       EBP - GeneralText            6.2
  1403.     text/richtext              no mapping defined           Encap
  1404.     application/oda            EBP - ODA                    [ODA]
  1405.     application/octet-stream   bilaterally-defined or       6.3
  1406.                                FTBP unknown attachment      6.4
  1407.     application/postscript     EBP - mime-postscript-body   [POSTSCRIPT]
  1408.     image/g3fax                g3-facsimile                 [IMAGES]
  1409.     image/jpeg                 EBP - mime-jpeg-body         [IMAGES]
  1410.     image/gif                  EBP - mime-gif-body          [IMAGES]
  1411.     audio/basic                no mapping defined           Encap
  1412.     video/mpeg                 no mapping defined           Encap
  1413.     message/RFC822             ForwardedIPMessage           6.5
  1414.     multipart/*                ForwardedIPMessage           6.6
  1415.     multipart/signed           HARPOON encap          7.3
  1416.     multipart/encrypted        HARPOON encap                7.4
  1417.  
  1418.     Abbreviation: EBP - Extended Body Part
  1419.  
  1420.  
  1421.  
  1422.  
  1423.  
  1424.  
  1425.  
  1426.  
  1427.  
  1428.  
  1429. Alvestrand                Exp Nov 96                 [Page 26]
  1430.  
  1431. draft               X.400/MIME body mapping             May 96
  1432.  
  1433.  
  1434.     5.4.  X.400 to MIME Table
  1435.                              Basic Body Parts
  1436.  
  1437.     X.400 Basic Body Part      MIME content-type           Section
  1438.     ---------------------      --------------------        -------
  1439.     ia5-text                   text/plain;charset=us-ascii 6.1
  1440.     voice                      No Mapping Defined          Encap
  1441.     g3-facsimile               image/g3fax                 [IMAGES]
  1442.     g4-class1                  no mapping defined          Encap
  1443.     teletex                    text/plain;charset=teletex  6.7
  1444.     videotex                   no mapping defined          Encap
  1445.     encrypted                  no mapping defined          Encap
  1446.     bilaterally-defined        application/octet-stream    6.3
  1447.     nationally-defined         no mapping defined          Encap
  1448.     externally-defined         See Extended Body Parts below
  1449.     ForwardedIPMessage         message/RFC822 or multipart 6.5,6.6
  1450.  
  1451.     X.400 Extended Body Part   MIME content-type              Section
  1452.     -------------------------  --------------------           -------
  1453.     GeneralText                text/plain;charset=ISO-8859-x  6.2
  1454.     ODA                        application/oda                [ODA]
  1455.     mime-postscript-body       application/postscript         [POSTSCRIPT]
  1456.     mime-jpeg-body             image/jpeg                     [IMAGES]
  1457.     mime-gif-body              image/gif                      [IMAGES]
  1458.     FTAM                       various                        2.3,6.4
  1459.  
  1460.     FTAM application ID        MIME content type              Section
  1461.     -------------------        -----------------              -------
  1462.     ema-unknown-attachment     application/octet-stream       6.4
  1463.  
  1464.  
  1465.  
  1466.  
  1467.  
  1468.  
  1469.  
  1470.  
  1471.  
  1472.  
  1473.  
  1474.  
  1475.  
  1476.  
  1477.  
  1478.  
  1479.  
  1480.  
  1481.  
  1482.  
  1483.  
  1484. Alvestrand                Exp Nov 96                 [Page 27]
  1485.  
  1486. draft               X.400/MIME body mapping             May 96
  1487.  
  1488.  
  1489.     5.5.  Use of OBJECT IDENTIFIERs and ASN.1 MACROS
  1490.  
  1491.     When one wants to define new BP15 body parts for use with
  1492.     equivalences, it is important to know that X.420 dictates
  1493.     that Extended Body Parts shall:
  1494.  
  1495.      (1)   use OBJECT IDENTIFIERs (OIDs) to uniquely identify
  1496.            the contents, and
  1497.  
  1498.      (2)   be defined by using the ASN.1 Macro:
  1499.  
  1500.               EXTENDED-BODY-PART-TYPE MACRO::=
  1501.               BEGIN
  1502.                  TYPE NOTATION  ::= Parameters Data
  1503.                  VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
  1504.  
  1505.                  Parameters     ::=  "PARAMETERS" type "IDENTIFIED"
  1506.                                      "BY" value(OBJECT IDENTIFIER)
  1507.                                    | empty;
  1508.                  Data           ::= "DATA" type
  1509.               END
  1510.  
  1511.     To meet these requirements, this document uses the OID
  1512.  
  1513.        mixer
  1514.  
  1515.     defined in [MIXER], as the root OID for X.400 Extended
  1516.     Body Parts defined for MIME interworking.
  1517.  
  1518.     Each Extended Body Part contains Data and optional
  1519.     Parameters, each being named by an OID.  To this end, two
  1520.     OID subtrees are defined under mixer-bodies, one for Data,
  1521.     and the other for Parameters:
  1522.  
  1523.        mixer-bp-data  OBJECT IDENTIFIER ::=
  1524.                        { mixer 1 }
  1525.  
  1526.        mixer-bp-parameter OBJECT IDENTIFIER ::=
  1527.                        { mixer 2 }
  1528.  
  1529.  
  1530.     All definitions of extended X.400 body parts submitted to
  1531.     the IANA for registration with a mapping must use the
  1532.     Extended Body Part Type macro for the definition.  See
  1533.     [IMAGES] for an example.
  1534.  
  1535.  
  1536.  
  1537.  
  1538.  
  1539. Alvestrand                Exp Nov 96                 [Page 28]
  1540.  
  1541. draft               X.400/MIME body mapping             May 96
  1542.  
  1543.  
  1544.     Lastly, the IANA will use the mixer-bp-data and mixer-bp-
  1545.     parameter OIDs as root OIDs for any new MIME content-
  1546.     type/subtypes that aren't otherwise registered in the
  1547.     Equivalence Table.
  1548.  
  1549.     NOTE: The ASN.1 for an ExternallyDefinedBodyPart is
  1550.  
  1551.       ExternallyDefinedBodyPart ::= SEQUENCE {
  1552.          parameters [0] ExternallyDefinedParameters OPTIONAL,
  1553.          data           ExternallyDefinedData }
  1554.  
  1555.       ExternallyDefinedParameters ::= EXTERNAL
  1556.  
  1557.       ExternallyDefinedData ::= EXTERNAL
  1558.  
  1559.     The ASN.1 for EXTERNAL is (from X.208):
  1560.  
  1561.       EXTERNAL ::= [UNIVERSAL 8] IMPLICIT SEQUENCE
  1562.       {direct-reference     OBJECT IDENTIFIER OPTIONAL,
  1563.       indirect-reference    INTEGER OPTIONAL,
  1564.       data-value-descriptor ObjectDescriptor OPTIONAL,
  1565.       encoding CHOICE
  1566.         {single-ASN1-type  [0] ANY,
  1567.          octet-aligned     [1] IMPLICIT OCTET STRING,
  1568.          arbitrary         [2] IMPLICIT BIT STRING}}
  1569.  
  1570.       ObjectDescriptor ::= [UNIVERSAL 7] IMPLICIT GraphicString
  1571.  
  1572.     There are a bit too many choices here; the common X.400
  1573.     usage for BP15 encoding is to:
  1574.  
  1575.      (1)   Always use direct-reference
  1576.  
  1577.      (2)   Omit indirect-reference and data-value-descriptor
  1578.  
  1579.      (3)   Use the single-ASN1-type encoding only
  1580.  
  1581.     Unfortunately, some implementations have chosen to use the
  1582.     octet-aligned choice when constructing values where the
  1583.     ASN.1 type is OCTET STRING, which of course caused
  1584.     interoperability problems.
  1585.  
  1586.     An attempt to specify that X.420 only allowed the single-
  1587.     ASN1-type choice in the 1996 versions is still (Sept 1995)
  1588.     being debated in ISO; the end result seems to be that all
  1589.  
  1590.  
  1591.  
  1592.  
  1593.  
  1594. Alvestrand                Exp Nov 96                 [Page 29]
  1595.  
  1596. draft               X.400/MIME body mapping             May 96
  1597.  
  1598.  
  1599.     agree in principle that single-ASN1-type should be used,
  1600.     but that one has to allow the generation of the octet-
  1601.     aligned choice as being conformant.
  1602.  
  1603.  
  1604.  
  1605.     6.  Defined Equivalences
  1606.  
  1607.  
  1608.     6.1.  IA5Text - text/plain
  1609.  
  1610.     X.400 Body Part: IA5Text
  1611.     MIME Content-type: text/plain; charset=US-ASCII
  1612.     Conversion Type: No conversion
  1613.     Comments:
  1614.  
  1615.     When mapping from X.400 to MIME, the "repertoire"
  1616.     parameter is ignored.
  1617.  
  1618.     When mapping from MIME to X.400, the "repertoire"
  1619.     parameter is set to IA5 (5).
  1620.  
  1621.     NOTE: The MIME Content-type headers are omitted, when
  1622.     mapping from X.400 to MIME, if and only if the IA5Text
  1623.     body part is the only body part in the IPMS.Body sequence.
  1624.  
  1625.     NOTE: IA5Text specifies the "currency" symbol in position
  1626.     2/4. This is converted without comment to the "dollar"
  1627.     symbol, since the author of this document has seen many
  1628.     documents in which the position was intended to indicate
  1629.     "dollar" while he has not yet seen one in which the
  1630.     "currency" symbol is intended.
  1631.  
  1632.     (For reference: The T.50 (1988) recommendation, which
  1633.     defines IA5, talks about ISO registered set number 2,
  1634.     while ASCII, using the "dollar" symbol, is ISO registered
  1635.     set number 6. There are no other differences.)
  1636.  
  1637.     NOTE: It is not uncommon, though it is a violation of the
  1638.     standard, to use 8-bit character sets inside an IA5 body
  1639.     part. Gateways that can expect to encounter this situation
  1640.     should consider implementing something like the guidance
  1641.     given in RFC 1428, "Transition of Internet Mail from just-
  1642.     send-8 to 8-bit SMTP/MIME", and generate appropriate
  1643.     charset parameters for the MIME messages they generate.
  1644.  
  1645.  
  1646.  
  1647.  
  1648.  
  1649. Alvestrand                Exp Nov 96                 [Page 30]
  1650.  
  1651. draft               X.400/MIME body mapping             May 96
  1652.  
  1653.  
  1654.     This behavior is not required for MIXER conformance, since
  1655.     it is only needed when the base standards are violated.
  1656.  
  1657.  
  1658.     6.2.  GeneralText - text/plain (ISO-8859)
  1659.  
  1660.     X.400 Body Part: GeneralText; CharacterSets in
  1661.                     6, 14, 42, 87, 100,101,109,110,126,127,138,144,148
  1662.     MIME Content-Type: text/plain; charset=ISO-8859-(1-9)
  1663.                                 or iso-2022-jp
  1664.     Conversion Type: Text conversion without character change
  1665.     When mapping from X.400 to MIME, the character-set is
  1666.     chosen from the table below according to the value of
  1667.     Parameters.CharacterSets. If no match is found, and the
  1668.     gateway does not support a conversion, the character set
  1669.     shall be encoded as x-iso-nnn-nnn-nnn, where "nnn" is the
  1670.     numbers of the Parameters.CharacterSets, sorted in numeric
  1671.     order.
  1672.  
  1673.     When mapping from MIME to X.400, GeneralText is an
  1674.     Extended Body Part, hence it requires an OID.  The OID for
  1675.     the GeneralText body is defined in [MOTIS], part 8, annex
  1676.     D, as {2 6 1 4 11}. The OID for the parameters is {2 6 1
  1677.     11 11}.
  1678.  
  1679.     The Parameters.CharacterSets is set from table below
  1680.     according to the value of "charset"
  1681.  
  1682.  
  1683.     The following table lists the MIME character sets and the
  1684.     corresponding ISO registry numbers. If no correspondence
  1685.     is found, this conversion fails, and the generic body part
  1686.     approach is used.
  1687.  
  1688.     MIME charset    ISO IR numbers          Comment
  1689.     -----------------------------------------------
  1690.     ISO-8859-1      6, 100                  West European "8-bit ASCII"
  1691.     ISO-8859-2      6, 101                  East European
  1692.     ISO-8859-3      6, 109                  <regarded as obsolete>
  1693.     ISO-8859-4      6, 110                  <regarded as obsolete>
  1694.     ISO-8859-5      6, 144                  Cyrillic
  1695.     ISO-8859-6      6, 127                  Arabic
  1696.     ISO-8859-7      6, 126                  Greek
  1697.     ISO-8859-8      6, 138                  Hebrew
  1698.     ISO-8859-9      6, 148                  Other Latin-using languages
  1699.  
  1700.  
  1701.  
  1702.  
  1703.  
  1704. Alvestrand                Exp Nov 96                 [Page 31]
  1705.  
  1706. draft               X.400/MIME body mapping             May 96
  1707.  
  1708.  
  1709.     ISO-2022-JP     6, 14, 42, 87           Japanese
  1710.  
  1711.     When converting from MIME to X.400, generate the correct
  1712.     OIDs for use in the message envelope's Encoded Information
  1713.     Types by looking up the ISO IR number in the above table,
  1714.     and then appending it to the id-cs-eit-authority {1 0
  1715.     10021 7 1 0} OID.
  1716.  
  1717.     The escape sequences to designate and invoke the relevant
  1718.     character sets in their proper positions must be added to
  1719.     the front of the GeneralText character string.
  1720.  
  1721.     For ISO 8859-1, the relevant escape sequence will be:
  1722.  
  1723.     ESC 28 42
  1724.          ASCII in G0
  1725.  
  1726.     ESC 2D 41
  1727.          ISO-IR-100 in G1
  1728.  
  1729.     ESC 21 41
  1730.          High control character set in C1
  1731.  
  1732.     ESC 7E
  1733.          Locking shift 1 Right
  1734.  
  1735.     These escape sequences are removed when converting from
  1736.     GeneralText to text/plain.
  1737.  
  1738.     Note that new character sets may be defined on both the
  1739.     Internet side and the X.400 side; a gateway MAY choose to
  1740.     implement more conversions in the same fashion.
  1741.  
  1742.     DISCUSSION:
  1743.  
  1744.     The conversion of text is a problematic one, and one in
  1745.     which it is likely that gateways should be given wide
  1746.     latitude to make decisions based upon their knowledge of
  1747.     the user's preferences. The text given below is thought to
  1748.     give the best approximation to a gateway conforming to
  1749.     current and anticipated usage in the MIME and X.400
  1750.     worlds, and is the way recommended when no knowledge of
  1751.     the recipient's capabilities exists.
  1752.  
  1753.     The changes, such as normalizing escape sequences, should
  1754.  
  1755.  
  1756.  
  1757.  
  1758.  
  1759. Alvestrand                Exp Nov 96                 [Page 32]
  1760.  
  1761. draft               X.400/MIME body mapping             May 96
  1762.  
  1763.  
  1764.     not be done when "conversion-prohibited" is set. If
  1765.     "conversion-with-loss-prohibited" is set, translation to a
  1766.     character set that is not able to encode all characters
  1767.     cannot be done, and the message should be non-delivered
  1768.     with an appropriate non-delivery reason.
  1769.  
  1770.  
  1771.     The common use of character sets in MIME is somewhat
  1772.     different from the rules given by X.400; in particular, it
  1773.     is common in MIME to assume that the character sets follow
  1774.     strict rules. For the ISO-8859-x character sets, it is
  1775.     assumed that they are designated and invoked at the
  1776.     beginning of the text, and that no designation or
  1777.     invocation sequences occur within the body of the text.
  1778.     The rules for ISO-2022-JP are given in RFC 1468, and are
  1779.     even more particular, using a pure 7-bit encoding in which
  1780.     each line of text starts in ASCII.
  1781.  
  1782.     Therefore, the text must be "normalized" by going through
  1783.     the whole message, using a state machine or similar device
  1784.     to remove all escape and shift sequences.
  1785.  
  1786.     Appendix A gives pseudocode for such a conversion.
  1787.  
  1788.     NOTE: In 1988, the GeneralText body part was defined in
  1789.     ISO 10021-8 [MOTIS], and NOT in the corresponding CCITT
  1790.     recommendation; this was added later.  Also, the
  1791.     parameters have been heavily modified; they should be a
  1792.     SET OF INTEGER in the currently valid text.  Use the
  1793.     latest version of the standard that you can get hold of.
  1794.  
  1795.  
  1796.     6.3.  BilaterallyDefined - application/octet-stream
  1797.  
  1798.     X.400 Body Part: BilaterallyDefined
  1799.     MIME Content-Type: Application/Octet-Stream (no parameters)
  1800.     Conversion Type: No conversion
  1801.  
  1802.     When mapping from MIME to X.400, if there are parameters
  1803.     present in the Content-Type: header field, they are
  1804.     removed.
  1805.  
  1806.     DISCUSSION:
  1807.  
  1808.     The parameters "name" "type" and "conversions" are
  1809.  
  1810.  
  1811.  
  1812.  
  1813.  
  1814. Alvestrand                Exp Nov 96                 [Page 33]
  1815.  
  1816. draft               X.400/MIME body mapping             May 96
  1817.  
  1818.  
  1819.     advisory; name and conversions are depreciated in RFC
  1820.     1521.
  1821.  
  1822.     The parameter "padding" changes the interpretation of the
  1823.     last byte of the data, but it is deemed better by the WG
  1824.     to delete this information than to non-deliver the body
  1825.     part. The "padding" parameter is rarely used with MIME.
  1826.  
  1827.  
  1828.     Use of BilaterallyDefined Body Parts is specifically
  1829.     deprecated in both 1988 and 1992 X.400.  It is retained
  1830.     solely for backward compatibility with 1984 systems, and
  1831.     because it is in common use.
  1832.  
  1833.  
  1834.     6.4.  FTBP EMA Unknown Attachment -
  1835.     application/octet-stream
  1836.  
  1837.     X.400 Body Part: FTBP EMA Unknown Attachment
  1838.     MIME Content-Type: Application/Octet-Stream
  1839.     Conversion Type: No conversion
  1840.  
  1841.     The OID for the Unknown Attachment is { joint-iso-ccitt(2)
  1842.     country(16) us(840) organization(1) ema(113694) objects(2)
  1843.     messaging(2) attachments(1) unknown(1) }, or
  1844.     2.16.840.1.113694.2.2.1.1 for short.
  1845.  
  1846.     NOTE: Previous EMA drafts gave it as { iso(1) countries(2)
  1847.     usa(840) organization (1) ema (113694) objects(2)
  1848.     messaging(2) attachments(1) unknown (1)}, or
  1849.     1.2.840.1.113694.2.2.1.1 for short.
  1850.  
  1851.     The parameters for this type must be mapped according to
  1852.     chapter 2.3, with the following extensions for the
  1853.     parameters of the application/octet-stream:
  1854.  
  1855.          If there is no Content-Disposition parameter with a
  1856.          filename, and there is a name parameter, the
  1857.          FTBP.FileTransferParameters.File-attributes.pathname
  1858.          is generated from this parameter. Note that RFC 1521
  1859.          recommends not using the "name" parameter.
  1860.  
  1861.  
  1862.     The "type", "conversions" and "padding" attributes are
  1863.     ignored; "type" is for human consumption; "conversions"
  1864.  
  1865.  
  1866.  
  1867.  
  1868.  
  1869. Alvestrand                Exp Nov 96                 [Page 34]
  1870.  
  1871. draft               X.400/MIME body mapping             May 96
  1872.  
  1873.  
  1874.     are discouraged in RFC 1521.
  1875.  
  1876.     The body mapping is just copying the bytes in both
  1877.     directions.
  1878.  
  1879.  
  1880.     6.5.  MessageBodyPart - message/RFC822
  1881.  
  1882.     X.400 body part: MessageBodyPart
  1883.     MIME Content-Type: message/RFC822
  1884.     Conversion Type: Special
  1885.  
  1886.     NOTE: If the headers of the X.400 MessageBodyPart contains the
  1887.     "multipart-message" heading extension with the isAMessage bit set
  1888.     (either explicitly or implicitly), the mapping should be to
  1889.     multipart/* according to section 6.6, below.
  1890.  
  1891.     To map an IPMS.MessageBodyPart, the full X.400 -> RFC 822
  1892.     mapping  is recursively applied, to generate an RFC 822 Message.
  1893.     If present, the IPMS.MessageBodyPart.parameters.delivery-envelope
  1894.     is used for the MTS Abstract Service Mappings.  If present, the
  1895.     IPMS.MessageBodyPart.parameters.delivery-time is mapped to the
  1896.     extended RFC 822 field "Delivery-Date:".
  1897.  
  1898.     When a message/RFC822 is contained within a MIME message, it is
  1899.     mapped to an IPMS.MessageBodyPart according to MIXER.
  1900.     specification.  Any mappings that would have been made to the MTS
  1901.     Abstract Service are placed in
  1902.     IPMS.MessageBodyPart.parameters.delivery-envelope.
  1903.  
  1904.  
  1905.     6.6.  MessageBodyPart - multipart/*
  1906.  
  1907.     X.400 body part: MessageBodyPart
  1908.     MIME Content-Type: multipart/*
  1909.     Conversion Type: Special
  1910.  
  1911.     NOTE: If the headers of the X.400 MessageBodyPart do not contain the
  1912.     "multipart-message" heading extension with the "isAMessage" flag FALSE,
  1913.     the mapping should be to message/RFC822.
  1914.  
  1915.     A MIME multipart is a set of content-types and not a message with
  1916.     a set of content types. When the multipart is at the outermost
  1917.     MIME header, elements of the multipart are mapped directly onto
  1918.     IPMS.Bodypart.
  1919.  
  1920.  
  1921.  
  1922.  
  1923.  
  1924. Alvestrand                Exp Nov 96                 [Page 35]
  1925.  
  1926. draft               X.400/MIME body mapping             May 96
  1927.  
  1928.  
  1929.     When the MIME multipart is not at the outermost level, it is mapped to
  1930.     an IPMS.MessageBodyPart containing an IPMS.Bodypart for each element
  1931.     of the multipart.
  1932.  
  1933.     When a nested IPMS.Message is generated from a multipart, an
  1934.     IPMS.heading shall always be generated.  The only mandatory field
  1935.     is the IPMS.Heading.this-IPM message id, which shall be generated
  1936.     by the gateway.  An IPMS.Heading.subject field shall also be
  1937.     generated, in order to provide useful information to non-MIME
  1938.     capable X.400(88) UAs and to all X.400(84) UAs.  The subject
  1939.     field is set as follows according to the multipart subtype:
  1940.  
  1941.  
  1942.     mixed:
  1943.          "Multipart Message"
  1944.  
  1945.     alternative:
  1946.          "Alternative Body Parts containing the same
  1947.          information"
  1948.  
  1949.     digest:
  1950.          "Message Digest"
  1951.  
  1952.     parallel:
  1953.          "Body Parts interpreted in parallel"
  1954.  
  1955.     other:
  1956.          "Multipart Message (<subtype>)"
  1957.  
  1958.     For other types of multipart, the multipart subtype shall
  1959.     be included in the subject line.
  1960.  
  1961.     For each multipart, the following IPMS.HeadingExtension
  1962.     shall be generated, with the value set according to the
  1963.     subtype.
  1964.     If the multipart is the outermost multipart, and the
  1965.     subtype is "mixed", it may be omitted.
  1966.  
  1967.             multipart-message HEADING-EXTENSION
  1968.                     VALUE MultipartType
  1969.                     ::= id-hex-multipart-message
  1970.  
  1971.             MultipartType ::= SEQUENCE {
  1972.                       subtype IA5String,
  1973.                       isAMessage BOOLEAN DEFAULT TRUE }
  1974.  
  1975.  
  1976.  
  1977.  
  1978.  
  1979. Alvestrand                Exp Nov 96                 [Page 36]
  1980.  
  1981. draft               X.400/MIME body mapping             May 96
  1982.  
  1983.  
  1984.     The MultipartType contains the subtype, for example
  1985.     "digest".  If this heading is present when mapping from
  1986.     X.400 to MIME, the appropriate multipart may be generated.
  1987.  
  1988.     The isAMessage flag is needed because of the case where a
  1989.     message contains a ForwardedIPMessage, which itself was
  1990.     generated from a MIME message that was a Multipart; it is
  1991.     set whenever the multipart is the outermost level of
  1992.     nesting inside a Message/RFC822.
  1993.  
  1994.  
  1995.     NOTE:
  1996.          When downgrading to X.400/84, the content-type SHOULD
  1997.          be regenerated from this heading-extension and put
  1998.          into the RFC-822-HEADERS extra body part.
  1999.  
  2000.  
  2001.  
  2002.  
  2003.     6.7.  Teletex - Text/Plain (Teletex)
  2004.  
  2005.     X.400 Body Part: Teletex
  2006.     MIME Content-Type: text/plain; charset=Teletex
  2007.     Conversion Type: Text conversion
  2008.  
  2009.     From X.400 to RFC-822, the conversion shall take the bytes
  2010.     of all the pages in the "data" part of the
  2011.     TeletexBodyPart, add a FF character (0x0C, control-L) to
  2012.     each part that does not already end in one, and
  2013.     concatenate them together to form the body of the
  2014.     Text/Plain.
  2015.  
  2016.     The character set shall be "Teletex", which is especially
  2017.     registered for this purpose. Its definition is shown in an
  2018.     appendix.
  2019.  
  2020.     The parameters are discarded.
  2021.  
  2022.     From RFC-822 to X.400, the conversion shall split the
  2023.     content at each occurrence of the FF character (0x0C),
  2024.     delete the character and construct the Teletex body part
  2025.     as a SEQUENCE OF TeletexString, as described in X.420(88),
  2026.     section 7.3.5
  2027.  
  2028.     The TeletexParameters may, but need not, contain the
  2029.  
  2030.  
  2031.  
  2032.  
  2033.  
  2034. Alvestrand                Exp Nov 96                 [Page 37]
  2035.  
  2036. draft               X.400/MIME body mapping             May 96
  2037.  
  2038.  
  2039.     number-of-pages component.
  2040.  
  2041.     NOTE: It is recommended, but not mandated, that the data
  2042.     be converted into a more widespread character set like
  2043.     ISO-8859-1 or ISO-2022-JP (if applicable) if possible.
  2044.     This will result in the reverse translation giving a
  2045.     GeneralText body part, which will have to be dealt with
  2046.     appropriately at the X.400/88 to X.400/84 downgrading
  2047.     boundary, if possible, but will give a much greater chance
  2048.     that the MIME recipient can actually read the message.
  2049.  
  2050.     DISCUSSION:
  2051.  
  2052.     The Teletex body part is frequently used in X.400(84) to
  2053.     send around text with slightly extended character sets
  2054.     beyond ASCII.
  2055.  
  2056.     Its body consists of a series of "pages", separated by
  2057.     ASN.1 representation.  It is important to many people to
  2058.     have this mapped into something that is readable to most
  2059.     end-users; therefore, it is recommended to map this onto
  2060.     Text/Plain; however, since this is not plain text, the
  2061.     conversion must be specified.
  2062.  
  2063.  
  2064.  
  2065.  
  2066.  
  2067.  
  2068.  
  2069.  
  2070.  
  2071.  
  2072.  
  2073.  
  2074.  
  2075.  
  2076.  
  2077.  
  2078.  
  2079.  
  2080.  
  2081.  
  2082.  
  2083.  
  2084.  
  2085.  
  2086.  
  2087.  
  2088.  
  2089. Alvestrand                Exp Nov 96                 [Page 38]
  2090.  
  2091. draft               X.400/MIME body mapping             May 96
  2092.  
  2093.  
  2094.     7.  Body parts where encapsulation is recommended
  2095.  
  2096.     Some body parts are MIME constructs, and their
  2097.     functionality will be severely damaged if they are coerced
  2098.     into an X.400 framework.
  2099.  
  2100.     Special care needs to be taken with these; they are
  2101.     described below.
  2102.  
  2103.  
  2104.     7.1.  message/external-body
  2105.  
  2106.     The gateway MUST support the encapsulation of this body
  2107.     part using the HARPOON encapsulation (IA5).
  2108.  
  2109.     It MAY support some kind of retrieval of the referred
  2110.     object.
  2111.  
  2112.     DISCUSSION:
  2113.  
  2114.     The message/external-body part points to an object that
  2115.     can be retrieved using Internet protocols.
  2116.  
  2117.     There are three cases to consider for the recipient's
  2118.     capabilities:
  2119.  
  2120.  
  2121.      (1)   The user has no Internet access. In this case, the
  2122.            user might be grateful if the gateway fetches the
  2123.            body part and inserts it into the message. If the
  2124.            body part is large or dynamic, it might not be
  2125.            appropriate.
  2126.  
  2127.      (2)   The user has Internet access, but no UA support for
  2128.            fetching external-body objects.
  2129.  
  2130.      (3)   The user has Internet access and UA support for
  2131.            fetching external-body objects, based on an
  2132.            understanding of this document.
  2133.  
  2134.  
  2135.     Some access-types, like anonymous FTP, are easy to
  2136.     resolve. Others, like the Mailserver access-type, are
  2137.     almost impossible to resolve at a gateway.
  2138.  
  2139.  
  2140.  
  2141.  
  2142.  
  2143.  
  2144. Alvestrand                Exp Nov 96                 [Page 39]
  2145.  
  2146. draft               X.400/MIME body mapping             May 96
  2147.  
  2148.  
  2149.     To support the second case above, the tunneling method
  2150.     chosen is the HARPOON encapsulation described in section
  2151.     3.1.3, using an IA5 body part, inserting the string "MIME-
  2152.     Version: 1.0 (generated by gateway)" at the beginning of
  2153.     the body part. (The part in parentheses can be changed at
  2154.     will).
  2155.  
  2156.     This will:
  2157.  
  2158.  
  2159.      (1)   Maximize the chance that the user will see the
  2160.            message
  2161.  
  2162.      (2)   Give the user hints that will enable him to fetch
  2163.            the message using other Internet tools
  2164.  
  2165.      (3)   Identify the message as a MIME object in a reliable
  2166.            fashion, allowing UAs to support the fetching of
  2167.            the object if the UA implementor desires.
  2168.  
  2169.  
  2170.     7.2.  message/partial
  2171.  
  2172.     This represents part of a larger message, where it is only
  2173.     possible to parse the complete message after getting all
  2174.     the pieces.
  2175.  
  2176.     The gateway MUST support the encapsulation of this body
  2177.     part.
  2178.  
  2179.     It MAY implement transparent reassembly of the message,
  2180.     but in this case, it MUST support a configurable timeout
  2181.     for the reassembly, defaulting back to encapsulation.
  2182.  
  2183.     DISCUSSION:
  2184.  
  2185.     The gateway's choices are:
  2186.  
  2187.  
  2188.      (1)   Wait until all the pieces arrive at the gateway,
  2189.            reassemble the message, and use normal processing
  2190.  
  2191.      (2)   Encapsulate the message, using any encapsulation
  2192.            method (BP15, FTAM or HARPOON).
  2193.  
  2194.  
  2195.  
  2196.  
  2197.  
  2198.  
  2199. Alvestrand                Exp Nov 96                 [Page 40]
  2200.  
  2201. draft               X.400/MIME body mapping             May 96
  2202.  
  2203.  
  2204.     In some cases, not all pieces will arrive at the gateway;
  2205.     some may have been transferred through other gateways due
  2206.     to route changes or machine outages; some may have been
  2207.     lost in transit.
  2208.  
  2209.  
  2210.     7.3.  multipart/signed
  2211.  
  2212.     A gateway MUST implement encapsulation of multipart/signed
  2213.     using HARPOON.
  2214.  
  2215.     The gateway MAY be configured to do other processing, as
  2216.     outlined in the discussion below. This is outside the
  2217.     scope of the standard.
  2218.  
  2219.     DISCUSSION:
  2220.  
  2221.     Gatewaying security is a problem.  The gateway can
  2222.     basically take three approaches:
  2223.  
  2224.  
  2225.     -    Strip the multipart/signed, leaving the bare body
  2226.          part unsecured, possibly with a comment that the
  2227.          signature was stripped
  2228.  
  2229.     -    Attempt to check the signature and re-signing the
  2230.          message using X.400 security functions, then
  2231.          stripping as above
  2232.  
  2233.     -    Encapsulate the message. This is the only approach
  2234.          that allows end to end security, but requires MIME
  2235.          functionality at the recipient.
  2236.  
  2237.     -    Replace the message content with multiple body parts,
  2238.          containing first an unsecured body part and then the
  2239.          encapsulated multipart/signed.
  2240.  
  2241.  
  2242.     All these are valid options for a MIXER gateway.
  2243.  
  2244.     Note that the encapsulation must use HARPOON, as the
  2245.     signature is computed on the ENCODED body part, not on the
  2246.     canonical representation, and HARPOON is the only
  2247.     encapsulation that preserves the content transfer encoding
  2248.     of the message.
  2249.  
  2250.  
  2251.  
  2252.  
  2253.  
  2254. Alvestrand                Exp Nov 96                 [Page 41]
  2255.  
  2256. draft               X.400/MIME body mapping             May 96
  2257.  
  2258.  
  2259.     Note also that all methods except for encapsulation break
  2260.     end-to-end security; the recipient can place no more trust
  2261.     in the integrity of the message than he can place in the
  2262.     security of the gateway.
  2263.  
  2264.  
  2265.     7.4.  multipart/encrypted
  2266.  
  2267.     A gateway MUST implement encapsulation of
  2268.     multipart/encrypted using HARPOON.
  2269.  
  2270.     If the implementor chooses to allow other processing at
  2271.     the gateway, as outlined below, he/she is advised that
  2272.     there are grave security concerns with such a solution,
  2273.     since it violates the general rule of keeping decryption
  2274.     keys as close to the user as possible.
  2275.  
  2276.  
  2277.     DISCUSSION:
  2278.  
  2279.     There are two basic cases for a gateway:
  2280.  
  2281.  
  2282.     -    The gateway is trusted with the user's keys. In this
  2283.          case, the gateway can decrypt the message, possibly
  2284.          add a note that it has done so, and gateway the
  2285.          unencrypted form, possibly applying X.400 security
  2286.          functions, and possibly attaching a copy of the
  2287.          original, encrypted material for reference.
  2288.          This does nothing to protect the transfer from
  2289.          gateway to recipient, unless suitable X.400-native
  2290.          security is applied. It also means that the gateway
  2291.          must be part of the user's trusted environment.
  2292.  
  2293.     -    The gateway is not trusted with the recipient's keys.
  2294.          In this case, encapsulation is the only approach that
  2295.          preserves any information at all.
  2296.  
  2297.  
  2298.     The valid options for a MIXER gateway are therefore:
  2299.  
  2300.     -    Decrypt the body part
  2301.  
  2302.     -    Encapsulate the body part
  2303.  
  2304.  
  2305.  
  2306.  
  2307.  
  2308.  
  2309. Alvestrand                Exp Nov 96                 [Page 42]
  2310.  
  2311. draft               X.400/MIME body mapping             May 96
  2312.  
  2313.  
  2314.     -    Drop the body part
  2315.  
  2316.  
  2317.     The MIXER WG has shown strong preference for the
  2318.     encapsulation alternative, and urges anyone who thinks of
  2319.     buying or implementing gateway decryption to carefully
  2320.     evaluate this choice in light of the company's general
  2321.     security policy.
  2322.  
  2323.  
  2324.  
  2325.     8.  Conformance requirements
  2326.  
  2327.     In order to be called MIXER conformant, a gateway must
  2328.     implement:
  2329.  
  2330.  
  2331.     -    Encapsulation of MIME content in the FTBP body part
  2332.  
  2333.     -    Encapsulation of X.400 body parts in the x400-bp body
  2334.          part
  2335.  
  2336.     -    Encapsulation of FTBP body parts in the
  2337.          application/x-oid.n.n.n body part
  2338.  
  2339.     -    Encapsulation of security multiparts using HARPOON
  2340.  
  2341.     -    Text/plain <-> IA5Text
  2342.  
  2343.     -    Text/plain; charset=iso-8859-* <-> GeneralText
  2344.  
  2345.     -    Multipart/* <-> ForwardedIPMessage
  2346.  
  2347.     -    message/RFC822 <-> ForwardedIPMessage
  2348.  
  2349.     -    application/octet-stream <-> FTBP unknown
  2350.  
  2351.     -    application/octet-stream <-> BilaterallyDefined
  2352.  
  2353.     -    A configuration choice of which application/octet-
  2354.          stream translation to use
  2355.  
  2356.  
  2357.     All other parts of this specification MAY be implemented
  2358.     by the gateway. If they are implemented at all, they MUST
  2359.  
  2360.  
  2361.  
  2362.  
  2363.  
  2364. Alvestrand                Exp Nov 96                 [Page 43]
  2365.  
  2366. draft               X.400/MIME body mapping             May 96
  2367.  
  2368.  
  2369.     be implemented conformant to this specification.
  2370.  
  2371.     In this context, a feature is "implemented" in a product
  2372.     if it is possible to configure the product in such a way
  2373.     that this feature is used. This specification does not
  2374.     restrict the product to only be configured in such a
  2375.     fashion.
  2376.  
  2377.  
  2378.     9.  Security considerations
  2379.  
  2380.     The security issues identified in this memo are:
  2381.  
  2382.      (1)   Security implications of using filenames that
  2383.            arrive in body part headers (section 2.3.2)
  2384.  
  2385.      (2)   Security implications of letting a gateway handle
  2386.            encrypted and/or signed content (section 7.3 and
  2387.            7.4)
  2388.  
  2389.     If a gateway fetches message/external-body on behalf of
  2390.     the recipient, as described in section 7.1, it may be
  2391.     tricked into performing inappropriate actions by malicious
  2392.     senders.
  2393.  
  2394.     In addition, all the normal caveats that apply to sending
  2395.     data that may contain executable code apply to UAs on both
  2396.     sides of the gateway.
  2397.  
  2398.  
  2399.  
  2400.     10.  Author's address
  2401.  
  2402.     Harald Tveit Alvestrand
  2403.     UNINETT
  2404.     P.O.box 6883 Elgeseter
  2405.     N-7002 Trondheim
  2406.     NORWAY
  2407.  
  2408.     Harald.T.Alvestrand@uninett.no
  2409.  
  2410.  
  2411.  
  2412.  
  2413.  
  2414.  
  2415.  
  2416.  
  2417.  
  2418.  
  2419. Alvestrand                Exp Nov 96                 [Page 44]
  2420.  
  2421. draft               X.400/MIME body mapping             May 96
  2422.  
  2423.  
  2424.     11.  Acknowledgements
  2425.  
  2426.     The author wishes to thank all the members of the MIXER WG
  2427.     for their valuable input, and in particular (in no
  2428.     particular order):
  2429.  
  2430.     Steve Kille, Peter Sylvester, Ned Freed, Julian Onions,
  2431.     Ruth Moulton, Keith Moore, Alain Zahm, Urs Eppenberger,
  2432.     Kevin Jordan, Jeroen Houttuin, Claudio Allocchio, Colin
  2433.     Robbins, Steven Thomson, Jim Craigie,
  2434.  
  2435.     and many others who have been active over the long
  2436.     lifetime of this document.
  2437.  
  2438.  
  2439.     References
  2440.  
  2441.     [RFC-822]
  2442.          D.H. Crocker, Standard for the Format of ARPA
  2443.          Internet Text Messages.  Request for Comments 822,
  2444.          (August, 1982).
  2445.  
  2446.     [MIME]
  2447.          N. Borenstein, N. Freed, MIME: Mechanisms for
  2448.          Specifying and Describing the Format of Internet
  2449.          Message Bodies.  Request for Comments 1521, (June,
  2450.          1992).
  2451.  
  2452.     [MIXER]
  2453.          S.E. Kille, Mapping between X.400(1988) / ISO 10021
  2454.          and RFC-822. (in preparation)
  2455.  
  2456.     [T.4]
  2457.          CCITT Recommendation T.4, Standardization of Group 3
  2458.          Facsimile Apparatus for Document Transmission (1988)
  2459.  
  2460.     [T.30]
  2461.          CCITT Recommendation T.30, Procedures For Document
  2462.          Facsimile Transmission in the General Switched
  2463.          Telephone Network (1988)
  2464.  
  2465.     [T.411]
  2466.          CCITT Recommendation T.411 (1988), Open Document
  2467.          Architecture (ODA) and Interchange Format,
  2468.          Introduction and General Principles
  2469.  
  2470.  
  2471.  
  2472.  
  2473.  
  2474. Alvestrand                Exp Nov 96                 [Page 45]
  2475.  
  2476. draft               X.400/MIME body mapping             May 96
  2477.  
  2478.  
  2479.     [MOTIS]
  2480.          ISO/IEC International Standard 10021, Information
  2481.          technology - Text Communication - Message-Oriented
  2482.          Text Interchange Systems (MOTIS) (Parts 1 to 8)
  2483.  
  2484.     [X.400]
  2485.          CCITT, Data Communication Networks - Message Handling
  2486.          Systems - Recommendations X.400 - X.420 (1988
  2487.          version)
  2488.  
  2489.     [X.420]
  2490.          CCITT Recommendation X.420 (1988), Interpersonal
  2491.          Messaging System
  2492.  
  2493.     [RFC-X400USE]
  2494.          Harald Tveit Alvestrand, X.400 use of extended
  2495.          Character Sets, Internet Draft, June 1992
  2496.  
  2497.     [MAWG]
  2498.          Electronic Messaging Association Message Attachment
  2499.          Working Group (MAWG): File Transfer Body Part
  2500.          Feasibility Project Guide - version 1.5 - September
  2501.          1995
  2502.  
  2503.     [CDISP]
  2504.          Dorner & Troost, The Content-Disposition header - RFC
  2505.          1806
  2506.  
  2507.     [POSTSCRIPT]
  2508.          Harald Tveit Alvestrand, Carrying PostScript in X.400
  2509.          and MIME, Work In Progress (draft-ietf-mixer-
  2510.          postscript-00.txt)
  2511.  
  2512.     [IMAGES]
  2513.          Harald Tveit Alvestrand, X.400 image body parts, Work
  2514.          In Progress (draft-ietf-mixer-images-00.txt)
  2515.  
  2516.     [ODA]
  2517.          Harald Tveit Alvestrand, A MIME body part for ODA,
  2518.          Work in Progress (draft-ietf-mixer-oda-00.txt)
  2519.  
  2520.  
  2521.  
  2522.  
  2523.  
  2524.  
  2525.  
  2526.  
  2527.  
  2528.  
  2529. Alvestrand                Exp Nov 96                 [Page 46]
  2530.  
  2531. draft               X.400/MIME body mapping             May 96
  2532.  
  2533.  
  2534.     APPENDIXES
  2535.  
  2536.  
  2537.     Appendix A: Escape code normalization
  2538.  
  2539.     The algorithm given here in pseudocode will reduce a
  2540.     GeneralString ISO-2022 unlimited use of shifts sequence to
  2541.     a pure 8-bit sequence that does not use shift sequences,
  2542.     if possible.
  2543.  
  2544.     Some error conditions, like EOF, are not tested for. It
  2545.     crashes if asked to do something it cannot.  Control
  2546.     character set switching is missing.
  2547.  
  2548.     A similar routine, albeit more complex, can be written for
  2549.     normalizing to the ISO-2022-JP character set.
  2550.  
  2551.     BEGIN: (from X.209)
  2552.       g0 = 6 (should be 2, but ignore the difference)
  2553.       g1 = NULL
  2554.       g2 = NULL
  2555.       g3 = NULL
  2556.       c0 = 1 (ASCII control)
  2557.       c1 = NULL
  2558.       leftset = &g0 (current input set, low)
  2559.       rightset = &g1 (current input set, high)
  2560.       lowset = 6 (output set, low)
  2561.       highset = NULL (output set, high)
  2562.       charset = US-ASCII
  2563.  
  2564.       (Init for the set tables)
  2565.       chartoid[{2D,2E,2F}, 41] = 100
  2566.       .....
  2567.       idtoname[100] = "ISO-8859-1"
  2568.       .....
  2569.  
  2570.     WHILE (more data)
  2571.       CASE head of input
  2572.         {These are the locking shift sequences}
  2573.         INCASE "00/14": (LS0, SO)
  2574.             leftset = &g0;
  2575.         INCASE "00/15": (LS1, SI)
  2576.             leftset = &g
  2577.         INCASE "ESC 07/14": (LS1R)
  2578.             rightset = &g1;
  2579.  
  2580.  
  2581.  
  2582.  
  2583.  
  2584. Alvestrand                Exp Nov 96                 [Page 47]
  2585.  
  2586. draft               X.400/MIME body mapping             May 96
  2587.  
  2588.  
  2589.         INCASE "ESC 07/13": (LS2R)
  2590.             rightset = &g2;
  2591.         INCASE "ESC 07/12": (LS3R)
  2592.             rightset = &g3;
  2593.         {There is missing code for handling the single shift function}
  2594.         {These are the changes of graphic character sets}
  2595.         {Note that G0 can contain only 94-character charsets}
  2596.         INCASE "ESC 28"
  2597.             g0 = chartoid[lastchar, next character]
  2598.             sethiset(g0)
  2599.         INCASE "ESC 2D", "ESC 29"
  2600.             g1 = chartoid[lastchar, next character]
  2601.             sethiset(g1)
  2602.         INCASE "ESC 2E", "ESC 2A"
  2603.             g2 = chartoid[lastchar, next character]
  2604.             sethiset(g2)
  2605.         INCASE "ESC 2F", "ESC 2B"
  2606.             g3 = chartoid[lastchar, next character]
  2607.             sethiset(g3)
  2608.         {control characters. There is missing code for changing these}
  2609.         INCASE 00/00-01/15 {normal control}
  2610.             write(char)
  2611.         INCASE 08/00-09/15 {upper control}
  2612.             write(char)
  2613.         {Normal characters}
  2614.         INCASE 02/00-07/15 (Left)
  2615.             IF (*leftset == lowset)
  2616.                 write(char)
  2617.             ELSIF (*leftset == highset)
  2618.                 write(char+80)
  2619.             ELSE
  2620.                 ERROR "Shift error"
  2621.             ENDIF
  2622.         INCASE 10/00-15/15
  2623.             IF (*rightset == highset)
  2624.                 write(char)
  2625.             ELSIF (*rightset == lowset)
  2626.                 write(char-80)
  2627.             ELSE
  2628.                 ERROR "Shift error"
  2629.             ENDIF
  2630.       ENDCASE
  2631.     ENDWHILE
  2632.  
  2633.     SUBROUTINE sethighset(g1)
  2634.  
  2635.  
  2636.  
  2637.  
  2638.  
  2639. Alvestrand                Exp Nov 96                 [Page 48]
  2640.  
  2641. draft               X.400/MIME body mapping             May 96
  2642.  
  2643.  
  2644.             IF (highset == NULL)
  2645.                 charset = idtoname[g1]
  2646.                 highset = g1
  2647.             ELSIF (highset == g1)
  2648.                 (it's OK)
  2649.             ELSE
  2650.                 ERROR "Too many charsets encountered"
  2651.             ENDIF
  2652.  
  2653.     ENDROUTINE
  2654.  
  2655.  
  2656.  
  2657.     Appendix B: OID Assignments
  2658.     MIXER-MAPPINGS DEFINITIONS ::= BEGIN
  2659.     EXPORTS -- everything --;
  2660.  
  2661.     IMPORTS
  2662.        experimental
  2663.            FROM RFC1155-SMI;
  2664.        mixer -- { iso(1) org(3) dod(6) internet(1) mail(7) mixer(1) }
  2665.            FROM MIXER --Companion RFC--;
  2666.  
  2667.     mixer-bp-data OBJECT IDENTIFIER ::=
  2668.             { mixer 1 };
  2669.  
  2670.     mixer-bp-parameter OBJECT IDENTIFIER ::=
  2671.             { mixer 2 };
  2672.  
  2673.     -- mixer-core is defined as { mixer core(3) } in [MIXER]
  2674.     mixer-bp-heading OBJECT IDENTIFIER ::=
  2675.             { mixer 4 }
  2676.  
  2677.     id-mime-bp-data OBJECT IDENTIFIER ::=
  2678.             { mixer-bp-data 1};
  2679.  
  2680.     id-mime-bp-parameters OBJECT IDENTIFIER ::=
  2681.             { mixer-bp-parameter 1};
  2682.  
  2683.     -- the following assignments were done in RFC 1494, using
  2684.     -- slightly different names, but the same numbers.
  2685.     -- their defining text is now is now in other documents
  2686.     id-mime-postscript-body OBJECT IDENTIFIER ::=
  2687.                    { mixer-bp-data 2}
  2688.  
  2689.  
  2690.  
  2691.  
  2692.  
  2693.  
  2694. Alvestrand                Exp Nov 96                 [Page 49]
  2695.  
  2696. draft               X.400/MIME body mapping             May 96
  2697.  
  2698.  
  2699.     id-mime-jpeg-body OBJECT IDENTIFIER ::=
  2700.                    { mixer-bp-data 3}
  2701.  
  2702.     id-mime-gif-body OBJECT IDENTIFIER ::=
  2703.                    { mixer-bp-data 4};
  2704.  
  2705.     -- This is a new definition, and defines an FTAM application reference,
  2706.     -- not a BP15 data OID.
  2707.     id-mime-ftbp-data OBJECT IDENTIFIER ::=
  2708.                    { mixer-bp-data 5 }
  2709.  
  2710.  
  2711.  
  2712.  
  2713.  
  2714.  
  2715.  
  2716.  
  2717.  
  2718.  
  2719.  
  2720.  
  2721.  
  2722.  
  2723.  
  2724.  
  2725.  
  2726.  
  2727.  
  2728.  
  2729.  
  2730.  
  2731.  
  2732.  
  2733.  
  2734.  
  2735.  
  2736.  
  2737.  
  2738.  
  2739.  
  2740.  
  2741.  
  2742.  
  2743.  
  2744.  
  2745.  
  2746.  
  2747.  
  2748.  
  2749. Alvestrand                Exp Nov 96                 [Page 50]
  2750.  
  2751. draft               X.400/MIME body mapping             May 96
  2752.  
  2753.  
  2754.     Appendix C: Registration information for the Teletex
  2755.     character set
  2756.  
  2757.     The Teletex character set is a character set in which the
  2758.     ISO 2022 character set switching mechanism may be used to
  2759.     switch between the following registered ISO character
  2760.     sets:
  2761.  
  2762.     ISO-IR-87 - JIS_C6226-1983; a 16-bit Japanese character set
  2763.     ISO-IR-102 - a fairly standard US-ASCII variant
  2764.     ISO-IR-103 - Latin characters using non-spacing accents
  2765.     ISO-IR-106 - Control characters for C0 use; CR, LF, FF and a few more.
  2766.     ISO-IR-107 - Control characters for C1 use
  2767.  
  2768.     Its intended use of this character set is to represent
  2769.     data that comes from ISO protocols that use the ASN.1
  2770.     construct "TeletexString" or "T61string" without
  2771.     conversion.
  2772.  
  2773.     The set of allowed character sets can be found in CCITT
  2774.     recommendation X.208(1988), chapter 31.2 and Table
  2775.     6/X.208.
  2776.  
  2777.     The rules for encoding the data type can be found in CCITT
  2778.     recommendation X.209(1988), chapter 23. It states that at
  2779.     the beginning of the string, G0 is always ISO-IR-102, C0
  2780.     is ISO-IR-106, and C1 is ISO-IR-107.
  2781.  
  2782.     The specification seems somehow to have missed the
  2783.     implicit assumption that ISO-IR-103 is designated and
  2784.     invoked as G1 and shifted into the upper half of the
  2785.     character set which seems to be assumed at least by the
  2786.     X.400 and X.500 software that uses TeletexStrings;
  2787.     implementors should act as if the sequence ESC 2/9 7/6
  2788.     LS1R is always present at the beginning of the data.
  2789.  
  2790.     The rules for interpreting T.61 data are found (I believe)
  2791.     in CCITT recommendations T.51, T.52 and T.53 (data from
  2792.     the ITU WWW server):
  2793.  
  2794.  
  2795.  
  2796.  
  2797.  
  2798.  
  2799.  
  2800.  
  2801.  
  2802.  
  2803.  
  2804. Alvestrand                Exp Nov 96                 [Page 51]
  2805.  
  2806. draft               X.400/MIME body mapping             May 96
  2807.  
  2808.  
  2809.         T.51 (09/92) [Rev.1] [26 pp.] [Publ.: May.93]
  2810.            Latin based coded character sets for telematic services
  2811.         T.52 (1993) [New] [88 pp.] [Publ.: Apr.94]
  2812.            Non-Latin coded character sets for telematic services
  2813.         T.53 (04/94) [New] [68 pp.] [Publ.: Jan.95]
  2814.            Character coded control functions for telematic services
  2815.  
  2816.  
  2817.  
  2818.     The Teletex character set is closely related to (but not
  2819.     identical with) that specified in ISO 6937.
  2820.  
  2821.     No further restrictions are imposed by this registration;
  2822.     in particular, character set switching can occur anywhere,
  2823.     and there is no guarantee that the character sets will be
  2824.     switched "back" at the end.
  2825.  
  2826.  
  2827.  
  2828.  
  2829.  
  2830.  
  2831.  
  2832.  
  2833.  
  2834.  
  2835.  
  2836.  
  2837.  
  2838.  
  2839.  
  2840.  
  2841.  
  2842.  
  2843.  
  2844.  
  2845.  
  2846.  
  2847.  
  2848.  
  2849.  
  2850.  
  2851.  
  2852.  
  2853.  
  2854.  
  2855.  
  2856.  
  2857.  
  2858.  
  2859. Alvestrand                Exp Nov 96                 [Page 52]
  2860.  
  2861. draft               X.400/MIME body mapping             May 96
  2862.  
  2863.  
  2864.  
  2865.     Appendix D: IANA Registration form for new mappings
  2866.  
  2867.     To: IANA@isi.edu
  2868.     Subject: Registration of new X.400/MIME content type mapping
  2869.  
  2870.     MIME type name:
  2871.  
  2872.     (this must have been registered previously with IANA)
  2873.  
  2874.     X.400 body part:
  2875.  
  2876.     IF BP15:
  2877.  
  2878.     - X.400 Object Identifier for Data:
  2879.  
  2880.     (If left empty, an OID will be assigned by IANA  under
  2881.     mixer-bp-data)
  2882.  
  2883.     - X.400 Object Identifier for Parameters:
  2884.  
  2885.     (If  left empty, an OID will be assigned by IANA under
  2886.     mixer-bp-parameter.  If it is not used,  fill  in  the
  2887.     words NOT USED.)
  2888.  
  2889.     X.400 ASN.1 Syntax:
  2890.  
  2891.     (must  be  an EXTENDED-BODY-PART-TYPE macro, or refer¡
  2892.     ence to a Basic body part type)
  2893.  
  2894.     IF FTBP:
  2895.  
  2896.     - FTAM Object Identifier for application-reference:
  2897.  
  2898.     - FTAM Object Identifier for contents-type:
  2899.  
  2900.     (if left empty, unstructured-binary is assumed)
  2901.  
  2902.     Conversion algorithm:
  2903.  
  2904.     (must be defined completely enough for independent im¡
  2905.     plementation. It may be defined by reference to RFCs).
  2906.  
  2907.     Person & email address to contact for further informa¡
  2908.     tion:
  2909.  
  2910.  
  2911.  
  2912.  
  2913.  
  2914. Alvestrand                Exp Nov 96                 [Page 53]
  2915.  
  2916. draft               X.400/MIME body mapping             May 96
  2917.  
  2918.  
  2919.     INFORMATION TO THE SUBMITTER:
  2920.  
  2921.     The  accepted registrations will be listed in the "As¡
  2922.     signed Numbers" series of RFCs.   The  information  in
  2923.     the registration form is freely distributable.
  2924.  
  2925.  
  2926.  
  2927.     Table of Contents
  2928.  
  2929.  
  2930.      Status of this Memo ................................    1
  2931.     1 Introduction ......................................    2
  2932.     1.1 Glossary ........................................    2
  2933.     2 Basic rules for body part conversion ..............    3
  2934.     2.1 Generating the IPM Body from MIME ...............    5
  2935.     2.2 Generating the MIME Body from the IPMS.Body .....    5
  2936.     2.3 Mapping the EMA FTBP parameters .................    7
  2937.     2.3.1 Mapping GraphicStrings ........................    7
  2938.     2.3.2 Mapping specific parameters ...................    8
  2939.     2.3.3 Summary of FTBP elements generated ............   11
  2940.     2.4 Information that is lost when mapping ...........   12
  2941.     3 Encapsulation of body parts .......................   13
  2942.     3.1 Encapsulation of MIME in X.400 ..................   13
  2943.     3.1.1 FTBP encapsulating body part ..................   14
  2944.     3.1.2 BP15 encapsulating body part ..................   15
  2945.     3.1.3 Encapsulation using IA5 (HARPOON) .............   17
  2946.     3.1.4 Content passing using BP14 ....................   18
  2947.     3.2 Encapsulating X.400 Body Parts in MIME ..........   18
  2948.     3.3 Encapsulating FTBP body parts in MIME ...........   19
  2949.     4 User control over the gateway choice ..............   20
  2950.     4.1 Conversion from MIME to X.400 ...................   21
  2951.     4.2 Conversion from X.400 to MIME ...................   23
  2952.     5 The equivalence registry ..........................   24
  2953.     5.1 What information one must give about a mapping
  2954.          ................................................   24
  2955.     5.2 Equivalence summary for known X.400  and  MIME
  2956.          Types ..........................................   25
  2957.     5.3 MIME to X.400 Table .............................   26
  2958.     5.4 X.400 to MIME Table .............................   27
  2959.     5.5 Use of OBJECT IDENTIFIERs and ASN.1 MACROS ......   28
  2960.     6 Defined Equivalences ..............................   30
  2961.     6.1 IA5Text - text/plain ............................   30
  2962.     6.2 GeneralText - text/plain (ISO-8859) .............   31
  2963.     6.3  BilaterallyDefined - application/octet-stream
  2964.  
  2965.  
  2966.  
  2967.  
  2968.  
  2969. Alvestrand                Exp Nov 96                 [Page 54]
  2970.  
  2971. draft               X.400/MIME body mapping             May 96
  2972.  
  2973.  
  2974.          ................................................   33
  2975.     6.4  FTBP  EMA  Unknown  Attachment   -   applica¡
  2976.          tion/octet-stream ..............................   34
  2977.     6.5 MessageBodyPart - message/RFC822 ................   35
  2978.     6.6 MessageBodyPart - multipart/* ...................   35
  2979.     6.7 Teletex - Text/Plain (Teletex) ..................   37
  2980.     7 Body parts where encapsulation is recommended .....   39
  2981.     7.1 message/external-body ...........................   39
  2982.     7.2 message/partial .................................   40
  2983.     7.3 multipart/signed ................................   41
  2984.     7.4 multipart/encrypted .............................   42
  2985.     8 Conformance requirements ..........................   43
  2986.     9 Security considerations ...........................   44
  2987.     10 Author's address .................................   44
  2988.     11 Acknowledgements .................................   45
  2989.      References .........................................   45
  2990.      APPENDIXES .........................................   47
  2991.      Appendix A: Escape code normalization ..............   47
  2992.      Appendix B: OID Assignments ........................   49
  2993.      Appendix  C:  Registration  information  for  the
  2994.          Teletex character set ..........................   51
  2995.      Appendix  D:  IANA Registration form for new map¡
  2996.          pings ..........................................   53
  2997.      Table of Contents ..................................   54
  2998.  
  2999.  
  3000.  
  3001.  
  3002.  
  3003.  
  3004.  
  3005.  
  3006.  
  3007.  
  3008.  
  3009.  
  3010.  
  3011.  
  3012.  
  3013.  
  3014.  
  3015.  
  3016.  
  3017.  
  3018.  
  3019.  
  3020.  
  3021.  
  3022.  
  3023.  
  3024. Alvestrand                Exp Nov 96                 [Page 55]
  3025.  
  3026.