Its important that we understand what processing multipart/related
provides. I read it as saying that the parts are to be decoded and stored
in local files and a list of file/header/id correspondences is to be built.
This is then passed to whatever agent is actually responsible for processing
the part.
I don't know whether or not HTML forms fit this processing model. They may or
they may not. The SGML use I've seen for multipart/related seems to fit. I do
know, however, that several other multipart subtypes do not fit, including
multipart/appledouble, multipart/signed, and multipart/encrypted. (The first
one requires treatment of the entire object as a single entity, either by
incorporating or discarding the data fork, while the second and third require
that tradition MIME processing be suspended until the security service runs, at
which time MIME processing must resume.)
> 2) Ned suggested:
> > 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.
> I think this would also be acceptable.
> Mainly I want to avoid creating a new mechanism that user agents have
> to support, when an existing one will do.
I don't really have a problem with creating a new header, since its
clear from the SGML work that the headers have to be available as part
of multipart/related processing. However, that doesn't justify the creation
of a new header in any of itself, especially since content-disposition seems
like a fairly good fit already (and its already supported by some agents).
Ned