mail should probably default to the "reply-to:" of the message.
   These two proposals would allow HTML forms to be served via HTTP
   servers but sent back via mail, or, alternatively, allow HTML forms
   to be sent by mail, filled out by HTML-aware mail recipients, and the
   results mailed back.

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

5.8 File transfer with ENCTYPE=x-www-form-urlencoded

   If a form contains <INPUT TYPE=file> elements but does not contain an
   ENCTYPE in the enclosing , the behavior is not specified.  It
   is probably inappropriate to attempt to URN-encode large quantities
   of data to servers that don't expect it.

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

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

5.11 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




 
RFC 1867             Form-based File Upload in HTML        November 1995


   set is ISO-8859-1, but non-ASCII characters in field names should be
   encoded.

6. Examples

   Suppose the server supplies the following HTML:

     <FORM ACTION="http://server.dom/cgi/handle"
           ENCTYPE="multipart/form-data"
           METHOD=POST>
     What is your name? <INPUT TYPE=TEXT NAME=submitter>
     What files are you sending? <INPUT TYPE=FILE NAME=pics>
     

   and the user types "Joe Blow" in the name field, and selects a text
   file "file1.txt" for the answer to 'What files are you sending?'

   The client might send back the following data:

        Content-type: multipart/form-data, boundary=AaB03x

        --AaB03x
        content-disposition: form-data; name="field1"

        Joe Blow
        --AaB03x
        content-disposition: form-data; name="pics"; filename="file1.txt"
        Content-Type: text/plain

         ... contents of file1.txt ...
        --AaB03x--

   If the user also indicated an image file "file2.gif" for the answer
   to 'What files are you sending?', the client might client might send
   back the following data:

        Content-type: multipart/form-data, boundary=AaB03x

        --AaB03x
        content-disposition: form-data; name="field1"

        Joe Blow
        --AaB03x
        content-disposition: form-data; name="pics"
        Content-type: multipart/mixed, boundary=BbC04y