Re: Registration of new Media Type multipart/form-data

Larry Masinter (
Thu, 13 Apr 95 11:35:56 EDT

The main _requirement_ is a well-known, designated type that clearly
identifies, FROM THE MEDIA TYPE that this is data intended to be
interpreted as the result of filling out a form.

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

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

content-type: text/plain
content-id: zzzzz

(value of variable foo)

content-type: text/plain
content-id: yyyyy

(value of variable bar)

content-type: text/plain
content-id: xxxxx

(value of variable zot)