*1* I am NOT talking about what assumptions a httpd (HTTP server)
should make in deciding what is the content-type of a file.
This is clearly a configuration option of the server, and the
administrator of the server should be able to set this to whatever
is appropriate.
*2* I am NOT talking about what assumptions a web client should make
for files that it retrieves via FTP, local-file, or other kinds of
URLs.
This is definitely a configuration issue, and the resolution
is sticky, but a separate issue.
*3* I am ONLY talking about what happens in the case of a HTTP client
that does a HTTP GET, and gets back a response that DOES NOT
INCLUDE a Content-type header.
Possible resolutions are:
a) this is illegal. HTTP server should always include
Content-type.
b) Clients should guess, based on the suffix of the URL, as if
this were a ftp or file URL.
c) Clients should have a configuration default, and rely on that.
d) The default should be text/plain.
e) The default should be text/html.
(a) is not incompatible with any of the other resolutions. Personally,
I prefer (e). I'm not sure if Guido's note arguing for (d) was based
on the assumption I was talking about situation *1*. I think Simon's
note about MDMA is really talking about *1* or *2*, since in case *3*,
what the type-mapping tables is mainly irrelevant (unless you also are
suggesting resolution (b)). Erik Sink's note seems to be that (c) is
what is actually current practice, or already decided?
Brian's note saying "the browser should allow the user to set the
default type for rendering" is option (c), but that seems inferior to
all of the other choices. In any case, (c) doesn't really give any
guidance as to what the meaning of the protocol is, it just gives
guidence to browser writers as to how they should cope with the
current situation.