That wouldn't rule out some variation of Kieth Moore's counter-proposal.
For example, here's an alternative proposal, which I will call
"multipart/x-form-data-take2":
multipart/x-form-data-take2 look like multipart/related, in that one of
the parts contains a simple text of name & content-id or (when the
form-data is simple) text.
I'll do this by example; let's suppose you have a form with four
fill-in fields, "foo", "bar", "baz", "zot".
I don't like this very much, bucase it is much more complicated to
generate and to parse than the original proposal; I'm leaning more
toward just fixing the original proposal to be more compliant with
MIME (e.g., use a special 'content-description' to identify the field
names that each body part is to be associated with.)
================================================================
example of multipart/x-form-data/take2
================================================================
content-type: multipart/x-form-data-take2; start=xyzzy; boundary=foo
--foo
content-type: application/form-data-fields
content-id: xyzzy
content-description: this lists (name, content-id) pairs
name=foo; content-id=zzzzz
name=bar; content-id=yyyyy
name=baz; value="value of variable baz"
name=zot; content-id=xxxxx
--foo
content-type: text/plain
content-id: zzzzz
(value of variable foo)
--foo
content-type: text/plain
content-id: yyyyy
(value of variable bar)
--foo
content-type: text/plain
content-id: xxxxx
(value of variable zot)
--foo--