idnits 2.17.1 draft-ietf-mimemhs-harpoon-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 5. Security considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 122: '... implementations MUST place the MIME-v...' RFC 2119 keyword, line 124: '...s of the message MUST NOT be placed in...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date () is 739384 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'MAPPING' on line 198 looks like a reference -- Missing reference section? 'RFC 1327' on line 60 looks like a reference -- Missing reference section? 'RFC 1328' on line 64 looks like a reference -- Missing reference section? 'RFC-1327' on line 189 looks like a reference -- Missing reference section? 'MIME' on line 184 looks like a reference -- Missing reference section? 'RFC-1328' on line 195 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 draft HARPOON May 92 3 HARPOON 4 Rules for downgrading messages from X.400/88 to X.400/84 when 5 MIME content-types are present in the messages 7 Sun Aug 30 23:40:19 MET DST 1992 9 Harald Tveit Alvestrand 10 SINTEF DELAB 11 Harald.T.Alvestrand@delab.sintef.no 13 Jim Romaguera 14 NetConsult AG 15 Romaguera@cosine-mhs.switch.ch 17 Kevin Jordan 18 Control Data Systems, Inc. 19 kej@mercury.udev.cdc.com 21 Status of this Memo 23 This document is an Internet Draft. Internet Drafts are 24 working documents of the Internet Engineering Task Force 25 (IETF), its Areas, and its Working Groups. Note that other 26 groups may also distribute working documents as Internet 27 Drafts. 29 Internet Drafts are draft documents valid for a maximum of 30 six months. Internet Drafts may be updated, replaced, or 31 obsoleted by other documents at any time. It is not 32 appropriate to use Internet Drafts as reference material or 33 to cite them other than as a "working draft" or "work in 34 progress." 36 Please check the I-D abstract listing contained in each 37 Internet Draft directory to learn the current status of this 38 or any other Internet Draft. 40 If consensus is reached in the IETF MIME-MHS Interworking 41 Working Group, it will be submitted to the IESG asking that 43 draft HARPOON May 92 45 it be recommended to the IAB as a Proposed Standard protocol 46 specification. 48 HARPOON stands for Holistic Approach to Reliable Provision of 49 Open Networking, and is used solely to catch the eye of 50 readers. 52 Please send comments to the MIME-MHS mailing list 53 55 draft HARPOON May 92 57 1. Introduction 59 Interworking between X.400(88) and MIME is achieved by [MAPPING], 60 which modifies RFC-1327 [RFC 1327], which specifies the 61 interworking between X.400(88) and RFC-822 based mail. 63 Interworking between X.400(88) and X.400 (84) is achieved by RFC- 64 1328 [RFC 1328]. That document does not describe what to do in the 65 case where body parts arrive at the gateway that cannot be 66 adequately represented in the X.400(84) system. 68 This document describes how RFC-1328 must be modified in order to 69 provide adequate support for the scenarios: 71 SMTP(MIME) -> X.400(84) 73 X.400(84) -> SMTP(MIME) 75 2. Basic approach 77 The approach is to imagine that the connection X.400(84) <-> 78 SMTP(MIME) never happens. This, of course, is an illusion, but can 79 be a very useful illusion. 81 All mail will therefore go on one of the paths 83 X.400(84) -> X.400(88) -> SMTP(MIME) 85 SMTP(MIME) -> X.400(88) -> X.400(84) 87 when it goes between a MIME user and an X.400(84) user. 89 The approach at the interface between X.400(88) and X.400(84) is: 91 o Convert what you can 93 o Encapsulate what you have to 95 o Never drop a message 97 3. Basic fallback format 99 For any body part that cannot be used directly in X.400(84), the 100 following body part is made: 102 draft HARPOON May 92 104 - Tag = 14 (Bilaterally defined) 106 - Content = Octet string 108 - First bytes of content: (in USASCII, with C escape sequences 109 used to represent control characters): 111 MIME-version: \r\n 112 Content-type: \r\n 113 Content-transfer-encoding: \r\n 114 115 \r\n 116 118 The preferred encoding is BINARY, because X.400 does not have any 119 limitations to what octets it can pass in an Octet String, but 120 this RFC does not require use of the BINARY encoding. 122 All implementations MUST place the MIME-version: header first in 123 the body part. Headers that are placed by [RFC-1327] and [MAPPING] 124 into other parts of the message MUST NOT be placed in the MIME 125 body part. 127 Since all X.400(88) body parts can be represented in MIME by using 128 the x400-bp MIME content-type, this conversion will never fail. 130 In the reverse direction, any body part that starts with the token 131 "MIME-Version:" will be subjected to conversion according to 132 [MAPPING] before including the body part into an X.400(88) 133 message. 135 4. Implications 137 The implications are several: 139 - People with X.400(84) readers who have the ability to save 140 Bodypart 14 messages to file will now be able to save MIME 141 multimedia messages 143 - People who can use features like the "Mailcaps" file to 144 identify what to do about a bodypart 14 can now grab MetaMail 145 or MHN and achieve at least some multimedia functionality 147 draft HARPOON May 92 149 - People with E-mail systems that drop into BP 14 when an 8-bit 150 character comes along can now include the magic tokens by 151 hand at the beginning of the message, and get their 152 characters received properly by MIME users 154 5. Security considerations 156 The security considerations in [MIME] and [MAPPING] (beware of 157 trojans that can hit you if your UA automagically starts programs 158 for you) are now relevant also for X.400(84) systems. 160 6. Authors' address 162 Harald Tveit Alvestrand 163 SINTEF DELAB 164 N-7034 Trondheim 165 NORWAY 166 Harald.T.Alvestrand@delab.sintef.no 168 Kevin E. Jordan, ARH215 169 Control Data Systems, Inc. 170 4201 Lexington Avenue N 171 Arden Hills, MN 55126 172 USA 173 Kevin.E.Jordan@mercury.oss.arh.cpg.cdc.com 175 James A. Romaguera 176 NetConsult AG 177 Mettlendwaldweg 20a 178 3037 Herrenschwanden 179 Switzerland 180 Romaguera@cosine-mhs.switch.ch 182 7. References 184 [MIME] 185 N. Borenstein, N. Freed, MIME: Mechanisms for Specifying and 186 Describing the Format of Internet Message Bodies. Internet- 187 Draft, (January, 1992). 189 [RFC-1327] 190 S.E. Hardcastle-Kille, Mapping between X.400(1988) / ISO 191 10021 and RFC-822. 193 draft HARPOON May 92 195 [RFC-1328] 196 S.E. Hardcastle-Kille, X.400 1988 to 1984 downgrading. 198 [MAPPING] 199 H.T. Alvestrand, R.S. Miles, M.T. Rose, S.J. Thompson, 200 Mapping between X.400 and RFC-822 Message Bodies Internet- 201 Draft, (June, 1992). 203 draft HARPOON May 92 205 Table of Contents 207 Status of this Memo ........................................ 1 208 1 Introduction .............................................. 3 209 2 Basic approach ............................................ 3 210 3 Basic fallback format ..................................... 3 211 4 Implications .............................................. 4 212 5 Security considerations ................................... 5 213 6 Authors' address .......................................... 5 214 7 References ................................................ 5 216 ------------------------------ End of body part 2