idnits 2.17.1 draft-dorner-content-header-00.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-18) 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == 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. ** There are 5 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC1521], [RFC1522], [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 (August 1994) is 10839 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) ** Obsolete normative reference: RFC 1521 (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 1522 (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft: draft-dorner-content-header-00.txt 2 Rens Troost 3 Steve Dorner 4 August 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 [RFC 1522], and [RFC 822]. The information presented herein 46 supplements but does not replace that found in those 47 documents. 49 2. Introduction 51 [RFC 1521] describes a standard format for encapsulating 52 multiple pieces of heterogeneous data into a single Internet 53 message. That document does not address the issue of 54 presentation styles; it provides a framework for the 55 interchange of message content, but leaves presentation 56 issues solely in the hands of mail user agent (MUA) 57 implementors. 59 Two common ways of presenting multipart electronic messages 60 are as a main document with a list of separate attachments, 61 and as a single document with the various parts expanded 62 (displayed) inline. The display of an attachment is generally 63 construed to require positive action on the part of the 64 recipient, while inline message components are displayed 65 automatically when the message is viewed. A mechanism is 66 needed to allow the sender to transmit this sort of 67 presentational information to the recipient; the 68 Content-Disposition header provides this mechanism, allowing 69 each component of a message to be tagged with an indication 70 of its desired presentation semantics. 72 Tagging messages in this manner will often be sufficient for 73 basic message formatting. However, in many cases a more 74 powerful and flexible approach will be necessary. The 75 definition of such approaches is beyond the scope of this 76 memo; however, such approaches can benefit from additional 77 Content-Disposition values and parameters, to be defined at a 78 later date. 80 In addition to allowing the sender to specify the 81 presentational disposition of a message component, it is 82 desirable to allow her to indicate a default archival 83 disposition; a filename. The optional "filename" parameter 84 provides for this. 86 3. The Content-Disposition Header Field 88 Content-Disposition is an optional header; In its absence, 89 presentation should default to `inline'. 91 It is desirable to keep the set of possible disposition types 92 small and well defined, to avoid needless complexity. Even 93 so, evolving usage will likely require the definition of 94 additional disposition types or parameters, so the set of 95 disposition values is extensible; see below. 97 In the extended BNF notation of [RFC 822], the 98 Content-Disposition header field is defined as follows: 100 disposition := "Content-Disposition" ":" 101 disposition-type 102 *(";" disposition-parm) 104 disposition-type := "inline" 105 / "attachment" 106 / extension-token 107 ; values are not case-sensitive 109 disposition-parm := filename-parm / extension-parm 111 filename-parm := "filename" "=" filename; 113 filename := token / quoted-string / quoted-phrase 115 quoted-phrase := <"> 1*(atom/encoded-word) <"> 117 `Extension-token', `extension-parm', `token', 118 `quoted-string', `atom', and `encoded-word' are defined 119 according to [RFC 822] and [RFC 1521] and [RFC 1522]. 121 3.1 The Inline Disposition Type 123 A bodypart should be marked `inline' if it is intended to be 124 displayed automatically upon display of the message. Inline 125 bodyparts should be presented in the order in which they are 126 encountered, subject to the normal semantics of multipart 127 messages. 129 3.2 The Attachment Disposition Type 131 Bodyparts can be designated `attachment' to indicate that 132 they are separate from the main body of the mail message, and 133 that their display should not be automatic, but contingent 134 upon some further action of the user. The MUA might instead 135 present the user of a bitmap terminal with an iconic 136 representation of the attachments, or, on character 137 terminals, with a list of attachments from which the user 138 could select for viewing or storage. 140 3.3 The Filename Parameter 142 The sender may want to suggest a filename to be used if the 143 entity is detached and stored in a separate file. If the 144 receiving MUA writes the entity to a file, the suggested 145 filename should be used where possible. 147 It is important that the receiving MUA not simply blindly use 148 the suggested filename. The suggested filename should be 149 checked (and possibly changed) to see that it conforms to 150 local filesystem conventions and that it does not present a 151 security problem (see Security Considerations below). 153 The value of the filename parameter must be in US-ASCII. 154 However, it is possible to use arbitrary characters in the 155 filename by using the "quoted- phrase" construct and 156 [RFC 1522] encoding. There is an ambiguity between 157 quoted-string and quoted-phrase. It should be resolved in 158 favor of the quoted-phrase when possible; a filename fitting 159 the syntax of a series of encoded-words and atoms should be 160 treated as such. 162 The presence of the filename parameter does not force an 163 implementation to write the entity to a separate file. It is 164 perfectly acceptable for implementations to leave the entity 165 as part of the normal mail stream unless the user requests 166 otherwise. As a consequence, the parameter may be used on any 167 MIME entity, even `inline' ones. These will not normally be 168 written to files, but the parameter could be used to provide 169 a filename if the receiving user should choose to write the 170 part to a file. 172 3.4 Future Extensions and Unrecognized Disposition Types 174 In the likely event that new parameters or types are needed, 175 they should be registered with the IANA, in the manner 176 specified in [RFC 1521], appendix E. 178 Once new types and parameters are defined, there is of course 179 the likelihood that implementations will see types and 180 parameters they do not understand. Furthermore, since 181 x-tokens are allowed, implementations may also see entirely 182 unregistered types and parameters. 184 Unrecognized parameters should be ignored. Unrecognized types 185 should be treated as `attachment'. The choice of `attachment' 186 for unrecognized types is made because a sender who goes to 187 the trouble of producing a Content- Disposition header with a 188 new value is more likely aiming for something more elaborate 189 than inline presentation. 191 3.5 Content-Disposition and Multipart 193 If a Content-Disposition header is used on a multipart body 194 part, it applies to the multipart as a whole, not the 195 individual subparts. The disposition types of the subparts 196 do not need to be consulted until the multipart itself is 197 presented. When the multipart is displayed, then the 198 dispositions of the subparts should be respected. 200 If the `inline' disposition is used, the multipart should be 201 displayed as normal; however, an `attachment' subpart should 202 require action from the user to display. 204 If the `attachment' disposition is used, presentation of the 205 multipart should not proceed without explicit user action. 206 Once the user has chosen to display the multipart, the 207 individual subpart dispositions should be consulted to 208 determine how to present the subparts. 210 3.6 Content-Disposition and the Main Message 212 It is permissible to use Content-Disposition on the main body 213 of an [RFC 822] message. Althouth the meanings of the two 214 current dispositions (`inline' and `attachment') are 215 respectively vacuous and undefined, it is anticipated that 216 future dispositions might be more amenable for use with main 217 messages (one might imagine a "print" disposition to 218 implement a print-by-mail service, for example). 220 4. Examples 222 Here is a an example of a message containing a gif image that 223 is intended to be viewed by the user immediately: 225 MIME-Version: 1.0 226 Content-Type: image/gif 227 Content-Disposition: inline 228 Content-Description: just a small picture of me 230 232 The following message contains a gif image should be 233 displayed to the user only if the user requests it. If the 234 gif is written to a file, the file should be named 235 "genome.gif": 237 MIME-Version: 1.0 238 Content-Type: image/gif 239 Content-Disposition: attachment; filename=genome.gif 240 Content-Description: a complete map of the human genome 242 244 The following is an example of the use of the `attachment' 245 disposition with a multipart message. The user will should 246 see text-part-1 immediately, then take some action to view 247 multipart-2. After taking action to view multipart-2, the 248 user will see text-part-2 right away, and be required to take 249 action to view gif-1. Subparts are indented for clarity; 250 they would not be so indented in a real message. 252 MIME-Version: 1.0 253 Content-Type: multipart/mixed; boundary=outer 254 Content-Description: multipart-1 256 --outer 257 Content-Type: text/plain 258 Content-Disposition: inline 259 Content-Description: text-part-1 261 Some text goes here 263 --outer 264 Content-Type: multipart/mixed; boundary=inner 265 Content-Disposition: attachment 266 Content-Description: multipart-2 268 --inner 269 Content-Type: text/plain 270 Content-Disposition: inline 271 Content-Description: text-part-2 273 Some more text here. 275 --inner 276 Content-Type: image/gif 277 Content-Disposition: attachment 278 Content-Description: gif-1 280 281 --inner-- 282 --outer-- 284 5. Summary 286 Content-Disposition takes one of two values, `inline' and 287 `attachment'. 'Inline' indicates that the entity should be 288 immediately displayed to the user, whereas `attachment' means 289 that the user should take additional action to view the 290 entity. 292 The `filename' parameter can be used to suggest a filename 293 for storing the bodypart, if the user wishes to store it in 294 an external file. 296 6. Security Considerations 298 There are security issues involved any time users exchange 299 data. While these are not to be minimized, neither does this 300 memo change the status quo in that regard, except in one 301 instance. 303 Since this memo provides a way for the sender to suggest a 304 filename, a receiving MUA must take care that the sender's 305 suggested filename does not represent a hazard. Using UNIX as 306 an example, some hazards would be: 308 o+ Creating startup files (e.g., ".login"). 310 o+ Creating or overwriting system files (e.g., 311 "/etc/passwd"). 313 o+ Overwriting any existing file. 315 o+ Placing executable files into any command search path 316 (e.g., "~/bin/more"). 318 o+ Sending the file to a pipe (e.g., "| sh"). 320 In general, the receiving MUA should never name or place the 321 file such that it will get interpreted or executed without 322 the user explicitly initiating the action. 324 7. Acknowledgements 326 We gratefully acknowledge the help these people provided 327 during the preparation of this draft: 329 Nathaniel Borenstein 330 Ned Freed 331 Keith Moore 332 Dave Crocker 333 Dan Pritchett 335 8. Authors' Addresses 337 Author: Rens Troost rens@imsi.com 339 Co-Author: Steve Dorner sdorner@qualcomm.com 341 9. References 343 [RFC 1521] 344 Borenstein N., and N. Freed, "MIME (Multipurpose Internet 345 Mail Extensions) Part One: Mechanisms for Specifying and 346 Describing the Format of Internet Message Bodies", 347 RFC 1521, Bellcore, Innosoft, September 1993. 349 [RFC 1522] 350 Moore, K., "MIME (Multipurpose Internet Mail Extensions) 351 Part Two: Message Header Extensions for Non-ASCII Text", 352 RFC 1522, University of Tennesee, September 1993. 354 [RFC 822] 355 Crocker, D., "Standard for the Format of ARPA Internet 356 Text Messages", STD 11, RFC 822, UDEL, August 1982.