idnits 2.17.1 draft-crocker-wrap-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 6 instances of lines with non-ascii characters in the document. == 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 334 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 abstract seems to contain references ([2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 285: '...mechanisms MUST be added, either via I...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 174 has weird spacing: '...LY when proce...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 23, 2002) is 7968 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 149 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D. Crocker 2 draft-crocker-wrap-02.txt Brandenburg InternetWorking 3 June 23, 2002 4 Expiration <12/02> 6 Wrapping MIME Objects: Application/MIME 8 STATUS OF THIS MEMO 10 This document is an Internet-Draft and is in full conformance 11 with all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet 14 Engineering Task Force (IETF), its areas and its working 15 groups. Note that other groups may also distribute working 16 documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of 19 six months and may be updated, replaced, or obsoleted by 20 other documents at any time. It is inappropriate to use 21 Internet-Drafts as reference material or to cite them other 22 than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed 28 at http://www.ietf.org/shadow.html. 30 ABSTRACT 32 MIME is a general-purpose mechanism for labeling and 33 aggregating objects into complex hierarchies. Some MIME 34 objects are discrete objects. If placed within another MIME 35 hierarchy, they need to appear as a leaf node in the 36 containing hierarchy, rather than seeming to be continuations 37 of that hierarchy. This specification defines Content-type 38 Application/MIME to provide an encapsulation mechanism for 39 arbitrary MIME structures. This facilitates their treatment 40 as a single unit, rather than causing them to be treated as 41 part of any containing MIME hierarchy. 43 INTRODUCTION 45 MIME is a general-purpose mechanism for labeling and 46 aggregating objects into complex hierarchies. Some MIME 47 objects are discrete objects. If placed within another MIME 48 hierarchy, they need to appear as a leaf node in the 49 containing hierarchy, rather than seeming to be continuations 50 of that hierarchy. One example of this requirement is to 51 provide some protection against the translations that email 52 gateways often make to MIME attachments. Further some uses 53 of MIME�s aggregation mechanism, Content-type Multipart, can 54 lead to requirements for processing an entire aggregated 55 object as a single unit. This is in contrast to Content-type 56 Multipart/Mixed, which specifies separate processing of 57 constituent components, and to which multipart sub-types 58 default if they are unknown to the processing software. 60 This specification defines Content-type Application/MIME to 61 provide an encapsulation mechanism for arbitrary MIME 62 structures. This facilitates their treatment as a single 63 unit, rather than causing them to be treated as part of any 64 containing MIME hierarchy. It is expected that 65 Application/MIME will be especially useful in getting data 66 past gateways. 68 The specification simply defines an object that contains MIME 69 data. When the object is removed from its Content-type 70 Application/MIME wrapper, what remains is an entire MIME 71 object, beginning with a (new) Content-type header. 73 APPLICATION/MIME SPECIFICATION 75 MIME type name: Application 77 MIME subtype name: MIME 79 Required parameters: 81 Optional parameters: None 83 Encoding considerations: May need BASE64 or QUOTED- 84 PRINTABLE transfer encoding, as 85 appropriate for the 86 data. Careful use of QUOTED- 87 PRINTABLE will maintain clear 88 text as robust against gateway 89 processing yet still be 90 readable without special 91 processing. 93 NOTE: items carried inside 94 this MIME object must be fully 95 conformant MIME structure and 96 data; this includes all of the 97 usual rules concerning network 98 standard canonical 99 representation. 101 Security considerations: See separate section in this 102 document. 104 Published specification: See detail, below. 106 Rationale: MIME objects can be discrete 107 entities; when attached to 108 another MIME object, the 109 attachment needs to be 110 represented as a leaf, rather 111 than a part of that hierarchy. 112 One use of this distinction is 113 for gateways and other 114 processing environments that 115 can alter and destroy MIME data 116 structure; the defined data 117 type will permit separate 118 handling of the structure 119 inside an object. It also 120 permits passing an aggregate 121 object as a single entity, 122 through processors that would 123 otherwise separate the 124 components. 126 Contact-info: See Contact section, below. 128 Detail specific to MIME-based usage: 130 This is a generic mechanism for encapsulating any MIME 131 object structure. The object is self-defining, since it 132 begins with a MIME Content-Type header and is then 133 processed (recursively). The mechanism is intended for 134 use when correct processing of the basic MIME structure 135 is at risk, in effect allowing the MIME structure to be 136 tunneled through such an environment. 138 The Content-Type parameter comprises the type and sub- 139 type tokens of the Content-Type header for the contained 140 MIME component, i.e., 142 contained = c-t *(�;� *parameter) 144 c-t = �Content-Type=� <"> type "/" subtype <"> 146 parameter = {as defined for MIME} 148 where the type and subtype tokens are defined by the 149 MIME [2] specification. The value of the Content-Type 150 parameter specifies the MIME Content-Type and subtype of 151 the data structure contained inside the Application/MIME 152 object. 154 The parameters replicate all of the 155 parameters which are present in the Content-Type 156 specification header referenced by the Content-Type 157 parameter. That is, they replicate the contained 158 object�s parameters, in their entirety. This is done to 159 facilitate dispatch of a particular type to a handler, 160 without parsing the contained MIME structure. 162 If the contained object is, itself 163 Application/MIME, then none of the 164 parameters of that contained object shall be 165 included. 167 (Using Application/MIME for doubly-wrapping MIME data 168 may provide a necessary level of protection in some 169 cases.) 171 GATEWAY AND PASS-THROUGH PROCESSING 173 Software which manipulates an Application/MIME component must 174 do so ONLY when processing can be done fully and correctly. 175 In the extreme, this may require full parsing of the 176 contained MIME structure and its parameters, prior to 177 deciding whether to take responsibility for the content. 178 Typically, however, review of the Application/MIME type and 179 parameters will suffice. 181 Any MIME-aware software that encounters an Application/MIME 182 component must leave the component in its existing form, 183 unless that software is able to fully and correctly process 184 ALL of the component contents AND such processing is 185 appropriate to the environment in which the software is 186 operating. 188 IMPORTANT NOTE: Gateway implementers are specifically 189 and strongly cautioned against 190 modification of an Application/MIME 191 component. 193 The question of whether to unwrap content that is embedded in 194 an Application/MIME becomes very simple. Application/MIME is 195 used to provide protection against mishandling by 196 intermediaries. Hence, only end-system software�including 197 gateways and regular email user agents�should even consider 198 touching the content and then it should only do so when the 199 recipient has a basis for believing that the processing will 200 be correct. 202 SIMPLE USAGE IN MIME-BASED EMAIL 204 This section is intended as a simple example of the gist of 205 the formatting required to encapsulate MIME objects within 206 Internet mail, using Application/MIME: 208 To: 209 Subject: 210 From: 211 Date: 212 Mime-Version: 1.0 213 Content-Type: Application/MIME; 214 content-type=Multipart/signed; 215 protocol="application/somesigscheme"; 216 boundary="//signatureboundary//" 218 Content-Type: Multipart/Signed; 219 boundary=//signatureboundary//; 220 protocol="application/somesigscheme" 222 --//signatureboundary// 223 Content-type:<> 225 <> 227 --//signatureboundary// 228 Content-type:application/somesigscheme 230 <> 232 --//signatureboundary//-- 234 DOUBLE-WRAPPED EXAMPLE 236 This section shows a contained object which is, itself, a 237 contained object, double-wrapped for extra protection against 238 decay: 240 To: 241 Subject: 242 From: 243 Date: 244 Mime-Version: 1.0 245 Content-Type: Application/MIME; 246 content-type=Multipart/signed; 247 protocol="application/somesigscheme"; 248 boundary="//signatureboundary//" 250 Content-Type: Application/MIME; 251 content-type=Multipart/signed; 252 boundary="//signatureboundary//"; 253 protocol="application/somesigscheme" 255 Content-Type: Multipart/Signed; 256 boundary=//signatureboundary//; 257 protocol="application/somesigscheme" 259 --//signatureboundary// 260 Content-type:<> 262 <> 264 --//signatureboundary// 265 Content-type:application/somesigscheme 267 <> 269 --//signatureboundary//-- 271 SECURITY CONSIDERATIONS 273 MIME content often includes sensitive data, so that 274 transmission often needs to attend to authentication, data 275 integrity, privacy, access control, and the like as 276 appropriate. 278 IMPORTANT NOTE: The recursive processing required by 279 Application/MIME requires use of 280 whatever security checks are applied to 281 newly received MIME data. 283 This specification does NOT, itself, provide any security- 284 related mechanisms. As needed and appropriate, such 285 mechanisms MUST be added, either via Internet MIME-based 286 security services or any other services which are appropriate 287 to the user requirements. 289 ACKNOWLEDGMENTS 291 The idea for Application/MIME first developed out of 292 conversations with Einar Stefferud and Marshall Rose, in 293 trying to find a way for exchanging valid Internet Mail, 294 complete with RFC822 headers and MIME content, through 295 environments that provided no other Internet Mail technology 296 besides a gateway between the proprietary environment and the 297 Internet. Additional benefits of this mechanism then 298 surfaced during discussions on the S/MIME development list. 300 A previous draft was co-authored by Laurence Lundblade and 301 Jamie Zewinskie. They are not listed in the current draft 302 merely to protect the innocent. 304 CONTACT 306 David H. Crocker 307 Brandenburg InternetWorking 308 675 Spruce Drive 309 Sunnyvale, CA 94086 USA 310 Phone: +1.408.246.8253