Subject: IPP> PRO - Suggested text for form-data

From: Carl-Uno Manros <[email-masked]>
Date: Wed, 19 Mar 1997 10:32:53 PST

Hi,

I was in Palo Alto yesterday and managed to corner Larry Masinter on the
form-data document.  He knocked up this version on-the-fly, and asked us to
give back any comments on the scope and content over the next couple of
days, make that Friday this week.  The document will initially be published
as a personal Internet-Draft from Larry, but can then proceed directly from
there to the standards process, without the need to go through any WG
(according to Larry).

Larry will send the document to the IETF before the deadline for Memphis.

Regards,

Carl-Uno

-- 
Internet Draft					Larry Masinter
March 18, 1997
Expires in 6 months	

                     multipart/form-data: a format
                   for returning the values obtained
                          from filling out a form

Status of this Memo

   Internet draft boilerplate
   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

1. Abstract

   This specification defines an Internet Media Type, multipart/form-data,
   which 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 the result of a user filling out a form. Typical applications
   include form values generated by HTML forms and submitted by
   HTTP post or by electronic mail, but the format is independent
   of those contexts. This data type is unchanged from its original
   description as part of RFC 1867.

2 Use of multipart/form-data

   The definition of multipart/form-data is included in section 3.  A
   boundary is selected that does not occur in any of the data. (This
   selection is sometimes done probabilisticly.) Each field of the form
   is sent, in the order in which it occurs in the form, as a part of
   the multipart stream.  Each part identifies the INPUT name within the
   original form. Each part should be labelled with an appropriate
   content-type if the media type is known (e.g., inferred from the file
   extension or operating system typing information) or as
   application/octet-stream.

   If multiple files are selected, they should be transferred together
   using the multipart/mixed format.

   While the HTTP protocol can transport arbitrary BINARY data, the
   default for mail transport (e.g., if the ACTION is a "mailto:" URL)
   is the 7BIT encoding.  The value supplied for a part may need to be
   encoded and the "content-transfer-encoding" header supplied if the
   value does not conform to the default encoding.  [See section 5 of
   RFC 1521 for more details.]

   The original local file name may be supplied as well, either as a
   'filename' parameter either of the 'content-disposition: form-data'
   header or in the case of multiple files in a 'content-disposition:
   file' header of the subpart. The client application should make best
   effort to supply the file name; if the file name of the client's
   operating system is not in US-ASCII, the file name might be
   approximated or encoded using the method of RFC 1522.  This is a
   convenience for those cases where, for example, the uploaded files
   might contain references to each other, e.g., a TeX file and its .sty
   auxiliary style description.

   On the server end, the ACTION might point to a HTTP URL that
   implements the forms action via CGI. In such a case, the CGI program
   would note that the content-type is multipart/form-data, parse the
   various fields (checking for validity, writing the file data to local
   files for subsequent processing, etc.).

3. definition 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. 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. Field names originally in
   non-ASCII character sets may be encoded using the method outlined in
   RFC 1522.

   As with all multipart MIME types, each part has an optional Content-
   Type which defaults to text/plain.  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.

   Each part may be encoded and the "content-transfer-encoding" header
   supplied if the value of that part does not conform to the default
   encoding.

   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.

4. Other considerations

4.1 Compression, encryption

   Some of the data in forms may be compressed or encrypted, using
   other MIME mechanisms.

4.2 Transmitting long files in form-data

   <discussion of how this can work>
   In some situations, it might be advisable to have the server validate
   various elements of the form data (user name, account, etc.)  before
   actually preparing to receive the data.  However, after some
   consideration, it seemed best to require that servers that wish to do
   this should implement this as a series of forms, where some of the
   data elements that were previously validated might be sent back to
   the client as 'hidden' fields, or by arranging the form so that the
   elements that need validation occur first.  This puts the onus of
   maintaining the state of a transaction only on those servers that
   wish to build a complex application, while allowing those cases that
   have simple input needs to be built simply.

   The HTTP protocol may require a content-length for the overall
   transmission. Even if it were not to do so, HTTP clients are
   encouraged to supply content-length for overall file input so that a
   busy server could detect if the proposed file data is too large to be
   processed reasonably and just return an error code and close the
   connection without waiting to process all of the incoming data.  Some
   current implementations of CGI require a content-length in all POST
   transactions.

   In any case, a HTTP server may abort a file upload in the middle of
   the transaction if the file being received is too large.

4.3 Other choices for return transmission of binary data

   Various people have suggested using new mime top-level type
   "aggregate", e.g., aggregate/mixed or a content-transfer-encoding of
   "packet" to express indeterminate-length binary data, rather than
   relying on the multipart-style boundaries.  While we are not opposed
   to doing so, this would require additional design and standardization
   work to get acceptance of "aggregate".  On the other hand, the
   'multipart' mechanisms are well established, simple to implement on
   both the sending client and receiving server, and as efficient as
   other methods of dealing with multiple combinations of binary data.

4.5 Transmitting form-data via mail

   Some forms will allow the results to be mailed, e.g., by supplying
   a "mailto" URL as the form's action.  In this case, a mail appropriate
   choice for encoding must be made for the form and its data.

4.6 Remote files with third-party transfer

   In some scenarios, the user operating the client software might want
   to specify a URL for remote data rather than a local file. In this
   case, is there a way to allow the browser to send to the client a
   pointer to the external data rather than the entire contents? This
   capability could be implemented, for example, by having the client
   send to the server data of type "message/external-body" with
   "access-type" set to, say, "uri", and the URL of the remote data in
   the body of the message.

