idnits 2.17.1 draft-moore-mime-cdisp-01.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-25) 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 11 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 127 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** The abstract seems to contain references ([RFC822]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 18 has weird spacing: '... This docum...' == Line 20 has weird spacing: '...its working g...' == Line 24 has weird spacing: '...months and ma...' == Line 25 has weird spacing: '...iate to use ...' == Line 29 has weird spacing: '...ined in the ...' == (122 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (July 1997) is 9781 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: 'RFC 1521' is mentioned on line 199, but not defined ** Obsolete undefined reference: RFC 1521 (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) == Unused Reference: 'RFC 2046' is defined on line 427, but no explicit reference was found in the text == Unused Reference: 'RFC 2047' is defined on line 431, but no explicit reference was found in the text == Unused Reference: 'RFC 2048' is defined on line 438, but no explicit reference was found in the text == Unused Reference: 'RFC 2049' is defined on line 443, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-freed-pvcsc-01 ** Obsolete normative reference: RFC 2048 (Obsoleted by RFC 4288, RFC 4289) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) Summary: 13 errors (**), 0 flaws (~~), 15 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Troost 3 Internet-Draft New Century Systems 4 Expires: 10 January 1998 S. Dorner 5 QUALCOMM Incorporated 6 K. Moore, Editor 7 University of Tennessee 8 July 1997 10 Communicating Presentation Information in 11 Internet Messages: 12 The Content-Disposition Header Field 14 draft-moore-mime-cdisp-01.txt 16 Status of this Memo 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, and 20 its working groups. Note that other groups may also distribute working 21 documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents at 25 any time. It is not appropriate to use Internet-Drafts as reference 26 material or to cite them other than as ``work in progress.'' 28 To learn the current status of any Internet-Draft, please check the 29 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 30 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 31 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 32 ftp.isi.edu (US West Coast). 34 Abstract 36 This memo provides a mechanism whereby messages conforming to the 37 MIME specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049] 38 can convey presentational information. It specifies the "Content-Dispo- 39 sition" header field, which is optional and valid for any MIME entity 40 ("message" or "body part"). Two values for this header field are 41 described in this memo; one for the ordinary linear presentation of the 42 body part, and another to facilitate the use of mail to transfer files. 43 It is expected that more values will be defined in the future, and pro- 44 cedures are defined for extending this set of values. 46 This document is intended as an extension to MIME. As such, the 47 reader is assumed to be familiar with the MIME specifications, and 48 [RFC 822]. The information presented herein supplements but does not 49 Content-Disposition 10 July 1997 51 replace that found in those documents. 53 This document is a revision to the Experimental protocol defined in 54 RFC 1806. As compared to RFC 1806, this document contains minor edito- 55 rial updates, adds new parameters needed to support the File Transfer 56 Body Part, and references a separate specification for the handling of 57 non-ASCII and/or very long parameter values. 59 1. Introduction 61 MIME specifies a standard format for encapsulating multiple pieces 62 of data into a single Internet message. That document does not address 63 the issue of presentation styles; it provides a framework for the inter- 64 change of message content, but leaves presentation issues solely in the 65 hands of mail user agent (MUA) implementors. 67 Two common ways of presenting multipart electronic messages are as 68 a main document with a list of separate attachments, and as a single 69 document with the various parts expanded (displayed) inline. The display 70 of an attachment is generally construed to require positive action on 71 the part of the recipient, while inline message components are displayed 72 automatically when the message is viewed. A mechanism is needed to allow 73 the sender to transmit this sort of presentational information to the 74 recipient; the Content-Disposition header provides this mechanism, 75 allowing each component of a message to be tagged with an indication of 76 its desired presentation semantics. 78 Tagging messages in this manner will often be sufficient for basic 79 message formatting. However, in many cases a more powerful and flexible 80 approach will be necessary. The definition of such approaches is beyond 81 the scope of this memo; however, such approaches can benefit from addi- 82 tional Content-Disposition values and parameters, to be defined at a 83 later date. 85 In addition to allowing the sender to specify the presentational 86 disposition of a message component, it is desirable to allow her to 87 indicate a default archival disposition; a filename. The optional "file- 88 name" parameter provides for this. Further, the creation-date, modifi- 89 cation-date, and read-date parameters allow preservation of those file 90 attributes when the file is transmitted over MIME email. 92 NB: The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, 93 SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in 94 this document, are to be interpreted as described in [DRAFT-KEYWORDS]. 96 Content-Disposition 10 July 1997 98 2. The Content-Disposition Header Field 100 Content-Disposition is an optional header field. In its absence, 101 the MUA may use whatever presentation method it deems suitable. 103 It is desirable to keep the set of possible disposition types small 104 and well defined, to avoid needless complexity. Even so, evolving usage 105 will likely require the definition of additional disposition types or 106 parameters, so the set of disposition values is extensible; see below. 108 In the extended BNF notation of [RFC 822], the Content-Disposition 109 header field is defined as follows: 111 disposition := "Content-Disposition" ":" 112 disposition-type 113 *(";" disposition-parm) 115 disposition-type := "inline" 116 / "attachment" 117 / extension-token 118 ; values are not case-sensitive 120 disposition-parm := filename-parm 121 / creation-date-parm 122 / modification-date-parm 123 / read-date-parm 124 / size-parm 125 / parameter 127 filename-parm := "filename" "=" value 129 creation-date-parm := "creation-date" "=" quoted-date-time 131 modification-date-parm := "modification-date" "=" quoted-date-time 133 read-date-parm := "read-date" "=" quoted-date-time 135 size-parm := "size" "=" 1*DIGIT 137 quoted-date-time := quoted-string 138 ; contents MUST be an RFC 822 `date-time' 139 ; numeric timezones (+HHMM or -HHMM) MUST be used 141 NOTE ON PARAMETER VALUE LENGHTS: A short (length <= 78 characters) 142 parameter value containing only non-`tspecials' characters SHOULD be 143 represented as a single `token'. A short parameter value containing 144 Content-Disposition 10 July 1997 146 only ASCII characters, but including `tspecials' characters, SHOULD be 147 represented as `quoted-string'. Parameter values longer than 78 charac- 148 ters, or which contain non-ASCII characters, MUST be encoded as speci- 149 fied in [DRAFT-PVCSC]. 151 `Extension-token', `parameter', `tspecials' and `value' are defined 152 according to [RFC 2045] (which references [RFC 822] in the definition of 153 some of these tokens). `quoted-string' and `DIGIT' are defined in 154 [RFC 822]. 156 2.1 The Inline Disposition Type 158 A bodypart should be marked `inline' if it is intended to be dis- 159 played automatically upon display of the message. Inline bodyparts 160 should be presented in the order in which they occur, subject to the 161 normal semantics of multipart messages. 163 2.2 The Attachment Disposition Type 165 Bodyparts can be designated `attachment' to indicate that they are 166 separate from the main body of the mail message, and that their display 167 should not be automatic, but contingent upon some further action of the 168 user. The MUA might instead present the user of a bitmap terminal with 169 an iconic representation of the attachments, or, on character terminals, 170 with a list of attachments from which the user could select for viewing 171 or storage. 173 2.3 The Filename Parameter 175 The sender may want to suggest a filename to be used if the entity 176 is detached and stored in a separate file. If the receiving MUA writes 177 the entity to a file, the suggested filename should be used as a basis 178 for the actual filename, where possible. 180 It is important that the receiving MUA not blindly use the sug- 181 gested filename. The suggested filename SHOULD be checked (and possibly 182 changed) to see that it conforms to local filesystem conventions, does 183 not overwrite an existing file, and does not present a security problem 184 (see Security Considerations below). 186 The receiving MUA SHOULD NOT respect any directory path information 187 that may seem to be present in the filename parameter. The filename 188 should be treated as a terminal component only. Portable specification 189 of directory paths might possibly be done in the future via a separate 190 Content-Disposition parameter, but no provision is made for it in this 191 draft. 193 Content-Disposition 10 July 1997 195 Current [RFC 2045] grammar restricts parameter values (and hence 196 Content-Disposition filenames) to US-ASCII. We recognize the great 197 desirability of allowing arbitrary character sets in filenames, but it 198 is beyond the scope of this document to define the necessary mechanisms. 199 We expect that the basic [RFC 1521] `value' specification will someday 200 be amended to allow use of non-US-ASCII characters, at which time the 201 same mechanism should be used in the Content-Disposition filename param- 202 eter. 204 Beyond the limitation to US-ASCII, the sending MUA may wish to bear 205 in mind the limitations of common filesystems. Many have severe length 206 and character set restrictions. Short alphanumeric filenames are least 207 likely to require modification by the receiving system. 209 The presence of the filename parameter does not force an implemen- 210 tation to write the entity to a separate file. It is perfectly accept- 211 able for implementations to leave the entity as part of the normal mail 212 stream unless the user requests otherwise. As a consequence, the parame- 213 ter may be used on any MIME entity, even `inline' ones. These will not 214 normally be written to files, but the parameter could be used to provide 215 a filename if the receiving user should choose to write the part to a 216 file. 218 2.4 The Creation-Date parameter 220 The creation-date parameter MAY be used to indicate the date at 221 which the file was created. If this parameter is included, the paramter 222 value MUST be a quoted-string which contains a representation of the 223 creation date of the file in [RFC 822] `date-time' format. 225 UNIX and POSIX implementors are cautioned that the `st_ctime' file 226 attribute of the `stat' structure is not the creation time of the file; 227 it is thus not appropriate as a source for the creation-date parameter 228 value. 230 2.5 The Modification-Date parameter 232 The modification-date parameter MAY be used to indicate the date at 233 which the file was last modified. If the modification-date parameter is 234 included, the paramter value MUST be a quoted-string which contains a 235 representation of the last modification date of the file in [RFC 822] 236 `date-time' format. 238 2.6 The Read-Date parameter 240 The read-date parameter MAY be used to indicate the date at which 241 the file was last read. If the read-date parameter is included, the 242 parameter value MUST be a quoted-string which contains a representation 243 Content-Disposition 10 July 1997 245 of the last-read date of the file in [RFC 822] `date-time' format. 247 2.7 The Size parameter 249 The size parameter indicates an approximate size of the file in 250 octets. It can be used, for example, to pre-allocate space before 251 attempting to store the file, or to determine whether enough space 252 exists. 254 2.8 Future Extensions and Unrecognized Disposition Types 256 In the likely event that new parameters or disposition types are 257 needed, they should be registered with the Internet Assigned Numbers 258 Authority (IANA), in the manner specified in Section 9 of this memo. 260 Once new disposition types and parameters are defined, there is of 261 course the likelihood that implementations will see disposition types 262 and parameters they do not understand. Furthermore, since x-tokens are 263 allowed, implementations may also see entirely unregistered disposition 264 types and parameters. 266 Unrecognized parameters should be ignored. Unrecognized disposition 267 types should be treated as `attachment'. The choice of `attachment' for 268 unrecognized types is made because a sender who goes to the trouble of 269 producing a Content-Disposition header with a new disposition type is 270 more likely aiming for something more elaborate than inline presenta- 271 tion. 273 Unless noted otherwise in the definition of a parameter, Content- 274 Disposition parameters are valid for all dispositions. (In contrast to 275 MIME content-type parameters, which are defined on a per-content-type 276 basis.) Thus, for example, the `filename' parameter still means the name 277 of the file to which the part should be written, even if the disposition 278 itself is unrecognized. 280 2.9 Content-Disposition and Multipart 282 If a Content-Disposition header is used on a multipart body part, 283 it applies to the multipart as a whole, not the individual subparts. 284 The disposition types of the subparts do not need to be consulted until 285 the multipart itself is presented. When the multipart is displayed, 286 then the dispositions of the subparts should be respected. 288 If the `inline' disposition is used, the multipart should be dis- 289 played as normal; however, an `attachment' subpart should require action 290 from the user to display. 292 Content-Disposition 10 July 1997 294 If the `attachment' disposition is used, presentation of the multi- 295 part should not proceed without explicit user action. Once the user has 296 chosen to display the multipart, the individual subpart dispositions 297 should be consulted to determine how to present the subparts. 299 2.10 Content-Disposition and the Main Message 301 It is permissible to use Content-Disposition on the main body of an 302 [RFC 822] message. 304 3. Examples 306 Here is a an example of a body part containing a JPEG image that is 307 intended to be viewed by the user immediately: 309 Content-Type: image/jpeg 310 Content-Disposition: inline 311 Content-Description: just a small picture of me 313 315 The following body part contains a JPEG image that should be displayed 316 to the user only if the user requests it. If the JPEG is written to a 317 file, the file should be named "genome.jpg". The recipient's user might 318 also choose to set the last-modified date of the stored file to date in 319 the modification-date parameter: 321 Content-Type: image/jpeg 322 Content-Disposition: attachment; filename=genome.jpeg; 323 modification-date="Wed, 12 Feb 1997 16:29:51 -0500"; 324 Content-Description: a complete map of the human genome 326 328 The following is an example of the use of the `attachment' disposition 329 with a multipart body part. The user should see text- part-1 immedi- 330 ately, then take some action to view multipart-2. After taking action 331 to view multipart-2, the user will see text-part-2 right away, and be 332 required to take action to view jpeg-1. Subparts are indented for clar- 333 ity; they would not be so indented in a real message. 335 Content-Disposition 10 July 1997 337 Content-Type: multipart/mixed; boundary=outer 338 Content-Description: multipart-1 340 --outer 341 Content-Type: text/plain 342 Content-Disposition: inline 343 Content-Description: text-part-1 345 Some text goes here 347 --outer 348 Content-Type: multipart/mixed; boundary=inner 349 Content-Disposition: attachment 350 Content-Description: multipart-2 352 --inner 353 Content-Type: text/plain 354 Content-Disposition: inline 355 Content-Description: text-part-2 357 Some more text here. 359 --inner 360 Content-Type: image/jpeg 361 Content-Disposition: attachment 362 Content-Description: jpeg-1 364 365 --inner-- 366 --outer-- 368 4. Summary 370 Content-Disposition takes one of two values, `inline' and `attach- 371 ment'. `Inline' indicates that the entity should be immediately dis- 372 played to the user, whereas `attachment' means that the user should take 373 additional action to view the entity. 375 The `filename' parameter can be used to suggest a filename for 376 storing the bodypart, if the user wishes to store it in an external 377 file. 379 5. Security Considerations 381 There are security issues involved any time users exchange data. 382 While these are not to be minimized, neither does this memo change the 383 status quo in that regard, except in one instance. 385 Content-Disposition 10 July 1997 387 Since this memo provides a way for the sender to suggest a file- 388 name, a receiving MUA must take care that the sender's suggested file- 389 name does not represent a hazard. Using UNIX as an example, some hazards 390 would be: 392 + Creating startup files (e.g., ".login"). 394 + Creating or overwriting system files (e.g., "/etc/passwd"). 396 + Overwriting any existing file. 398 + Placing executable files into any command search path (e.g., 399 "~/bin/more"). 401 + Sending the file to a pipe (e.g., "| sh"). 403 In general, the receiving MUA should not name or place the file 404 such that it will get interpreted or executed without the user explic- 405 itly initiating the action. 407 It is very important to note that this is not an exhaustive list; 408 it is intended as a small set of examples only. Implementors must be 409 alert to the potential hazards on their target systems. 411 6. References 413 [DRAFT-KEYWORDS] 414 Bradner, S. "Key words for use in RFCs to Indicate Requirement Lev- 415 els". RFC 2119, March 1997. 417 [DRAFT-PVCSC] 418 Freed, N. and Moore, K. "MIME Parameter value and Encoded Words: 419 Character Sets, Lanaguage, and Continuations". Internet-Draft 420 draft-freed-pvcsc-01.txt, November 1996. 422 [RFC 2045] 423 Freed, N. and Borenstein, N., "MIME (Multipurpose Internet Mail 424 Extensions) Part One: Format of Internet Message Bodies", RFC 2045, 425 December 1996. 427 [RFC 2046] 428 Freed, N. and Borenstein N., "MIME (Multipurpose Internet Mail 429 Extensions) Part Two: Media Types", RFC 2046, December 1996. 431 [RFC 2047] 432 Moore, K. "MIME (Multipurpose Internet Mail Extensions) Part Three: 433 Message Header Extensions for non-ASCII Text", RFC 2047, December 434 1996. 436 Content-Disposition 10 July 1997 438 [RFC 2048] 439 Freed, N., Klensin, J. and Postel, J., "MIME (Multipurpose Internet 440 Mail Extensions) Part Four: Registration Procedures", RFC 2048, 441 December 1996. 443 [RFC 2049] 444 Freed, N. and Borenstein N., "MIME (Multipurpose Internet Mail 445 Extensions) Part Five: Conformance Criteria and Examples", RFC 446 2049, December 1996. 448 [RFC 822] 449 Crocker, D., "Standard for the Format of ARPA Internet Text Mes- 450 sages", STD 11, RFC 822, UDEL, August 1982. 452 7. Acknowledgements 454 We gratefully acknowledge the help these people provided during the 455 preparation of this draft: 457 Nathaniel Borenstein 458 Ned Freed 459 Keith Moore 460 Dave Crocker 461 Dan Pritchett 463 8. Authors' Addresses 465 You should blame the editor of this version of the document for any 466 changes since RFC 1806: 468 Keith Moore 469 Department of Computer Science 470 University of Tennessee, Knoxville 471 107 Ayres Hall 472 Knoxville TN 37996-1301 473 USA 475 Phone: +1 (423) 974-5067 476 Fax: +1 (423) 974-8296 477 Email: moore@cs.utk.edu 479 The authors of RFC 1806 are: 481 Content-Disposition 10 July 1997 483 Rens Troost 484 New Century Systems 485 324 East 41st Street #804 486 New York, NY, 10017 USA 488 Phone: +1 (212) 557-2050 489 Fax: +1 (212) 557-2049 490 EMail: rens@century.com 492 Steve Dorner 493 QUALCOMM Incorporated 494 6455 Lusk Boulevard 495 San Diego, CA 92121 496 USA 498 EMail: sdorner@qualcomm.com 500 9. Registration of New Content-Disposition Values and Parameters 502 New Content-Disposition values (besides "inline" and "attachment") 503 may be defined only by Internet standards-track documents, or in Experi- 504 mental documents approved by the Internet Engineering Steering Group. 506 New content-disposition parameters may be registered by supplying 507 the information in the following template and sending it via electronic 508 mail to IANA@IANA.ORG: 510 To: IANA@IANA.ORG 511 Subject: Registration of new Content-Disposition parameter 513 Content-Disposition parameter name: 515 Allowable values for this parameter: 516 (If the parameter can only assume a small number of values, 517 list each of those values. Otherwise, describe the values 518 that the parameter can assume.) 519 Description: 520 (What is the purpose of this parameter and how is it used?) 522 10. Changes since RFC 1806 524 The following changes have been made since the earlier version of 525 this document, published in RFC 1806 as an Experimental protocol: 527 Content-Disposition 10 July 1997 529 + Updated references to MIME documents. In some cases this involved 530 substituting a reference to one of the current MIME RFCs for a ref- 531 erence to RFC 1521; in other cases, a reference to RFC 1521 was 532 simply replaced with the word "MIME". 534 + Added a section on registration procedures, since none of the pro- 535 cedures in RFC 2048 seemed to be appropriate. 537 + Added new parameter types: creation-date, modification-date, read- 538 date, and size. 540 + Incorporated a reference to draft-freed-pvcsc-* for encoding long 541 or non-ASCII parameter values. 543 + Added reference to RFC 2119 to define MUST, SHOULD, etc. keywords.