Re: Proposed TAG Finding: Internet Media Type registration, consistency of use

At 05:33 AM 2002-05-30, Steven Pemberton wrote:

>From: "Tim Bray" <>
>> Anyhow, for the moment I stand by the position that sniffing is always
>> without exception bad when you're figuring out how to do top-level
>> dispatch.  It opens horrible security holes and when breakage does
>> occur, it focuses the blame away from where it belongs, namely people
>> who screw up in configuring their webservers.
>I think this is the major problem: it protects the guilty, and penalises the
>I have long wanted to be able to write web-based tutorials along these
>    Here is an HTML document to illustrate this technique:
>    and here is its source:
>but I can't, because in IE you get exactly the same results for the two
>links (try it on the above). How can I get IE to do the right thing? I
>can't! It *always* presents my file served as text/plain as if I had served
>it as text/html. It prevents people from doing the right thing...

How committed are the consumers of your web-based tutorials?  Are they casual Web walk-ons, or have they enrolled in something?

Two out of the three browsers I happen to have installed do this the way you want.  The other two are readily available for free.  In some educational situations[1], asking the users to install some client or client extensions is de_rigeur.  You don't have to specify the browser, just the standards compliance profile that they meet, and you can inform your customers of know non-compliant configurations.  That is why I ask how persistent is your relationship with the learners.

If the dominant player does something wrong, this is an problem of enterprise proportions for the Web.  But still, it is not clear that the TAG list is the place to pursue a specific beef against a specific implementation.  If that is all we are dealing with, we don't need to wrap it in the trappings of TAG findings and architectural principles.

In this case, control by user supervision alone is inadequate.  Users accept the unquestioned 'upgrade' to HTML processing in such proportions that this behavior is what the market will bear.  The system is showing not enough stiffness against violating _what the author said and expects to happen_.

We need both a stiffer control loop around what the servers serve as type information, and a more faithful response from user agents.  These are interdependent.  So we need a roadmap for a closed-loop transition practice that will migrate the operating point to where we would rather be.  This does sound like a 'delegate to QA' perhaps.

I do hope we can resolve this without having to introduce a !important on HTTP headers...

Content-Type: text/plain ;sic


[1] a category of situations distinguished by [recognizable by] business rules.

>And if IE thinks your tar archive is an HTML file, well bad luck for you and
>your users.
>It would be *really really good* if IE offered an option to switch off
>content switching, and even a dialogue, so that people could get an idea
>that something was wrong:
>    This document has been served as text/plain but looks like an HTML file.
>    What do you want to do:
>        [ ] View it as HTML
>        [ ] View it as text
>    [ ] Never ask me this question again.
>Steven Pemberton

Received on Thursday, 30 May 2002 09:23:34 UTC