4.7 CRLF used as line separator

   As with all MIME transmissions, CRLF is used as the separator for
   lines in a POST of the data in multipart/form-data.

4.8 Relationship to multipart/related

   The MIMESGML group is proposing a new type called multipart/related.
   While it contains similar features to multipart/form-data, the use
   and application of form-data is different enough that form-data is
   being described separately.

   It might be possible at some point to encode the result of HTML forms
   (including files) in a multipart/related body part; this is not
   incompatible with this proposal.

4.9 Non-ASCII field names

   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
   encoded according to the prescriptions of RFC 1522 if they contain
   characters outside of that set. In HTML 2.0, the default character
   set is ISO-8859-1, but non-ASCII characters in field names should be
   encoded.

5. Security Considerations

   TBD

6. Author's Addresses

   Larry Masinter
   Xerox Palo Alto Research Center
   3333 Coyote Hill Road
   Palo Alto, CA 94304

   Phone:  (415) 812-4365
   Fax:    (415) 812-4333
   EMail:   [email-masked]

Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: [email-masked]

---

From: [email-masked] (Robert Herriot)
Date: Wed, 19 Mar 1997 19:24:39 -0800

I have a few questions about form-data.

Am I correct in assuming that if a form does not have 
<FORM ENCTYPE="multipart/form-data", the data is send as a string
of several 'name=value', e.g. "foo=xxx&bar=yyy"?

When form-data is sent, what parts of the form are encoded in the
field data?  From examples in rfc1867, it appears to me that the
name of the field is encoded in the content-disposition field and that
the value is in the entity body. Am I right?  Are any other parts of
a form field returned with form-data?

The examples given in the protocol meeting implied that a selection
list would return the "name" of the value rather than the actual
string displayed to the user. 

The examples in rfc1867 help, but they don't cover many types of fields.

Can you provide more examples or tell me how other types of fields
are handled?

Thanks.

Bob Herriot

---

From: Larry Masinter <[email-masked]>
Date: Wed, 19 Mar 1997 21:04:40 PST

I submitted a new Internet Draft which is intended to go
into standards track, and just defines the internet media
type multipart/form-data independent of HTML.

I'm guessing there are still ambiguities in this document 
(since I mainly just cut and pasted from RFC 1867), but
still, I'd appreciate it if you could review the new document.
Subject: draft-masinter-form-data-00.txt
From: Larry Masinter <[email-masked]>
To: [email-masked]

Internet Draft                                  Larry Masinter
draft-masinter-form-data-00.txt                 Xerox Corporation
Expires in 6 months                            March 18, 1997

          Returning Values from Forms:  multipart/form-data

Status of this Memo

     This document is an Internet-Draft.  Internet-Drafts are working
     documents of the Internet Engineering Task Force (IETF), its
     areas, and its working groups.  Note that other groups may also
     distribute working documents as Internet-Drafts.

     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other
     documents at any time.  It is inappropriate to use Internet-
     Drafts as reference material or to cite them other than as
     ``work in progress.''

     To learn the current status of any Internet-Draft, please check
     the ``1id-abstracts.txt'' listing contained in the Internet-
     Drafts Shadow Directories on ftp.is.co.za (Africa),
     nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
     ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).

1. Abstract

   This specification defines an Internet Media Type,
   multipart/form-data, which 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 the result of a user filling
   out a form. Typical applications include form values generated by
   HTML forms and submitted by HTTP post or by electronic mail, but
   the format is independent of those contexts. The definition
   of multipart/form-data is derived from its original definition
   in RFC 1867.

2. Definition of multipart/form-data

   Forms may request file inputs from the user. Those 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.

3 Use of multipart/form-data

   As with other multipart types, a boundary is selected that does not
   occur in any of the data. (This selection is sometimes done
   probabilisticly.) Each field of the form is sent, in the order
   defined by the form, as a part of the multipart stream.  Each part
   identifies the INPUT name within the original form. Each part

   should be labelled with an appropriate content-type if the media
   type is known (e.g., inferred from the file extension or operating
   system typing information) or as application/octet-stream.

   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
   multipart/mixed format.

4. Operability considerations

   Some of the data in forms may be compressed or encrypted, using
   other MIME mechanisms. This is a function of the application
   that is generating the form-data.

4.2 Other data encodings rather than multipart

4.3 Remote files with third-party transfer

4.4 Non-ASCII field names

   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
   encoded according to the prescriptions of RFC 1522 if they contain
   characters outside of that set.

   The data format described in this document introduces no new
   security considerations outside of those introduced by the
   protocols that use it and of the component elements. It is important
   when interpreting content-disposition to not overwrite files
   in the recipients address space inadvertently.

6. Author's Addresses

   Larry Masinter

   Phone:  (415) 812-4365
   Fax:    (415) 812-4333

A. Media type registration for multipart/form-data

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:
 RFC 1867

Security Considerations

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

References

[RFC 1521] MIME (Multipurpose Internet Mail Extensions) Part One:
           Mechanisms for Specifying and Describing the Format of
           Internet Message Bodies.  N. Borenstein & N. Freed.
           September 1993.

[RFC 1522] MIME (Multipurpose Internet Mail Extensions) Part Two:
           Message Header Extensions for Non-ASCII Text. K. Moore.
           September 1993.

[RFC 1806] Communicating Presentation Information in Internet
           Messages: The Content-Disposition Header. R. Troost & S.
           Dorner, June 1995.

[RFC 1867] Form-based File UPload in HTML. E. Nebel, L. Masinter,
           November 1995.