[6484] in www-talk@info.cern.ch
Re: MIME
daemon@ATHENA.MIT.EDU (Roy T. Fielding)
Wed Nov 2 00:53:57 1994
Date: Wed, 2 Nov 1994 06:39:26 +0100
Errors-To: listmaster@www0.cern.ch
Errors-To: listmaster@www0.cern.ch
Reply-To: fielding@avron.ICS.UCI.EDU
From: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>
To: Multiple recipients of list <www-talk@www0.cern.ch>
> Can someone give me a list of specific advantages to using MIME
> as message bodies in HTTP? I've often wondered why this
> choice was made...
1) It provides a means for typing (as in assigning a type to) message data.
2) It provides a means of associating data types with data handlers.
3) It's trivial to parse (so trivial, in fact, that people don't bother
to consult the RFCs first and end up making a mess of it).
4) It's completely extensible.
5) It's an Internet protocol, and people who matter like it when Internet
protocols are reused, rather than reinvented.
Of course, that doesn't mean we can't move on to a different method
in the future. However, data types are (probably) always going to be
named with MIME content-type identifiers, simply because we'd never
agree on the names otherwise.
On a different thread, people have noted that many current browsers do not
support mime parameters, e.g.
Content-type: text/html; level=3
This is true, but should not be used as an excuse to implement and
distribute MORE clients that can't parse MIME properly. It WILL be in
the HTTP/1.0 specification, and new client authors will be expected to abide
by that specification. Eventually, servers will be able to send parameters
in MIME types without worrying about clients barfing -- it is a requirement
for enabling extensions to data types, as well as for supporting complex
parameterized data types like text/sgml.
......Roy Fielding ICS Grad Student, University of California, Irvine USA
<fielding@ics.uci.edu>
<URL:http://www.ics.uci.edu/dir/grad/Software/fielding>
