idnits 2.17.1 draft-dorner-content-header-01.txt: ** The Abstract section seems to be numbered 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 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. == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 2) being 59 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC1521], [RFC822]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (January 1994) is 11059 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1521 (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) Summary: 12 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft: draft-dorner-content-header-01.txt 2 Category: Informational Rens Troost 3 Steve Dorner 4 January 1994 6 Communicating Presentation Information in 7 Internet Messages: 8 The Content-Disposition Header 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are 13 working documents of the Internet Engineering Task Force 14 (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of 19 six months. Internet-Drafts may be updated, replaced, or 20 obsoleted by other documents at any time. It is not 21 appropriate to use Internet-Drafts as reference material or 22 to cite them other than as a "working draft" or "work in 23 progress". 25 To learn the current status of any Internet-Draft, please 26 check the 1id-abstracts.txt listing contained in the 27 Internet-Drafts Shadow Directories on ds.internic.net, 28 nic.nordu.net, ftp.isi.edu, or munnari.oz.au. 30 1. Abstract 32 This memo provides a mechanism whereby messages conforming to 33 the [RFC 1521] ("MIME") specification can convey 34 presentational information. It specifies a new 35 "Content-Disposition" header, optional and valid for any 36 [RFC 1521] entity ("message" or "body part"). Two values for 37 this header are described in this memo; one for the ordinary 38 linear presentation of the body part, and another to 39 facilitate the use of mail to transfer files. It is expected 40 that more values will be defined in the future, and 41 procedures are defined for extending this set of values. 43 This document is intended as an extension to [RFC 1521]. As 44 such, the reader is assumed to be familiar with [RFC 1521], 45 and [RFC 822]. The information presented herein supplements 46 but does not replace that found in those documents. 48 2. Introduction 50 [RFC 1521] describes a standard format for encapsulating 51 multiple pieces of data into a single Internet message. That 52 document does not address the issue of presentation styles; 53 it provides a framework for the interchange of message 54 content, but leaves presentation issues solely in the hands 55 of mail user agent (MUA) implementors. 57 Two common ways of presenting multipart electronic messages 58 are as a main document with a list of separate attachments, 59 and as a single document with the various parts expanded 60 (displayed) inline. The display of an attachment is generally 61 construed to require positive action on the part of the 62 recipient, while inline message components are displayed 63 automatically when the message is viewed. A mechanism is 64 needed to allow the sender to transmit this sort of 65 presentational information to the recipient; the 66 Content-Disposition header provides this mechanism, allowing 67 each component of a message to be tagged with an indication 68 of its desired presentation semantics. 70 Tagging messages in this manner will often be sufficient for 71 basic message formatting. However, in many cases a more 72 powerful and flexible approach will be necessary. The 73 definition of such approaches is beyond the scope of this 74 memo; however, such approaches can benefit from additional 75 Content-Disposition values and parameters, to be defined at a 76 later date. 78 In addition to allowing the sender to specify the 79 presentational disposition of a message component, it is 80 desirable to allow her to indicate a default archival 81 disposition; a filename. The optional "filename" parameter 82 provides for this. 84 3. The Content-Disposition Header Field 86 Content-Disposition is an optional header; in its absence, 87 the MUA may use whatever presentation method it deems 88 suitable. 90 It is desirable to keep the set of possible disposition types 91 small and well defined, to avoid needless complexity. Even 92 so, evolving usage will likely require the definition of 93 additional disposition types or parameters, so the set of 94 disposition values is extensible; see below. 96 In the extended BNF notation of [RFC 822], the 97 Content-Disposition header field is defined as follows: 99 disposition := "Content-Disposition" ":" 100 disposition-type 101 *(";" disposition-parm) 103 disposition-type := "inline" 104 / "attachment" 105 / extension-token 106 ; values are not case-sensitive 108 disposition-parm := filename-parm / parameter 110 filename-parm := "filename" "=" value; 112 `Extension-token', `parameter' and `value' are defined 113 according to [RFC 822] and [RFC 1521]. 115 3.1 The Inline Disposition Type 117 A bodypart should be marked `inline' if it is intended to be 118 displayed automatically upon display of the message. Inline 119 bodyparts should be presented in the order in which they are 120 encountered, subject to the normal semantics of multipart 121 messages. 123 3.2 The Attachment Disposition Type 125 Bodyparts can be designated `attachment' to indicate that 126 they are separate from the main body of the mail message, and 127 that their display should not be automatic, but contingent 128 upon some further action of the user. The MUA might instead 129 present the user of a bitmap terminal with an iconic 130 representation of the attachments, or, on character 131 terminals, with a list of attachments from which the user 132 could select for viewing or storage. 134 3.3 The Filename Parameter 136 The sender may want to suggest a filename to be used if the 137 entity is detached and stored in a separate file. If the 138 receiving MUA writes the entity to a file, the suggested 139 filename should be used as a basis for the actual filename, 140 where possible. 142 It is important that the receiving MUA not blindly use the 143 suggested filename. The suggested filename should be checked 144 (and possibly changed) to see that it conforms to local 145 filesystem conventions, does not overwrite an existing file, 146 and does not present a security problem (see Security 147 Considerations below). 149 The receiving MUA should not respect any directory path 150 information that may seem to be present in the filename 151 parameter. The filename should be treated as a terminal 152 component only. Portable specification of directory paths 153 might possibly be done in the future via a separate Content- 154 Disposition parameter, but no provision is made for it in 155 this draft. 157 Current [RFC 1521] grammar restricts parameter values (and 158 hence Content-Disposition filenames) to US-ASCII. We 159 recognize the great desirability of allowing arbitrary 160 character sets in filenames, but it is beyond the scope of 161 this document to define the necessary mechanisms. We expect 162 that the basic [RFC 1521] `value' specification will someday 163 be amended to allow use of non-US-ASCII characters, at which 164 time the same mechanism should be used in the Content- 165 Disposition filename parameter. 167 Beyond the limitation to US-ASCII, the sending MUA may wish 168 to bear in mind the limitations of common filesystems. Many 169 have severe length and character set restrictions. Short 170 alphanumeric filenames are least likely to require 171 modification by the receiving system. 173 The presence of the filename parameter does not force an 174 implementation to write the entity to a separate file. It is 175 perfectly acceptable for implementations to leave the entity 176 as part of the normal mail stream unless the user requests 177 otherwise. As a consequence, the parameter may be used on any 178 MIME entity, even `inline' ones. These will not normally be 179 written to files, but the parameter could be used to provide 180 a filename if the receiving user should choose to write the 181 part to a file. 183 3.4 Future Extensions and Unrecognized Disposition Types 185 In the likely event that new parameters or types are needed, 186 they should be registered with the IANA, in the manner 187 specified in [RFC 1521], appendix E. 189 Once new types and parameters are defined, there is of course 190 the likelihood that implementations will see types and 191 parameters they do not understand. Furthermore, since 192 x-tokens are allowed, implementations may also see entirely 193 unregistered types and parameters. 195 Unrecognized parameters should be ignored. Unrecognized types 196 should be treated as `attachment'. The choice of `attachment' 197 for unrecognized types is made because a sender who goes to 198 the trouble of producing a Content-Disposition header with a 199 new value is more likely aiming for something more elaborate 200 than inline presentation. 202 Unless noted otherwise in the definition of a parameter, 203 Content-Disposition parameters are valid for all 204 dispositions. (In contrast to [RFC 1521] content-type 205 parameters, which are defined on a per-content-type basis.) 206 Thus, for example, the `filename' parameter still means the 207 name of the file to which the part should be written, even if 208 the disposition itself is unrecognized. 210 3.5 Content-Disposition and Multipart 212 If a Content-Disposition header is used on a multipart body 213 part, it applies to the multipart as a whole, not the 214 individual subparts. The disposition types of the subparts 215 do not need to be consulted until the multipart itself is 216 presented. When the multipart is displayed, then the 217 dispositions of the subparts should be respected. 219 If the `inline' disposition is used, the multipart should be 220 displayed as normal; however, an `attachment' subpart should 221 require action from the user to display. 223 If the `attachment' disposition is used, presentation of the 224 multipart should not proceed without explicit user action. 225 Once the user has chosen to display the multipart, the 226 individual subpart dispositions should be consulted to 227 determine how to present the subparts. 229 3.6 Content-Disposition and the Main Message 231 It is permissible to use Content-Disposition on the main body 232 of an [RFC 822] message. 234 4. Examples 236 Here is a an example of a body part containing a JPEG image 237 that is intended to be viewed by the user immediately: 239 Content-Type: image/jpeg 240 Content-Disposition: inline 241 Content-Description: just a small picture of me 243 245 The following body part contains a JPEG image that should be 246 displayed to the user only if the user requests it. If the 247 JPEG is written to a file, the file should be named 248 "genome.jpg": 250 Content-Type: image/jpeg 251 Content-Disposition: attachment; filename=genome.jpeg 252 Content-Description: a complete map of the human genome 254 256 The following is an example of the use of the `attachment' 257 disposition with a multipart body part. The user should see 258 text-part-1 immediately, then take some action to view 259 multipart-2. After taking action to view multipart-2, the 260 user will see text-part-2 right away, and be required to take 261 action to view jpeg-1. Subparts are indented for clarity; 262 they would not be so indented in a real message. 264 Content-Type: multipart/mixed; boundary=outer 265 Content-Description: multipart-1 267 --outer 268 Content-Type: text/plain 269 Content-Disposition: inline 270 Content-Description: text-part-1 272 Some text goes here 274 --outer 275 Content-Type: multipart/mixed; boundary=inner 276 Content-Disposition: attachment 277 Content-Description: multipart-2 279 --inner 280 Content-Type: text/plain 281 Content-Disposition: inline 282 Content-Description: text-part-2 284 Some more text here. 286 --inner 287 Content-Type: image/jpeg 288 Content-Disposition: attachment 289 Content-Description: jpeg-1 291 292 --inner-- 293 --outer-- 295 5. Summary 297 Content-Disposition takes one of two values, `inline' and 298 `attachment'. 'Inline' indicates that the entity should be 299 immediately displayed to the user, whereas `attachment' means 300 that the user should take additional action to view the 301 entity. 303 The `filename' parameter can be used to suggest a filename 304 for storing the bodypart, if the user wishes to store it in 305 an external file. 307 6. Security Considerations 309 There are security issues involved any time users exchange 310 data. While these are not to be minimized, neither does this 311 memo change the status quo in that regard, except in one 312 instance. 314 Since this memo provides a way for the sender to suggest a 315 filename, a receiving MUA must take care that the sender's 316 suggested filename does not represent a hazard. Using UNIX as 317 an example, some hazards would be: 319 + Creating startup files (e.g., ".login"). 321 + Creating or overwriting system files (e.g., 322 "/etc/passwd"). 324 + Overwriting any existing file. 326 + Placing executable files into any command search path 327 (e.g., "~/bin/more"). 329 + Sending the file to a pipe (e.g., "| sh"). 331 In general, the receiving MUA should never name or place the 332 file such that it will get interpreted or executed without 333 the user explicitly initiating the action. 335 It is very important to note that this is not an exhaustive 336 list; it is intended as a small set of examples only. 337 Implementors must be alert to the potential hazards on their 338 target systems. 340 7. Acknowledgements 342 We gratefully acknowledge the help these people provided 343 during the preparation of this draft: 345 Nathaniel Borenstein 346 Ned Freed 347 Keith Moore 348 Dave Crocker 349 Dan Pritchett 351 8. Authors' Addresses 353 Author: Rens Troost rens@imsi.com 355 Co-Author: Steve Dorner sdorner@qualcomm.com 357 9. References 359 [RFC 1521] 360 Borenstein N., and N. Freed, "MIME (Multipurpose Internet 361 Mail Extensions) Part One: Mechanisms for Specifying and 362 Describing the Format of Internet Message Bodies", 363 RFC 1521, Bellcore, Innosoft, September 1993. 365 [RFC 822] 366 Crocker, D., "Standard for the Format of ARPA Internet 367 Text Messages", STD 11, RFC 822, UDEL, August 1982.