rfc7578v3.txt		rfc7578.txt
	Internet Engineering Task Force (IETF) L. Masinter		Internet Engineering Task Force (IETF) L. Masinter
	Request for Comments: 7578 Adobe		Request for Comments: 7578 Adobe
	Obsoletes: 2388 June 2015		Obsoletes: 2388 July 2015
	Category: Standards Track		Category: Standards Track
	ISSN: 2070-1721		ISSN: 2070-1721
	Returning Values from Forms: multipart/form-data		Returning Values from Forms: multipart/form-data
	Abstract		Abstract
	This specification defines the multipart/form-data media type, which		This specification defines the multipart/form-data media type, which
	can be used by a wide variety of applications and transported by a		can be used by a wide variety of applications and transported by a
	wide variety of protocols as a way of returning a set of values as		wide variety of protocols as a way of returning a set of values as
	skipping to change at page 2, line 34		skipping to change at page 2, line 34
	5.1.3. Parsing and Interpreting Form Data . . . . . . . . . 8		5.1.3. Parsing and Interpreting Form Data . . . . . . . . . 8
	5.2. Ordered Fields and Duplicated Field Names . . . . . . . . 8		5.2. Ordered Fields and Duplicated Field Names . . . . . . . . 8
	5.3. Interoperability with Web Applications . . . . . . . . . 8		5.3. Interoperability with Web Applications . . . . . . . . . 8
	5.4. Correlating Form Data with the Original Form . . . . . . 9		5.4. Correlating Form Data with the Original Form . . . . . . 9
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 9		7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	8. Media Type Registration for multipart/form-data . . . . . . . 10		8. Media Type Registration for multipart/form-data . . . . . . . 10
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	9.1. Normative References . . . . . . . . . . . . . . . . . . 11		9.1. Normative References . . . . . . . . . . . . . . . . . . 11
	9.2. Informative References . . . . . . . . . . . . . . . . . 12		9.2. Informative References . . . . . . . . . . . . . . . . . 12
	Appendix A. Changes from RFC 2388 . . . . . . . . . . . . . . . 14		Appendix A. Changes from RFC 2388 . . . . . . . . . . . . . . . 13
	Appendix B. Alternatives . . . . . . . . . . . . . . . . . . . . 14		Appendix B. Alternatives . . . . . . . . . . . . . . . . . . . . 13
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	In many applications, it is possible for a user to be presented with		In many applications, it is possible for a user to be presented with
	a form. The user will fill out the form, including information that		a form. The user will fill out the form, including information that
	is typed, generated by user input, or included from files that the		is typed, generated by user input, or included from files that the
	user has selected. When the form is filled out, the data from the		user has selected. When the form is filled out, the data from the
	form is sent from the user to the receiving application.		form is sent from the user to the receiving application.
	The definition of multipart/form-data is derived from one of those		The definition of multipart/form-data is derived from one of those
	skipping to change at page 8, line 19		skipping to change at page 8, line 19
	5.1.3. Parsing and Interpreting Form Data		5.1.3. Parsing and Interpreting Form Data
	While this specification provides guidance for the creation of		While this specification provides guidance for the creation of
	multipart/form-data, parsers and interpreters should be aware of the		multipart/form-data, parsers and interpreters should be aware of the
	variety of implementations. File systems differ as to whether and		variety of implementations. File systems differ as to whether and
	how they normalize Unicode names, for example. The matching of form		how they normalize Unicode names, for example. The matching of form
	elements to form-data parts may rely on a fuzzier match. In		elements to form-data parts may rely on a fuzzier match. In
	particular, some multipart/form-data generators might have followed		particular, some multipart/form-data generators might have followed
	the previous advice of [RFC2388] and used the "encoded-word" method		the previous advice of [RFC2388] and used the "encoded-word" method
	of encoding non-ASCII values, as described in [RFC2047] (using ABNF		of encoding non-ASCII values, as described in [RFC2047]:
	[RFC5234] syntax):
	encoded-word = "=?" charset "?" encoding "?" encoded-text "?="		encoded-word = "=?" charset "?" encoding "?" encoded-text "?="
	Others have been known to follow [RFC2231], to send unencoded UTF-8,		Others have been known to follow [RFC2231], to send unencoded UTF-8,
	or even to send strings encoded in the form-charset.		or even to send strings encoded in the form-charset.
	For this reason, interpreting multipart/form-data (even from		For this reason, interpreting multipart/form-data (even from
	conforming generators) may require knowing the charset used in form		conforming generators) may require knowing the charset used in form
	encoding in cases where the _charset_ field value or a charset		encoding in cases where the _charset_ field value or a charset
	parameter of a 'text/plain' Content-Type header field is not		parameter of a 'text/plain' Content-Type header field is not
	skipping to change at page 9, line 6		skipping to change at page 8, line 52
	Many web applications use the 'application/x-www-form-urlencoded'		Many web applications use the 'application/x-www-form-urlencoded'
	method for returning data from forms. This format is quite compact,		method for returning data from forms. This format is quite compact,
	for example:		for example:
	name=Xavier+Xantico&verdict=Yes&colour=Blue&happy=sad&Utf%F6r=Send		name=Xavier+Xantico&verdict=Yes&colour=Blue&happy=sad&Utf%F6r=Send
	However, there is no opportunity to label the enclosed data with a		However, there is no opportunity to label the enclosed data with a
	content type, apply a charset, or use other encoding mechanisms.		content type, apply a charset, or use other encoding mechanisms.
	Many form-interpreting programs (primarily web browsers) now		Many form-interpreting programs (primarily web browsers) now
	implement and generate multipart/form-data, but an existing		implement and generate multipart/form-data, but a receiving
	application might need to optionally support the 'application/x-www-		application might also need to support the 'application/x-www-form-
	form-urlencoded' format.		urlencoded' format.
	5.4. Correlating Form Data with the Original Form		5.4. Correlating Form Data with the Original Form
	This specification provides no specific mechanism by which multipart/		This specification provides no specific mechanism by which multipart/
	form-data can be associated with the form that caused it to be		form-data can be associated with the form that caused it to be
	transmitted. This separation is intentional; many different forms		transmitted. This separation is intentional; many different forms
	might be used for transmitting the same data. In practice,		might be used for transmitting the same data. In practice,
	applications may supply a specific form processing resource (in HTML,		applications may supply a specific form processing resource (in HTML,
	the ACTION attribute in a FORM tag) for each different form.		the ACTION attribute in a FORM tag) for each different form.
	Alternatively, data about the form might be encoded in a "hidden		Alternatively, data about the form might be encoded in a "hidden
	skipping to change at page 12, line 21		skipping to change at page 12, line 21
	[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded		[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
	Word Extensions: Character Sets, Languages, and		Word Extensions: Character Sets, Languages, and
	Continuations", RFC 2231, DOI 10.17487/RFC2231, November		Continuations", RFC 2231, DOI 10.17487/RFC2231, November
	1997, <http://www.rfc-editor.org/info/rfc2231>.		1997, <http://www.rfc-editor.org/info/rfc2231>.
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66, RFC		Resource Identifier (URI): Generic Syntax", STD 66, RFC
	3986, DOI 10.17487/RFC3986, January 2005,		3986, DOI 10.17487/RFC3986, January 2005,
	<http://www.rfc-editor.org/info/rfc3986>.		<http://www.rfc-editor.org/info/rfc3986>.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/
	RFC5234, January 2008,
	<http://www.rfc-editor.org/info/rfc5234>.
	9.2. Informative References		9.2. Informative References
	[RFC1867] Nebel, E. and L. Masinter, "Form-based File Upload in		[RFC1867] Nebel, E. and L. Masinter, "Form-based File Upload in
	HTML", RFC 1867, DOI 10.17487/RFC1867, November 1995,		HTML", RFC 1867, DOI 10.17487/RFC1867, November 1995,
	<http://www.rfc-editor.org/info/rfc1867>.		<http://www.rfc-editor.org/info/rfc1867>.
	[RFC2388] Masinter, L., "Returning Values from Forms: multipart/		[RFC2388] Masinter, L., "Returning Values from Forms: multipart/
	form-data", RFC 2388, DOI 10.17487/RFC2388, August 1998,		form-data", RFC 2388, DOI 10.17487/RFC2388, August 1998,
	<http://www.rfc-editor.org/info/rfc2388>.		<http://www.rfc-editor.org/info/rfc2388>.
	skipping to change at page 15, line 12		skipping to change at page 14, line 18
	Melnikov, Salvatore Loreto, Chris Lonvick, Kathleen Moriarty, Barry		Melnikov, Salvatore Loreto, Chris Lonvick, Kathleen Moriarty, Barry
	Leiba, Julian Reschke, Tom Petch, Ned Freed, Cedric Brancourt, as		Leiba, Julian Reschke, Tom Petch, Ned Freed, Cedric Brancourt, as
	well as others, including Ian Hickson, who requested it be produced		well as others, including Ian Hickson, who requested it be produced
	in the first place.		in the first place.
	Author's Address		Author's Address
	Larry Masinter		Larry Masinter
	Adobe		Adobe
	EMail: masinter@adobe.com		Email: masinter@adobe.com
	URI: http://larry.masinter.net		URI: http://larry.masinter.net
End of changes. 7 change blocks.
	15 lines changed or deleted		9 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/