Re: Unknown content types

On Wednesday, July 9, 2003, 10:09:51 PM, Julian wrote:

JR> 2) If a sender (mail agent) / server (HTTP server) doesn't know
JR> the MIME type, DO NOT SEND IT. This allows the recipient to guess
JR> and/or consult the user.

JR> (my personal preference would be alternative 2 because it doesn't
JR> require to special-case one particular MIME type).

Further to my previous reply, and even-handedly arguing bothsides ;-)

>> In HTTP/1.1 a a response from the server can include a bag of bits
>> (the "entity body") and metadata about those bits (the "entity
>> headers", including Content-Type, Content-Language, and
>> Content-Encoding).
http://www.w3.org/2001/tag/doc/mime-respect.html

So this pretty much says that an entity body without a Content-Type is
already defined as a 'bag of bits'.

>> In Web architecture terms, a bag of bits plus
>> metadata is called a representation of a resource.

Ah. So if Content-Type, Content-Language, and Content-Encoding are all
empty, is it a resource representation still (I would say yes and
tighten the wording in the finding slightly.)

>> In practice, the MIME mechanism defined in RFC2046 is used to
>> associate a bag of bits with metadata.

That one can be argued either way, but seems to suggest that without
any MIME headers it is still a resource. In other words, absence of
Content-Type could still be defined as 'metadata' but I would feel
more comfortable to have explicit metadata.

In addition, many existing servers are set up to server
application/octet-stream for unknown types. I would be happy with
wording that says

a) this is a good idea
b) its way better than serving unknown stuff as text/plain


-- 
 Chris                            mailto:chris@w3.org