> 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