At 2:52 AM 11/20/95, Roy T. Fielding wrote:
involved in writing the document. There is no technical reason why an
agent should ignore header fields in body parts that do not begin with
"Content-". No existing MIME applications discard these fields -- in fact,
Can you speak with certainty about gateways? Gateways are famous
for throwing away headers.
Yes, because we are not talking about the message headers here -- only the
body-part headers. Gateways cannot alter those headers.
Roy, there are two approaches to designing system enhancements: No
reason this shouldn't work, versus, they're out to get us so what can we do
to make SURE it will work?
In the Internet interoperability game -- and especially the email
game -- the latter has proved to be the necessary mode of design. I said
necessary.
You are preaching to the choir there -- just look at the HTTP spec.
Utlimately, all this leads to the question of your reason for
wanting to deviate from solidly-established convention? What possible
benefit is there?
That is the important question, yes. In my case, it allows each body part
to define the Entity-Headers (defined by HTTP as those header fields
containing information about the entity) for the entity within that body
part. It is, in fact, the only thing that makes multipart/* useful
within the context of HTTP. I cannot and will not change all of the HTTP
Entity-Header fields to add a Content- prefix, nor does it make sense
to disallow multipart except when each part is of type message/http.
The only thing that the above section accomplishes is waste bytes.
Roy! We're talking about RFC822 and MIME, here. The byte-counting
war got lost 20 years ago.
Well, I didn't mean that as a design issue -- the section in question
just doesn't accomplish anything useful for MIME.
Cheers,
...Roy T. Fielding
Department of Information & Computer Science
(fielding(_at_)ics(_dot_)uci(_dot_)edu)
University of California, Irvine, CA 92717-3425 fax:+1(714)824-4056
http://www.ics.uci.edu/~fielding/