Re: Comments on the HTTP/1.0 draft.

>>It already mentions these issues and includes explicit reference to how
>>media types are registered.
>
>Well, the issue I take is with the statement that HTTP should be
>"allowed more freedom in the use of non-registered types."  I believe
>one way to interpret this is "use whatever non-registered types you
>want, as long as it's HTTP and not email that's no problem," and I'm
>not sure that is what was meant.

What's wrong with interpreting it that way? HTTP doesn't do ANYTHING with
the MIME types AT ALL! You know this, I know this, and all the HTTP
implementors on the planet know this. The MIME types are strictly a
pass-through from the server's logical file system to the client, for the
benefit of the client and associated viewers. Whether the type is
registered or not has absolutely no bearing on HTTP, the interpretation,
semantics, and operation of the HTTP protocol, or its implementation.
Whether MIME types are registered or not has nothing to do with the HTTP
standard.

It'd be like demanding that all of the words that appear in text
object-bodies be spelled correctly, or that the comments after a status
code in the response all be lower case. This is data that has no bearing on
the function of the protocol. It is data that is conveyed from point A to
point B in a standard slot in the HTTP protocol, just like the data in the
Content-length field, the  Server field, etc. The syntax matters, but the
semantics don't. The client uses the MIME type to figure out how to display
the data, and the user on the other end of the pipe has made the join
between the MIME type and the data, not the server or the HTTP protocol.
Specific MIME type info has no place in the HTTP standard. The syntax of a
Content-type field needs to be there, but that's all.

-----------------------------------------------------------------------
Chuck Shotton
cshotton@oac.hsc.uth.tmc.edu                           "I am NOT here."

Received on Friday, 9 December 1994 19:41:28 UTC