IPP> PRO - Suggested text for form-data

IPP> PRO - Suggested text for form-data

IPP> PRO - Suggested text for form-data

Tom Hastings hastings at cp10.es.xerox.com
Tue Apr 1 16:42:10 EST 1997


Larry,


We were studying the suggested representation for IPP using
your proposal for form-data and could
not figure out how we would represent the IPP attribute tags (adornments).
Can you help us?  See section 5.1.3 in the Internet-Draft or Model 2.0
for the description of attribute tags.


Thanks,
Tom


At 21:04 03/19/97 PST, Larry Masinter wrote:
>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 <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.
>



More information about the Ipp mailing list