(Third? lost count) revised Registration of new Media Type multipart/form-data

Larry Masinter (masinter@parc.xerox.com)
Tue, 2 May 95 17:01:45 EDT

This is revised again as a result of previous comments. The published
specification is now contained within section 7 of the html-fileupload
proposal.
================================================================
Media Type name:
multipart

Media subtype name:
form-data

Required parameters:
none

Optional parameters:
none

Encoding considerations:
No additional considerations other than as for other multipart types.

Published specification:
section 7 of draft-ietf-html-fileupload-02.txt, included below

Security Considerations

The multipart/form-data type introduces no new security
considerations beyond what might occur with any of the enclosed
parts.

Person & email address to contact for further information:

Larry Masinter
masinter@parc.xerox.com

================================================================
Here is section 7 of draft-ietf-html-fileupload-02.txt:

7. Registration of multipart/form-data

The media-type multipart/form-data follows the rules of all
multipart MIME data streams as outlined in RFC 1521. It is intended
for use in returning the data that comes about from filling out a
form. In a form (in HTML, although other applications may also use
forms), there are a series of fields to be supplied by the user who
fills out the form. Each field has a name. The name of the field
is restricted to be a set of US-ASCII graphic characters; within a
given form, the names are unique.

multipart/form-data contains a series of parts. Each part is expected
to contain a content-disposition header where the value is
"form-data" and a name attribute specifies the field name within the
form, e.g., 'content-disposition: form-data; name="xxxxx"', where
xxxxx is the field name corresponding to that field. As with all
multipart MIME types, each part has an optional Content-Type which
defaults to text/plain.

Note that mime headers are generally required to consist only of
7-bit data in the US-ASCII character set. This specification thus
requires that the field names used consist of 7-bit ascii US
characters.

If the contents of a file are returned via filling out a form, then
the file input is identified as application/octet-stream or the
appropriate media type, if known. If multiple files are to be
returned as the result of a single form entry, they can be returned
as multipart/mixed embedded within the multipart/form-data.

The "content-transfer-encoding" header should be supplied for all
fields whose values do not conform to the default 7BIT encoding
(all characters 7-bit US-ASCII data with lines no longer than 1000
characters.)

Otherwise, file data and longer field values may be
transferred using a content-transfer-encoding appropriate to the
protocol of the ACTION in the form. For HTTP applications,
content-transfer-encoding of "binary" may be use. If the ACTION is
a "mailto:" URL, then the user agent may encode the data
appropriately to the mail transport mechanism. [See section 5 of
RFC 1521 for more details.]

File inputs may also identify the file name. The file name may be
described using the 'filename' parameter of the
"content-disposition" header. This is not required, but is strongly
recommended in any case where the original filename is known. This
is useful or necessary in many applications.