comments from Alexey - Githubissues

Hi Larry, Some comments after reviewing your draft:

In Section 2:

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
the appropriate media type, if known, or "application/octet-stream".
The inclusion of multiple files returned for a single file input
result in multiple parts, one for each file, with the same name.

I would insert references to where various mentioned media types are defined.

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
the appropriate media type, if known, or "application/octet-stream".
The inclusion of multiple files returned for a single file input
result in multiple parts, one for each file, with the same name.

It took me multiple passes to understand the last sentence. I am not sure I got it. Can you insert an example or qualify various use of "file"?

3.5. Charset of text in form data

For example, a form with a text field in which a user typed 'Joe owes
<eu>100' where <eu> is the Euro symbol might have form data returned
as:

   --AaB03x
   content-disposition: form-data; name="field1"
   content-type: text/plain;charset=windows-1250
   content-transfer-encoding: quoted-printable
   Joe owes =80100.
   --AaB03x

Are you missing an empty line after "content-transfer-encoding:"? This doesn't look like a proper MIME fragment.

Media type registration for multipart/form-data

Media Type name:
 multipart
Media subtype name:
 form-data
   Required parameters:
  none
Optional parameters:
  none

This doesn't look correct. What about "boundary"?

Example multipart/form-data would be useful. I had to search the web to find some

masinter / multipart-form-data

comments from Alexey #9