< draft-masinter-form-data-03.txt		draft-masinter-form-data-04.txt >
	Internet Draft Larry Masinter		Internet Draft Larry Masinter
	draft-masinter-form-data-03.txt Xerox Corporation		draft-masinter-form-data-04.txt Xerox Corporation
	Expires in 6 months March 6, 1998		Expires in 6 months June 25, 1998
	Obsoletes RFC 1867
	Returning Values from Forms: multipart/form-data		Returning Values from Forms: multipart/form-data
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft. Internet-Drafts are working		This document is an Internet-Draft. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its		documents of the Internet Engineering Task Force (IETF), its
	areas, and its working groups. Note that other groups may also		areas, and its working groups. Note that other groups may also
	distribute working documents as Internet-Drafts.		distribute working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other		months and may be updated, replaced, or obsoleted by other
	documents at any time. It is inappropriate to use Internet-		documents at any time. It is inappropriate to use Internet-
	Drafts as reference material or to cite them other than as		Drafts as reference material or to cite them other than as
	``work in progress.''		``work in progress.''
	To learn the current status of any Internet-Draft, please check		To view the entire list of current Internet-Drafts, please check
	the ``1id-abstracts.txt'' listing contained in the Internet-		the "1id-abstracts.txt" listing contained in the Internet-Drafts
	Drafts Shadow Directories on ftp.is.co.za (Africa),		Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
	nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),		(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
	ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).		(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
			(US West Coast).
	Copyright (C) 1998, The Internet Society. All Rights Reserved.		Copyright (C) 1998, The Internet Society. All Rights Reserved.
	1. Abstract		1. Abstract
	This specification defines an Internet Media Type,		This specification defines an Internet Media Type,
	multipart/form-data, which can be used by a wide variety of		multipart/form-data, which can be used by a wide variety of
	applications and transported by a wide variety of protocols as a		applications and transported by a wide variety of protocols as a
	way of returning a set of values as the result of a user filling		way of returning a set of values as the result of a user filling
	out a form.		out a form.
	skipping to change at line 55 ¶		skipping to change at line 54 ¶
	The definition of MultiPart/Form-Data is derived from one of those		The definition of MultiPart/Form-Data is derived from one of those
	applications, originally set out in [RFC1867], and subsequently		applications, originally set out in [RFC1867], and subsequently
	incorporated into [HTML40], where forms are expressed in HTML, and in		incorporated into [HTML40], where forms are expressed in HTML, and in
	which the form values are sent via HTTP or electronic mail. This		which the form values are sent via HTTP or electronic mail. This
	representation is widely implemented in numerous web browsers and		representation is widely implemented in numerous web browsers and
	web servers.		web servers.
	However, multipart/form-data can be used for forms that are		However, multipart/form-data can be used for forms that are
	presented using representations other than HTML (spreadsheets,		presented using representations other than HTML (spreadsheets,
	Adobe's Portable Document Format, etc), and for transport using		Portable Document Format, etc), and for transport using
	other means than electronic mail or HTTP. This document defines the		other means than electronic mail or HTTP. This document defines the
	representation of form values independently of the application for		representation of form values independently of the application for
	which it is used.		which it is used.
	3. Definition of multipart/form-data		3. Definition of multipart/form-data
	The media-type multipart/form-data follows the rules of all multipart		The media-type multipart/form-data follows the rules of all multipart
	MIME data streams as outlined in [RFC 2046]. In forms, there are a		MIME data streams as outlined in [RFC 2046]. In forms, there are a
	series of fields to be supplied by the user who fills out the		series of fields to be supplied by the user who fills out the
	form. Each field has a name. Within a given form, the names are		form. Each field has a name. Within a given form, the names are
	skipping to change at line 97 ¶		skipping to change at line 96 ¶
	"application/octet-stream". If multiple files are to be returned as		"application/octet-stream". If multiple files are to be returned as
	the result of a single form entry, they should be represented as a		the result of a single form entry, they should be represented as a
	"multipart/mixed" part embedded within the "multipart/form-data".		"multipart/mixed" part embedded within the "multipart/form-data".
	Each part may be encoded and the "content-transfer-encoding" header		Each part may be encoded and the "content-transfer-encoding" header
	supplied if the value of that part does not conform to the default		supplied if the value of that part does not conform to the default
	encoding.		encoding.
	4. Use of multipart/form-data		4. Use of multipart/form-data
			4.1 Boundary
	As with other multipart types, a boundary is selected that does not		As with other multipart types, a boundary is selected that does not
	occur in any of the data. Each field of the form is sent, in the		occur in any of the data. Each field of the form is sent, in the
	order defined by the sending appliction and form, as a part of the		order defined by the sending appliction and form, as a part of the
	multipart stream. Each part identifies the INPUT name within the		multipart stream. Each part identifies the INPUT name within the
	original form. Each part should be labelled with an appropriate		original form. Each part should be labelled with an appropriate
	content-type if the media type is known (e.g., inferred from the		content-type if the media type is known (e.g., inferred from the
	file extension or operating system typing information) or as		file extension or operating system typing information) or as
	"application/octet-stream".		"application/octet-stream".
			4.2 Sets of files
	If the value of a form field is a set of files rather than a single		If the value of a form field is a set of files rather than a single
	file, that value can be transferred together using the		file, that value can be transferred together using the
	"multipart/mixed" format.		"multipart/mixed" format.
			4.3 Encoding
	While the HTTP protocol can transport arbitrary binary data, the		While the HTTP protocol can transport arbitrary binary data, the
	default for mail transport is the 7BIT encoding. The value supplied		default for mail transport is the 7BIT encoding. The value supplied
	for a part may need to be encoded and the "content-transfer-encoding"		for a part may need to be encoded and the "content-transfer-encoding"
	header supplied if the value does not conform to the default		header supplied if the value does not conform to the default
	encoding. [See section 5 of RFC 2046 for more details.]		encoding. [See section 5 of RFC 2046 for more details.]
			4.4 Other attributes
	Forms may request file inputs from the user; the form software may		Forms may request file inputs from the user; the form software may
	include the file name and other file attributes, as specified in		include the file name and other file attributes, as specified in
	[RFC 2184].		[RFC 2184].
	The original local file name may be supplied as well, either as a		The original local file name may be supplied as well, either as a
	"filename" parameter either of the "content-disposition: form-data"		"filename" parameter either of the "content-disposition: form-data"
	header or, in the case of multiple files, in a "content-disposition:		header or, in the case of multiple files, in a "content-disposition:
	file" header of the subpart. The sending application MAY supply a		file" header of the subpart. The sending application MAY supply a
	file name; if the file name of the sender's operating system is not		file name; if the file name of the sender's operating system is not
	in US-ASCII, the file name might be approximated, or encoded using		in US-ASCII, the file name might be approximated, or encoded using
	the method of RFC 2231.		the method of RFC 2231.
	This is a convenience for those cases where, for example, the files		This is a convenience for those cases where the files supplied by
	supplied by the form might contain references to each other, e.g., a		the form might contain references to each other, e.g., a TeX file
	TeX file and its .sty auxiliary style description.		and its .sty auxiliary style description.
			4.5 Charset of text in form data
			Each part of a multipart/form-data is supposed to have a content-type.
			In the case where a field element is text, the charset parameter
			for the text indicates the character encoding used.
			For example, a form with a text field in which a user
			typed 'Joe owes <eu>100' where <eu> is the Euro symbol
			might have form data returned as:
			--AaB03x
			content-disposition: form-data; name="field1"
			content-type: text/plain;charset=windows-1250
			content-transfer-encoding: quoted-printable
			Joe owes =80100.
			--AaB03x
	5. Operability considerations		5. Operability considerations
	5.1 Compression, encryption		5.1 Compression, encryption
	Some of the data in forms may be compressed or encrypted, using other		Some of the data in forms may be compressed or encrypted, using other
	MIME mechanisms. This is a function of the application that is		MIME mechanisms. This is a function of the application that is
	generating the form-data.		generating the form-data.
	5.2 Other data encodings rather than multipart		5.2 Other data encodings rather than multipart
	skipping to change at line 179 ¶		skipping to change at line 204 ¶
	Note that MIME headers are generally required to consist only of 7-		Note that MIME headers are generally required to consist only of 7-
	bit data in the US-ASCII character set. Hence field names should be		bit data in the US-ASCII character set. Hence field names should be
	encoded according to the method in RFC 2047 if they contain		encoded according to the method in RFC 2047 if they contain
	characters outside of that set.		characters outside of that set.
	5.5 Ordered fields and duplicated field names		5.5 Ordered fields and duplicated field names
	The relationship of the ordering of fields within a form and the		The relationship of the ordering of fields within a form and the
	ordering of returned values within "multipart/form-data" is not		ordering of returned values within "multipart/form-data" is not
	defined by this specification, nor is the handling of the case where		defined by this specification, nor is the handling of the case where
	a form has multiple fields with the same name.		a form has multiple fields with the same name. While HTML-based
			forms may send back results in the order received, and intermediaries
			should not reorder the results, there are some systems which
			might not define a natural order for form fields.
			5.6 Interoperability with web applications
			Many web applications use the "application/x-url-encoded"
			method for returning data from forms. This format is quite
			compact, e.g.:
			name=Xavier+Xantico&verdict=Yes&colour=Blue&happy=sad&Utf%F6r=Send
			however, there is no opportunity to label the enclosed data
			with content type, apply a charset, or use other encoding
			mechanisms.
			Many form-interpreting programs (primarly web browsers) now
			implement and generate multipart/form-data, but an existing
			application might need to optionally support both the
			application/x-url-encoded format as well.
	6. Security Considerations		6. Security Considerations
	The data format described in this document introduces no new security		The data format described in this document introduces no new
	considerations outside of those introduced by the protocols that use		security considerations outside of those introduced by the
	it and of the component elements. It is important when interpreting		protocols that use it and of the component elements. It is
	content-disposition to not overwrite files in the recipients address		important when interpreting content-disposition to not overwrite
	space inadvertently.		files in the recipients address space inadvertently.
	User applications that request form information from users must be		User applications that request form information from users must be
	careful not to cause a user to send information to the requestor or a		careful not to cause a user to send information to the requestor or
	third party unwillingly or unwittingly. For example, a form might		a third party unwillingly or unwittingly. For example, a form might
	request 'spam' information to be sent to an unintended third party,		request 'spam' information to be sent to an unintended third party,
	or private information to be sent to someone that the user might not		or private information to be sent to someone that the user might
	actually intend. While this is primarily an issue for the		not actually intend. While this is primarily an issue for the
	representation and interpretation of forms themselves, rather than		representation and interpretation of forms themselves, rather than
	the data representation of the result of form transmission, the		the data representation of the result of form transmission, the
	transportation of private information must be done in a way that does		transportation of private information must be done in a way that
	not expose it to unwanted prying.		does not expose it to unwanted prying.
			With the introduction of form-data that can reasonably send back
			the content of files from user's file space, the possibility that a
			user might be sent an automated script that fills out a form and
			then sends the user's local file to another address arises. Thus,
			additional caution is required when executing automated scripting
			where form-data might include user's files.
	7. Author's Addresses		7. Author's Addresses
	Larry Masinter		Larry Masinter
	Xerox Palo Alto Research Center		Xerox Palo Alto Research Center
	3333 Coyote Hill Road		3333 Coyote Hill Road
	Palo Alto, CA 94304		Palo Alto, CA 94304
	Fax: +1 650 812 4333		Fax: +1 650 812 4333
	EMail: masinter@parc.xerox.com		EMail: masinter@parc.xerox.com
	skipping to change at line 293 ¶		skipping to change at line 345 ¶
	Information in Internet Messages: The Content-Disposition		Information in Internet Messages: The Content-Disposition
	Header Field." August 1997.		Header Field." August 1997.
	[RFC 2184] N. Freed, K. Moore. "MIME Parameter Value and Encoded Word		[RFC 2184] N. Freed, K. Moore. "MIME Parameter Value and Encoded Word
	Extensions: Character Sets, Languages, and Continuations."		Extensions: Character Sets, Languages, and Continuations."
	August 1997.		August 1997.
	[HTML40] D.Raggett, A. Le Hors, I. Jacobs. "HTML 4.0 Specificdation",		[HTML40] D.Raggett, A. Le Hors, I. Jacobs. "HTML 4.0 Specificdation",
	World Wide Web Consortium Technical Report "REC-html40",		World Wide Web Consortium Technical Report "REC-html40",
	December, 1997. <http://www.w3.org/TR/REC-html40/>		December, 1997. <http://www.w3.org/TR/REC-html40/>
End of changes. 15 change blocks.
	25 lines changed or deleted		77 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/