idnits 2.17.1 draft-masinter-form-data-04.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): ---------------------------------------------------------------------------- ** 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. ** 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 1 longer page, the longest (page 1) being 347 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 6 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 3 instances of lines with control characters in the document. ** 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 130: '.... The sending application MAY supply a...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 25, 1998) is 9431 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: 'RFC1867' is mentioned on line 46, but not defined ** Obsolete undefined reference: RFC 1867 (Obsoleted by RFC 2854) == Unused Reference: 'RFC 2047' is defined on line 321, but no explicit reference was found in the text == Unused Reference: 'RFC 2231' is defined on line 324, but no explicit reference was found in the text == Unused Reference: 'RFC 1806' is defined on line 327, but no explicit reference was found in the text == Unused Reference: 'RFC 1867' is defined on line 331, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1806 (Obsoleted by RFC 2183) ** Obsolete normative reference: RFC 1867 (Obsoleted by RFC 2854) ** Obsolete normative reference: RFC 2184 (Obsoleted by RFC 2231) -- Possible downref: Non-RFC (?) normative reference: ref. 'HTML40' Summary: 16 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Larry Masinter 2 draft-masinter-form-data-04.txt Xerox Corporation 3 Expires in 6 months June 25, 1998 5 Returning Values from Forms: multipart/form-data 7 Status of this Memo 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its 11 areas, and its working groups. Note that other groups may also 12 distribute working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six 15 months and may be updated, replaced, or obsoleted by other 16 documents at any time. It is inappropriate to use Internet- 17 Drafts as reference material or to cite them other than as 18 ``work in progress.'' 20 To view the entire list of current Internet-Drafts, please check 21 the "1id-abstracts.txt" listing contained in the Internet-Drafts 22 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 23 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 24 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 25 (US West Coast). 27 Copyright (C) 1998, The Internet Society. All Rights Reserved. 29 1. Abstract 31 This specification defines an Internet Media Type, 32 multipart/form-data, which can be used by a wide variety of 33 applications and transported by a wide variety of protocols as a 34 way of returning a set of values as the result of a user filling 35 out a form. 37 2. Introduction 39 In many applications, it is possible for a user to be presented with 40 a form. The user will fill out the form, including information that 41 is typed, generated by user input, or included from files that the 42 user has selected. When the form is filled out, the data from the 43 form is sent from the user to the receiving application. 45 The definition of MultiPart/Form-Data is derived from one of those 46 applications, originally set out in [RFC1867], and subsequently 47 incorporated into [HTML40], where forms are expressed in HTML, and in 48 which the form values are sent via HTTP or electronic mail. This 49 representation is widely implemented in numerous web browsers and 50 web servers. 52 However, multipart/form-data can be used for forms that are 53 presented using representations other than HTML (spreadsheets, 54 Portable Document Format, etc), and for transport using 55 other means than electronic mail or HTTP. This document defines the 56 representation of form values independently of the application for 57 which it is used. 59 3. Definition of multipart/form-data 61 The media-type multipart/form-data follows the rules of all multipart 62 MIME data streams as outlined in [RFC 2046]. In forms, there are a 63 series of fields to be supplied by the user who fills out the 64 form. Each field has a name. Within a given form, the names are 65 unique. 67 "multipart/form-data" contains a series of parts. Each part is 68 expected to contain a content-disposition header [RFC 2183] where the 69 disposition type is "form-data", and where the disposition contains 70 an (additional) parameter of "name", where the value of that 71 parameter is the original field name in the form. For example, a part 72 might contain a header: 74 Content-Disposition: form-data; name="user" 76 with the value corresponding to the entry of the "user" field. 78 Field names originally in non-ASCII character sets may be encoded 79 within the value of the "name" parameter using the standard method 80 described in RFC 2047. 82 As with all multipart MIME types, each part has an optional 83 "Content-Type", which defaults to text/plain. If the contents of a 84 file are returned via filling out a form, then the file input is 85 identified as the appropriate media type, if known, or 86 "application/octet-stream". If multiple files are to be returned as 87 the result of a single form entry, they should be represented as a 88 "multipart/mixed" part embedded within the "multipart/form-data". 90 Each part may be encoded and the "content-transfer-encoding" header 91 supplied if the value of that part does not conform to the default 92 encoding. 94 4. Use of multipart/form-data 96 4.1 Boundary 98 As with other multipart types, a boundary is selected that does not 99 occur in any of the data. Each field of the form is sent, in the 100 order defined by the sending appliction and form, as a part of the 101 multipart stream. Each part identifies the INPUT name within the 102 original form. Each part should be labelled with an appropriate 103 content-type if the media type is known (e.g., inferred from the 104 file extension or operating system typing information) or as 105 "application/octet-stream". 107 4.2 Sets of files 109 If the value of a form field is a set of files rather than a single 110 file, that value can be transferred together using the 111 "multipart/mixed" format. 113 4.3 Encoding 115 While the HTTP protocol can transport arbitrary binary data, the 116 default for mail transport is the 7BIT encoding. The value supplied 117 for a part may need to be encoded and the "content-transfer-encoding" 118 header supplied if the value does not conform to the default 119 encoding. [See section 5 of RFC 2046 for more details.] 121 4.4 Other attributes 123 Forms may request file inputs from the user; the form software may 124 include the file name and other file attributes, as specified in 125 [RFC 2184]. 127 The original local file name may be supplied as well, either as a 128 "filename" parameter either of the "content-disposition: form-data" 129 header or, in the case of multiple files, in a "content-disposition: 130 file" header of the subpart. The sending application MAY supply a 131 file name; if the file name of the sender's operating system is not 132 in US-ASCII, the file name might be approximated, or encoded using 133 the method of RFC 2231. 135 This is a convenience for those cases where the files supplied by 136 the form might contain references to each other, e.g., a TeX file 137 and its .sty auxiliary style description. 139 4.5 Charset of text in form data 141 Each part of a multipart/form-data is supposed to have a content-type. 142 In the case where a field element is text, the charset parameter 143 for the text indicates the character encoding used. 145 For example, a form with a text field in which a user 146 typed 'Joe owes 100' where is the Euro symbol 147 might have form data returned as: 149 --AaB03x 150 content-disposition: form-data; name="field1" 151 content-type: text/plain;charset=windows-1250 152 content-transfer-encoding: quoted-printable 154 Joe owes =80100. 155 --AaB03x 157 5. Operability considerations 159 5.1 Compression, encryption 161 Some of the data in forms may be compressed or encrypted, using other 162 MIME mechanisms. This is a function of the application that is 163 generating the form-data. 165 5.2 Other data encodings rather than multipart 167 Various people have suggested using new mime top-level type 168 "aggregate", e.g., aggregate/mixed or a content-transfer-encoding of 169 "packet" to express indeterminate-length binary data, rather than 170 relying on the multipart-style boundaries. While this would be 171 useful, the "multipart" mechanisms are well established, simple to 172 implement on both the sending client and receiving server, and as 173 efficient as other methods of dealing with multiple combinations of 174 binary data. 176 The multipart/form-data encoding has a high overhead and performance 177 impact if there are many fields with short values. However, in 178 practice, for the forms in use, for example, in HTML, the average 179 overhead is not significant. 181 5.3 Remote files with third-party transfer 183 In some scenarios, the user operating the form software might want to 184 specify a URL for remote data rather than a local file. In this case, 185 is there a way to allow the browser to send to the client a pointer 186 to the external data rather than the entire contents? This capability 187 could be implemented, for example, by having the client send to the 188 server data of type "message/external-body" with "access-type" set 189 to, say, "uri", and the URL of the remote data in the body of the 190 message. 192 5.4 Non-ASCII field names 194 Note that MIME headers are generally required to consist only of 7- 195 bit data in the US-ASCII character set. Hence field names should be 196 encoded according to the method in RFC 2047 if they contain 197 characters outside of that set. 199 5.5 Ordered fields and duplicated field names 201 The relationship of the ordering of fields within a form and the 202 ordering of returned values within "multipart/form-data" is not 203 defined by this specification, nor is the handling of the case where 204 a form has multiple fields with the same name. While HTML-based 205 forms may send back results in the order received, and intermediaries 206 should not reorder the results, there are some systems which 207 might not define a natural order for form fields. 209 5.6 Interoperability with web applications 211 Many web applications use the "application/x-url-encoded" 212 method for returning data from forms. This format is quite 213 compact, e.g.: 215 name=Xavier+Xantico&verdict=Yes&colour=Blue&happy=sad&Utf%F6r=Send 217 however, there is no opportunity to label the enclosed data 218 with content type, apply a charset, or use other encoding 219 mechanisms. 221 Many form-interpreting programs (primarly web browsers) now 222 implement and generate multipart/form-data, but an existing 223 application might need to optionally support both the 224 application/x-url-encoded format as well. 226 6. Security Considerations 228 The data format described in this document introduces no new 229 security considerations outside of those introduced by the 230 protocols that use it and of the component elements. It is 231 important when interpreting content-disposition to not overwrite 232 files in the recipients address space inadvertently. 234 User applications that request form information from users must be 235 careful not to cause a user to send information to the requestor or 236 a third party unwillingly or unwittingly. For example, a form might 237 request 'spam' information to be sent to an unintended third party, 238 or private information to be sent to someone that the user might 239 not actually intend. While this is primarily an issue for the 240 representation and interpretation of forms themselves, rather than 241 the data representation of the result of form transmission, the 242 transportation of private information must be done in a way that 243 does not expose it to unwanted prying. 245 With the introduction of form-data that can reasonably send back 246 the content of files from user's file space, the possibility that a 247 user might be sent an automated script that fills out a form and 248 then sends the user's local file to another address arises. Thus, 249 additional caution is required when executing automated scripting 250 where form-data might include user's files. 252 7. Author's Addresses 254 Larry Masinter 255 Xerox Palo Alto Research Center 256 3333 Coyote Hill Road 257 Palo Alto, CA 94304 258 Fax: +1 650 812 4333 259 EMail: masinter@parc.xerox.com 261 8. Copyright Notice 263 Copyright (C) The Internet Society 1998. All Rights Reserved. 265 This document and translations of it may be copied and furnished 266 to others, and derivative works that comment on or otherwise 267 explain it or assist in its implmentation may be prepared, copied, 268 published and distributed, in whole or in part, without 269 restriction of any kind, provided that the above copyright notice 270 and this paragraph are included on all such copies and derivative 271 works. However, this document itself may not be modified in any 272 way, such as by removing the copyright notice or references to the 273 Internet Society or other Internet organizations, except as needed 274 for the purpose of developing Internet standards in which case the 275 procedures for copyrights defined in the Internet Standards 276 process must be followed, or as required to translate it into 277 languages other than English. 279 The limited permissions granted above are perpetual and will not 280 be revoked by the Internet Society or its successors or assigns. 282 This document and the information contained herein is provided on 283 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 284 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 285 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 286 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 287 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 289 Appendix A. Media type registration for multipart/form-data 291 Media Type name: 292 multipart 294 Media subtype name: 295 form-data 297 Required parameters: 298 none 300 Optional parameters: 301 none 303 Encoding considerations: 304 No additional considerations other than as for other multipart types. 306 Security Considerations 307 Applications which receive forms and process them must be careful 308 not to supply data back to the requesting form processing site that 309 was not intended to be sent by the recipient. This is a consideration 310 for any application that generates a multipart/form-data. 312 The multipart/form-data type introduces no new security 313 considerations for recipients beyond what might occur with any of 314 the enclosed parts. 316 References 318 [RFC 2046] Multipurpose Internet Mail Extensions (MIME) Part Two: 319 Media Types. N. Freed & N. Borenstein, November 1996. 321 [RFC 2047] MIME (Multipurpose Internet Mail Extensions) Part Three: Message 322 Header Extensions for Non-ASCII Text. K. Moore. November 1996. 324 [RFC 2231] MIME Parameter Value and Encoded Word Extensions: Character Sets, 325 Languages, and Continuations. N. Freed, K. Moore. November 1997. 327 [RFC 1806] Communicating Presentation Information in Internet 328 Messages: The Content-Disposition Header. R. Troost & S. 329 Dorner, June 1995. 331 [RFC 1867] E. Nebel, L. Masinter. "Form-based File UPload in HTML." 332 RFC 1867, November 1995. 334 [RFC 2183] R. Troost, S. Dorner, K. Moore. "Communicating Presentation 335 Information in Internet Messages: The Content-Disposition 336 Header Field." August 1997. 338 [RFC 2184] N. Freed, K. Moore. "MIME Parameter Value and Encoded Word 339 Extensions: Character Sets, Languages, and Continuations." 340 August 1997. 342 [HTML40] D.Raggett, A. Le Hors, I. Jacobs. "HTML 4.0 Specificdation", 343 World Wide Web Consortium Technical Report "REC-html40", 344 December, 1997.