draft HARPOON Jan 93 HARPOON Rules for downgrading messages from X.400/88 to X.400/84 when MIME content-types are present in the messages Tue Apr 13 15:50:23 MET DST 1993 Harald Tveit Alvestrand SINTEF DELAB Harald.T.Alvestrand@delab.sintef.no Jim Romaguera NetConsult AG Romaguera@netconsult.ch Kevin Jordan Control Data Systems, Inc. kej@mercury.udev.cdc.com Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. If consensus is reached in the IETF MIME-MHS Interworking Working Group, it will be submitted to the IESG asking that Alvestrand et al Expires Sep 13 1993 [Page 1] draft HARPOON Jan 93 it be recommended to the IAB as a Proposed Standard protocol specification. This RFC updates RFC 1328. HARPOON stands for Holistic Approach to Reliable Provision of Open Networking, and is used solely to catch the eye of readers. Please send comments to the MIME-MHS mailing list Alvestrand et al Expires Sep 13 1993 [Page 2] draft HARPOON Jan 93 1. Introduction Interworking between X.400(88) and MIME is achieved by [MAPPING], which modifies RFC-1327 [RFC 1327], which specifies the interworking between X.400(88) and RFC-822 based mail. Interworking between X.400(88) and X.400 (84) is achieved by RFC- 1328 [RFC 1328]. 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. This document describes how RFC-1328 must be modified in order to provide adequate support for the scenarios: SMTP(MIME) -> X.400(84) X.400(84) -> SMTP(MIME) It replaces chapter 6 of RFC-1328. 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. 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. 2. Basic approach 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. All mail will therefore go on one of the paths X.400(84) -> X.400(88) -> SMTP(MIME) SMTP(MIME) -> X.400(88) -> X.400(84) when it goes between a MIME user and an X.400(84) user. The approach at the interface between X.400(88) and X.400(84) is: Alvestrand et al Expires Sep 13 1993 [Page 3] draft HARPOON Jan 93 o Convert what you can o Encapsulate what you have to o Never drop a message 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. 3. Conversion rules 3.1. EBP conversions to Basic 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. 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. 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. 3.2. Encapsulation format For any body part that cannot be used directly in X.400(84), the following IA5Text body part is made: - Content = IA5String - First bytes of content: (the description is in USASCII, with C escape sequences used to represent control characters): MIME-version: \r\n Content-type: \r\n Content-transfer-encoding: \r\n \r\n Alvestrand et al Expires Sep 13 1993 [Page 4] draft HARPOON Jan 93 All implementations MUST place the MIME-version: header first in the body part. Headers that are placed by [RFC-1327] and [MAPPING] into other parts of the message MUST NOT be placed in the MIME body part. 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 [RFC-1327], Appendix G. Other heading-extensions are still handled as described in chapter 5 of RFC 1328: They are dropped. 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. In the reverse direction, any IA5 body part that starts with the token "MIME-Version:" will be subjected to conversion according to [MAPPING] before including the body part into an X.400(88) message. 4. Implications The implications are several: - People with X.400(84) readers who have the ability to save messages to file will now be able to save MIME multimedia messages - People who can use features like the "Mailcaps" file to identify what to do about a bodypart can now grab MetaMail or MHN and achieve at least some multimedia functionality 5. Security considerations The security considerations in [MIME] and [MAPPING] (beware of trojans that can hit you if your UA automagically starts programs for you) are now relevant also for X.400(84) systems. Alvestrand et al Expires Sep 13 1993 [Page 5] draft HARPOON Jan 93 6. Authors' address Harald Tveit Alvestrand SINTEF DELAB N-7034 Trondheim NORWAY Harald.T.Alvestrand@delab.sintef.no Kevin E. Jordan, ARH215 Control Data Systems, Inc. 4201 Lexington Avenue N Arden Hills, MN 55126 USA Kevin.E.Jordan@mercury.oss.arh.cpg.cdc.com James A. Romaguera NetConsult AG Mettlendwaldweg 20a 3037 Herrenschwanden Switzerland Romaguera@netconsult.ch 7. References [MIME] N. Borenstein, N. Freed, MIME: Mechanisms for Specifying and Describing the Format of Internet Message Bodies. RFC 1341 [RFC-1327] S.E. Hardcastle-Kille, Mapping between X.400(1988) / ISO 10021 and RFC-822. [RFC-1328] S.E. Hardcastle-Kille, X.400 1988 to 1984 downgrading. [MAPPING] H.T. Alvestrand, R.S. Miles, M.T. Rose, S.J. Thompson, Mapping between X.400 and RFC-822 Message Bodies Internet- Draft, (June, 1992). Alvestrand et al Expires Sep 13 1993 [Page 6] draft HARPOON Jan 93 Table of Contents Status of this Memo ........................................ 1 1 Introduction .............................................. 3 2 Basic approach ............................................ 3 3 Conversion rules .......................................... 4 3.1 EBP conversions to Basic ................................ 4 3.2 Encapsulation format .................................... 4 4 Implications .............................................. 5 5 Security considerations ................................... 5 6 Authors' address .......................................... 6 7 References ................................................ 6 Alvestrand et al Expires Sep 13 1993 [Page 7]