idnits 2.17.1 draft-crocker-wrap-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-03-29) 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 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 265 lines 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 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 209: '...mechanism defined here MUST be sure to...' RFC 2119 keyword, line 215: '...mechanisms MUST be added, either via I...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 144 has weird spacing: '...LY when proce...' == 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 (October 22, 1996) is 10020 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? '2' on line 119 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Application/MIME10/22/96 (Expiration: 4/97) 3 Network Working Group D. Crocker 4 Internet-Draft: DRAFT-CROCKER-WRAP-00.TXT 5 Brandenburg Consulting 6 Expiration <4/97> Laurence Lundblade 7 Qualcomm, Inc. 8 Jamie Zawinski 9 Netscape Communcations, Inc. 10 October 22, 1996 12 Wrapping MIME Objects: Application/MIME 14 STATUS OF THIS MEMO 16 This document is an Internet-Draft. Internet-Drafts are 17 working documents of the Internet Engineering Task Force 18 (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of 23 six months and may be updated, replaced, or obsoleted by 24 other documents at any time. It is inappropriate to use 25 Internet- Drafts as reference material or to cite them other 26 than as ``work in progress.'' 28 To learn the current status of any Internet-Draft, please 29 check the ``1id-abstracts.txt'' listing contained in the 30 Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), 31 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 32 ds.internic.net (US East Coast), or ftp.isi.edu (US West 33 Coast). 35 INTRODUCTION 37 MIME permits labeling and aggregating objects into complex 38 hierarchies. Support for MIME mechanisms is not universal 39 although it is growing quickly, so that gateways are often 40 required to translate portions of a MIME object into its 41 constituent pieces, that is, as independent attachments. 42 Further some uses of MIME's aggregation mechanism, Content- 43 Type:Multipart, are leading to requirements for processing an 44 entire aggregated object as a single unit. This is in 45 contrast to Content-type:Multipart/Mixed which specifies 46 separate processing of constituent components, and to which 47 multipart sub-types default if they are unknown to the 48 processing software. This specification defines Content- 49 Type:Application/MIME to provide an encapsulation mechanism 50 for arbitrary MIME structures. This facilitates their 51 treatment, as a single attachment, by software that is 52 otherwise unfamiliar with the types of objects contained in 53 the encapsulation. It is expected that Application/MIME will 54 be especially useful in getting data past gateways. 56 The specification simply defines an object which contains 57 MIME data. When the object is removed from its Content- 58 Type:Application/MIME wrapper, what remains is an entire MIME 59 object, beginning with a (new) Content-type header. 61 APPLICATION/EDIFACT SPECIFICATION 63 MIME type name: Application 65 MIME subtype name: MIME 67 Required parameters: Content-type, 69 Optional parameters: None 71 Encoding considerations: May need BASE64 or QUOTED- 72 PRINTABLE transfer encoding, as 73 appropriate for the contained 74 data. Careful use of QUOTED- 75 PRINTABLE will maintain clear 76 text as robust against gateway 77 processing yet still be 78 readable without special 79 processing. 81 Security considerations: See separate section in this 82 document. 84 Published specification: See detail, below. 86 Rationale: Gateways and some other 87 processing environments can 88 alter and destroy MIME data 89 structure; the defined data 90 type will permit "hiding" the 91 structure inside an object that 92 is much less likely to be 93 modified by such software. It 94 also permits passing an 95 aggregate object as a single 96 entity, through processors that 97 would otherwise separate the 98 components. 100 Contact-info: See Contact section, below. 102 Detail specific to MIME-based usage: 104 This is a generic mechanism for encapsulating any MIME 105 object structure. The object is self-defining, since it 106 begins with a MIME Content-Type header and is then 107 processed (recursively). The mechanism is intended for 108 use when correct processing of the basic MIME structure 109 is at risk, in effect allowing the MIME structure to be 110 tunneled through such an environment. 112 The Content-Type parameter comprises the type and sub- 113 type tokens of the Content-Type header for the contained 114 MIME component, i.e., 116 type := "Content-Type=" <"> type "/" subtype <"> 118 where the type and subtype tokens are defined by the 119 MIME [2] specification. The value of the Content-Type 120 parameter specifies the MIME Content-Type and subtype of 121 the data structure contained inside the Application/MIME 122 object. 124 The parameters replicate all of the 125 parameters which are present in the Content-Type 126 specification header referenced by the Content-Type 127 parameter. That is, they replicate the contained 128 object's parameters, in their entirety. This is done to 129 facilitate dispatch of a particular type to a handler 130 without parsing the contained MIME structure. 132 If the contained object is, itself 133 Application/MIME, then none of the 134 parameters of that contained object shall be 135 included. 137 (Using Application/MIME for doubly-wrapping MIME data 138 may provide a necessary level of protection in some 139 cases.) 141 GATEWAY AND PASS-THROUGH PROCESSING 143 Software which manipulates an Application/MIME component must 144 do so ONLY when processing can be done fully and correctly. 145 In the extreme, this may require full parsing of the 146 contained MIME structure and its parameters, prior to 147 deciding whether to take responsibility for the content. 148 Typically, however, review of the Application/MIME type and 149 parameters will suffice. 151 Any MIME-aware software which encounters an Application/MIME 152 component must leave the component in its existing form, 153 unless that software is able to fully and correctly process 154 ALL of the component contents AND such processing is 155 appropriate to the environment in which the software is 156 operating. 158 GATEWAY IMPLEMENTORS ARE SPECIFICALLY AND STRONGLY 159 CAUTIONED AGAINST MODIFICATION OF AN 160 APPLICATION/MIME COMPONENT. 162 The question of whether to unwrap content which is embedded 163 in an Application/MIME becomes very simple. Application/MIME 164 is used to provide protection against mishandling by 165 intermediaries. Hence, only end-system software-including 166 gateways and regular email user agents-should even consider 167 touching the content and then it should only do so when the 168 recipient has a basis for believing that the processing will 169 be correct. 171 SAMPLE USAGE IN MIME-BASED EMAIL 173 This section is intended as a simple example of the gist of 174 the formatting required to encapsulate MIME objects within 175 Internet mail, using Application/MIME: 177 To: 178 Subject: 179 From: 180 Date: 181 Mime-Version: 1.0 182 Content-Type: Application/MIME; content- 183 type=Multipart/signed; 184 protocol="application/somesigscheme"; 185 boundary="//signatureboundary//" 187 Content-Type: Multipart/Signed; 188 boundary=//signatureboundary//; 189 protocol="application/somesigscheme" 191 --//signatureboundary// 192 Content-type:<> 194 <> 196 --//signatureboundary// 197 Content-type:application/somesigscheme 199 <> 201 --//signatureboundary//-- 203 SECURITY CONSIDERATIONS 205 MIME content often includes sensitive data, so that 206 transmission often needs to attend to authentication, data 207 integrity, privacy and access control, and the like as 208 appropriate. In particular, the recursive processing 209 required by the mechanism defined here MUST be sure to 210 include whatever security checks are applied to newly- 211 received MIME data. 213 This specification does NOT, itself, provide any security- 214 related mechanisms. As needed and appropriate, such 215 mechanisms MUST be added, either via Internet MIME-based 216 security services or any other services which are appropriate 217 to the user requirements. 219 ACKNOWLEDGMENTS 221 The idea for Application/MIME first developed out of 222 conversations with Einar Stefferud and Marshall Rose, in 223 trying to find a way for exchanging valid Internet Mail, 224 complete with RFC822 headers and MIME content, through 225 environments that provided no other Internet Mail technology 226 besides a gateway between the proprietary environment and the 227 Internet. Additional benefits of this mechanism then 228 surfaced during discussions on the S/MIME development list. 230 CONTACT 232 David H. Crocker 233 Internet Mail Consortium 234 675 Spruce Dr. 235 Sunnyvale, CA 94086 USA 236 Phone: +1 408 246 8253 237 Fax: +1 408 249 6205 239 Laurence Lundblade 240 Qualcomm, Inc. 241 6455 Lusk Blvd 242 San Diego Ca 92121 USA 243 Phone: 619-658-3584 245 Jamie Zawinski 246 Netscape Communciations, Inc. 247 501 East Middlefield Road 248 Mountain View, CA 94043