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

Keith Moore (moore@cs.utk.edu)
Tue, 11 Apr 95 01:21:35 EDT

> > Security considerations?
>
> What about:
>
> Security Considerations
> None. multipart/form-data introduces no security considerations.

..beyond those of the objects it contains?

(reminds me of "security considerations are not discussed in this memo." :)

> > 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. 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}.
>
> What about:
>
> Content-form-field
>
> instead of
>
> Name

Maybe. I'm not sure it's reasonable for a content-type to define new
body part headers. What do other people think?

> >> 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.)
>
> The goal wasn't to create a variant use but to adopt whatever
> content-length was used for in email and HTTP. (They *are* the same,
> aren't they?)

I don't think we can say they're the same. There's no standard for
the content-length header in email, and usage of the content-type
header varies from one email system to another. In HTTP, I think of
the content-length "header" as being specific to the HTTP protocol.
After all, HTTP's "headers" are incompatible with 822/MIME in several
ways, even if they have similar names.

This is a wierd turn of the tables. This type is clearly designed for
HTTP, but my objections to this type are mostly due to the problems it
would cause if these things started showing up in MIME email. (which
they probably will...)

Keith