> Your draft mentions explicitly that an object with
> Content-Disposition: form-data can have the following
> Content-Types:
>
>    application/octet-stream
>    multipart/mixed
>    text/plain and other subtypes to text/
>    message/external-body
>
> It is not quite clear whether any other content-types can be included.


Wow, you really like to have things spelled out. It says
"as with all multipart types". Does it need to say that there
are no restrictions?

> Question 1: Can multipart/form-data be recursively embedded
> inside multipart/form-data?

This is not disallowed, but I imagine it might be rare. If I had
received a form result earlier, saved it to disk, and then later
sent it in as a file as part of another form query, this could happen.

> Question 2: Can application/x-url-encoded be embedded
> inside application/form-data?

Same answer. Rare.

> Question 3: Can objects of Content-Type: Message/rfc822 or
> Content-Type: Message/http be embedded inside application/form-data?

Same answer, but rare. If I dragged a message attachment from
a mail message into a 'file upload' box in a form, this might
happen.

> If yes, perhaps one should add
>
>    If a complete e-mail message is to be returned, the
>    "Content-Type: Message/rfc822" can be embedded within
>    multipart/form-data.


This makes no sense to me. What do you mean "a complete e-mail message"?
Forms rarely ask for 'a complete email message', anyway.

> or
>
>    If a complete message is to be returned, the
>    "Content-Type: Message" can be embedded within
>    multipart/form-data.

"message" isn't a valid media type, so I wouldn't recommend that.


> Your draft says:
>
>    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".  If multiple files are to be returned as
>    the result of a single form entry, they should be represented as a
>    "multipart/mixed" part embedded within the "multipart/form-data".
>
> Maybe one should here add:
>
>    If a HTML document including inline objects like images or
>    applets is to be returned as the result of a single form
>    entry, they should be represented as a "multipart/related"
>    part embedded within the "multipart/form-data". Also other
>    submodes to multipart may be embedded within the "multipart/
>    form-data".

Well, I'm wary of suggesting this; I'd rather avoid too much advice about
how to use "multipart/form-data" except to say what it means if you DO
use it under various circumstances.

> If this is added, references should maybe be added to RFC 2110 or
> to RFC 2110, 2111 and 2112.

I think I would rather avoid making references to all of the things
that _could_ be sent. It just defines a method of sending things.

Larry