- From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
- Date: Sun, 04 Dec 1994 12:45:08 -0500
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Thus wrote: "Roy T. Fielding" >Larry Masinter wrote (on Monday): >>> 4.2 Content Types >> >> In what way is the HTTP content-type a superset of the MIME BNF? >> If you must repeat some BNF that occurs in another RFC, you must >> identify how this is either just a repeat, or a modification, and if >> it is a modification, how it is different from the source. > >It is a superset because it does not restrict itself to the official >MIME types and x-token types, as does the MIME spec. Thus, the parsing >is the same but without restricting the token values. This is equivalent >to the RFC 1590 decision to not constrain media types. I'm sorry, I don't see this difference is meaningful. MIME defines some types, a system for registering them, and says that unregistered types should have x- labeling. 1590 improves the registration process and changes the terminology to reduce email-centrisms, but changing the grammar hardly seems necessary. Are you saying HTTP should not call for unregistered media types to employ the x-token convention? Mind you, there are aspects of media type procedures I'd like to see changed to increase HTTP-friendliness. I'd like to see an easier way to revisit media type definitions, and I'd really like to see more liberal guidelines for optional parameters (since in HTTP, unlike Email, you sometimes have the C-T without the object itself.) But that's for another day. >I'd rather include the generic syntax, just in case the MIME people >change their minds. I am tempted to just remove MIME-Version altogether >(except for gateways), but that will have to be a group decision. Given that we're picking and choosing which portions of MIME to include and which to ignore, tying to 1.0 seems as sensible as anything else. - Marc -- Marc VanHeyningen <URL:http://www.cs.indiana.edu/hyplan/mvanheyn.html>
Received on Sunday, 4 December 1994 09:46:07 UTC