IPP> PRO - Suggested text for form-data

IPP> PRO - Suggested text for form-data

IPP> PRO - Suggested text for form-data

Larry Masinter masinter at parc.xerox.com
Thu Mar 20 00:04:40 EST 1997


This is a multi-part message in MIME format.


--------------68DD8D74DB2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


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.


--------------68DD8D74DB2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Subject: draft-masinter-form-data-00.txt
From: Larry Masinter <masinter at parc.xerox.com>
To: internet-drafts at ietf.org


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


   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.


   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.


   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.).


4. Operability considerations


4.1 Compression, encryption


   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


   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.3 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.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.


5. Security Considerations


   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
   Xerox Palo Alto Research Center
   3333 Coyote Hill Road
   Palo Alto, CA 94304


   Phone:  (415) 812-4365
   Fax:    (415) 812-4333
   EMail:   masinter at parc.xerox.com


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.


--------------68DD8D74DB2--



More information about the Ipp mailing list