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