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

Ned Freed (NED@SIGURD.INNOSOFT.COM)
Wed, 12 Apr 95 14:53:50 EDT

> > multipart/form-data contains a series of parts, each of which has
> > a "Name:" header. As with all multipart MIME types, each part has
> > an optional Content-Type which defaults to text/plain.

> This is a little bit wierd. Offhand, I don't know of any thing in
> MIME that allows type-specific body part headers to be defined, or any
> body part that defines such headers.

While it is true that no existing content-type defines type-specific body part
headers, that isn't what is happening here. Specifically, I read this as
type-independent headers, that is, they are independent of the type of
attachment that they are associated with. There are a number of cases where
this is done already, e.g. content-language.

> It's not clear that existing
> MIME parsers would support this. Even if they were to support it,
> there's a strong argument to be made that it should be called
> Content-{something}.

It isn't an argument, its a requirement. RFC 1521 clearly states that all body
part headers must begin with content-.

I have no real problem with something like content-form-name, however, I
think this may belong under the content-disposition umbrella. If this isn't
a disposition for a body part, what is it? I think something like

content-disposition: form; name=foo

would be a nice way to do it that doesn't involve creation of another
header.

> > multipart/form-data headers may optionally include a Content-Length
> > header both in the overall reply and in individual components. The
> > content-length is *not* intended as a replacement for the multipart
> > boundary as a way of detecting the end of an individual component.
> > It is *only* supplied as a way forwarning the server of the amount
> > of data coming.

> This is a Bad Idea. There's already a nonstandard Content-Length
> header in use in email, and it's caused a tremendous amount of
> problems. This variant use of Content-Length would only add to the
> confusion. (I assume this would be the length of the canonical form,
> not the encoded form, of the body part.)

Agreed. This should be removed.

Ned