home *** CD-ROM | disk | FTP | other *** search
/ Internet Access: To the Information Highway / InternetAccessToTheInformationHighway1994.disc1of1.iso / internet / rfc4 / rfc1496.txt < prev    next >
Text File  |  1994-05-29  |  9KB  |  284 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                      H. Alvestrand
  8. Request for Comments: 1496                                  SINTEF DELAB
  9. Updates: 1328                                               J. Romaguera
  10.                                                            NetConsult AG
  11.                                                                K. Jordan
  12.                                               Control Data Systems, Inc.
  13.                                                              August 1993
  14.  
  15.      Rules for Downgrading Messages from X.400/88 to X.400/84 When
  16.              MIME Content-Types are Present in the Messages
  17.  
  18. Status of this Memo
  19.  
  20.    This RFC specifies an IAB standards track protocol for the Internet
  21.    community, and requests discussion and suggestions for improvements.
  22.    Please refer to the current edition of the "IAB Official Protocol
  23.    Standards" for the standardization state and status of this protocol.
  24.    Distribution of this memo is unlimited.
  25.  
  26. Table of Contents
  27.  
  28.    1.  Introduction ...............................................    1
  29.    2.  Basic approach .............................................    2
  30.    3.  Conversion rules ...........................................    3
  31.    3.1  EBP conversions to Basic ..................................    3
  32.    3.2  Encapsulation format ......................................    3
  33.    4.  Implications ...............................................    4
  34.    5.  Security Considerations ....................................    4
  35.    6.  Authors' Addresses .........................................    4
  36.    7.  References .................................................    5
  37.  
  38. 1. Introduction
  39.  
  40.    Interworking between X.400(88) and MIME is achieved by [4], which
  41.    complements RFC-1327 [2], which in turn specifies the interworking
  42.    between X.400(88) and RFC-822 based mail.
  43.  
  44.    Interworking between X.400(88) and X.400 (84) is achieved by RFC-1328
  45.    [3]. That document does not describe what to do in the case where
  46.    body parts arrive at the gateway that cannot be adequately
  47.    represented in the X.400(84) system.
  48.  
  49.    This document describes how RFC-1328 must be modified in order to
  50.    provide adequate support for the scenarios:
  51.  
  52.       SMTP(MIME) -> X.400(84)
  53.  
  54.       X.400(84) -> SMTP(MIME)
  55.  
  56.  
  57.  
  58. Alvestrand, Romaguera & Jordan                                  [Page 1]
  59.  
  60. RFC 1496                        HARPOON                      August 1993
  61.  
  62.  
  63.    It replaces chapter 6 of RFC-1328. The rest of RFC-1328 is NOT
  64.    obsoleted.
  65.  
  66.    NOTE: A desireable side-effect of HARPOON is that a standardized
  67.    method for the identification and transmission of multimedia and
  68.    binary data (like spreadsheets) between X.400/84 UAs is achieved.
  69.  
  70.    While this method is not compatible with current proprietary
  71.    approaches, we believe that it requires less invasive changes to
  72.    current UAs than other possible methods.
  73.  
  74.    This memo updates RFC 1328.  HARPOON is a pure name, and has no
  75.    meaning.  Please send comments to the MIME-MHS mailing list
  76.    <mime-mhs@surnet.nl>.
  77.  
  78. 2.  Basic approach
  79.  
  80.    The approach is to imagine that the connection X.400(84) <->
  81.    SMTP(MIME) never happens. This, of course, is an illusion, but can be
  82.    a very useful illusion.
  83.  
  84.    All mail will therefore go on one of the paths
  85.  
  86.       X.400(84) -> X.400(88) -> SMTP(MIME)
  87.  
  88.       SMTP(MIME) -> X.400(88) -> X.400(84)
  89.  
  90.    when it goes between a MIME user and an X.400(84) user.
  91.  
  92.    The approach at the interface between X.400(88) and X.400(84) is:
  93.  
  94.       o  Convert what you can
  95.  
  96.       o  Encapsulate what you have to
  97.  
  98.       o  Never drop a message
  99.  
  100.    Of course, for X.400/88 body parts that are already defined in
  101.    X.400/84, no downgrading should be done. In particular, multi-body
  102.    messages should remain multi-body messages, IA5 messages including
  103.    IA5 messages encoded as Extended Body Parts) should remain IA5
  104.    messages, and G3Fax messages should remain G3Fax messages.
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Alvestrand, Romaguera & Jordan                                  [Page 2]
  115.  
  116. RFC 1496                        HARPOON                      August 1993
  117.  
  118.  
  119. 3.  Conversion rules
  120.  
  121. 3.1.  EBP conversions to Basic
  122.  
  123.    Some body parts are defined by X.400(88) as having both a Basic form
  124.    and an Extended form. These are listed in Annex B of X.420.
  125.  
  126.    For all of these, the transformation from the Extended Body Part to
  127.    the Basic Body Part takes the form of putting the PARAMETERS and the
  128.    DATA members together in a SEQUENCE.
  129.  
  130.    This transformation should be applied by the gateway in order to
  131.    allow (for example) X.400(88) systems that use the Extended form of
  132.    the IA5 body part to communicate with X.400(84) systems.
  133.  
  134. 3.2.  Encapsulation format
  135.  
  136.    For any body part that cannot be used directly in X.400(84), the
  137.    following IA5Text body part is made:
  138.  
  139.    -  Content = IA5String
  140.  
  141.    -  First bytes of content: (the description is in USASCII, with C
  142.       escape sequences used to represent control characters):
  143.  
  144.        MIME-version: <version>\r\n
  145.            Content-type: <the proper MIME content type>\r\n
  146.          Content-transfer-encoding: <quoted-printable or base64>\r\n
  147.          <Possibly other Content headings here, terminated by\r\n>
  148.          \r\n
  149.  
  150.       <Here follows the bytes of the content, as per [4], encoded in the
  151.       proper encoding>
  152.  
  153.    All implementations MUST place the MIME-version: header first in the
  154.    body part. Headers that are placed by [2] and [4] into other parts of
  155.    the message MUST NOT be placed in the MIME body part.
  156.  
  157.    This includes RFC-822 headings carried as heading-extensions, which
  158.    must be placed in a new IA5 body part starting with the string "RFC-
  159.    822-HEADERS", as specified in [2], Appendix G.
  160.  
  161.    Other heading-extensions are still handled as described in chapter 5
  162.    of RFC 1328: They are dropped.
  163.  
  164.    Since all X.400(88) body parts can be represented in MIME by using
  165.    the x400-bp MIME content-type, this conversion will never fail.
  166.  
  167.  
  168.  
  169.  
  170. Alvestrand, Romaguera & Jordan                                  [Page 3]
  171.  
  172. RFC 1496                        HARPOON                      August 1993
  173.  
  174.  
  175.    In the reverse direction, any IA5 body part that starts with the
  176.    token "MIME-Version:" will be subjected to conversion according to
  177.    [4] before including the body part into an X.400(88) message.
  178.  
  179. 4.  Implications
  180.  
  181.    The implications are several:
  182.  
  183.    - People with X.400(84) readers who have the ability to save messages
  184.      to file will now be able to save MIME multimedia messages
  185.  
  186.    - People who can use features like the "Mailcaps" file to identify
  187.      what to do about a bodypart can now grab implementations of MIME
  188.      that can run as subprograms and achieve at least some multimedia
  189.      functionality
  190.  
  191. 5.  Security Considerations
  192.  
  193.    The security considerations in [1] and [4] (beware of trojans that
  194.    can hit you if your UA automagically starts programs for you) are now
  195.    relevant also for X.400(84) systems.
  196.  
  197. 6.  Authors' Addresses
  198.  
  199.    Harald Tveit Alvestrand
  200.    SINTEF DELAB
  201.    N-7034 Trondheim
  202.    NORWAY
  203.  
  204.    EMail: Harald.T.Alvestrand@delab.sintef.no
  205.  
  206.  
  207.    Kevin E. Jordan, ARH215
  208.    Control Data Systems, Inc.
  209.    4201 Lexington Avenue N
  210.    Arden Hills, MN  55126
  211.    USA
  212.  
  213.    EMail: Kevin.E.Jordan@mercury.oss.arh.cpg.cdc.com
  214.  
  215.  
  216.    James A. Romaguera
  217.    NetConsult AG
  218.    Mettlendwaldweg 20a
  219.    3037 Herrenschwanden
  220.    Switzerland
  221.  
  222.    EMail: Romaguera@netconsult.ch
  223.  
  224.  
  225.  
  226. Alvestrand, Romaguera & Jordan                                  [Page 4]
  227.  
  228. RFC 1496                        HARPOON                      August 1993
  229.  
  230.  
  231. 7.  References
  232.  
  233.    [1]  Borenstein, N, and N. Freed, "MIME: Mechanisms for Specifying
  234.         and Describing the Format of Internet Message Bodies", RFC 1341,
  235.         Bellcore, Innosoft, June 1992.
  236.  
  237.    [2]  Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021
  238.         and RFC-822", RFC 1327, University College London, May 1992.
  239.  
  240.    [3]  Hardcastle-Kille, S., "X.400 1988 to 1984 downgrading", RFC
  241.         1328, University College London, May 1992.
  242.  
  243.    [4]  Alvestrand, H., Kille, S., Miles, R., Rose, M., and S. Thompson,
  244.         "Mapping between X.400 and RFC-822 Message Bodies", RFC 1494,
  245.         SINTEF DELAB, ISODE Consortium, Soft*Switch, Inc, Dover Beach
  246.         Consulting, Inc., Soft*Switch, Inc., August 1993.
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Alvestrand, Romaguera & Jordan                                  [Page 5]
  283.  
  284.