Why Microsoft's authoritative=true won't work and is a bad idea

Ian Hickson wrote:
The only way you get get it to _not_ work in all the other browsers would
be for all the browsers to be updated to support this simultaneously, with
a simultaneous launch, and have the entire installed base upgraded at the
same time. In practice, more than 25% of the install base still uses _IE6_
today. The amount of time between when a feature can first be used and
when a feature cannot be copy-and-pasted by an ignorant author who isn't
using the latest browsers is several _years_. That's plenty of time to
poison the well and ruin the chances of the new feature getting deployed
across all browsers.

It seems to me that you're totally missing the point here.

Before HTML5, the specifications told UAs to respect the mime type (see
HTTP, MIME, WebArch). UAs are known not do this, and to vary in how
they implement sniffing.

That means that today, a content author has no way to ensure that
recipients will not do content sniffing.

In many cases, it doesn't matter. In some, it does.

Giving content authors more control about what recipients seems to be a
good thing to me, even if it only works in one of the major UAs first.
In particular, if that one is known to do the most content-sniffing today.

Yes, I'd prefer all of this not to be necessary. The less sniffing is
done, is better. Therefore I'd encourage everybody to try to get the
number of cases as small as possible.

And no, I'm not convinced that a content-type parameter is the best
approach, in particular as I don't see how it can be registered
properly. A new response header may be better.

And yes, I'd prefer if Microsoft would submit proposals like this to a
public forum, instead of just telling us "this is what we're going to
do" (the canvas way :-).

The way out of this mess is containment. We define a strict set of
Content-Type sniffing rules that are required to render the Web, and
we get the browsers to converge on only sniffing for those.
>So you can get the browser vendors to converge on a precise set of
>sniffing rules, but you can't get them to agree on an opt-out?

The precise set is the set that is compatible with rendering the legacy
content as expected, the minimal subset compatible with what browsers do.
It can also be changed in response to browser feedback when it is
discovered that it isn't quite perfect. It is far easier to incrementally
move towards a set that is trying to be compatible with what the browsers
already do than it is to get the browsers to jump to an extreme.

I wouldn't consider trusting the server supplied content type an "extreme."


>This leads to the question: what is the essential difference between
>"text/plain" as defined by the spec and therefore is presumed to be
>workable (despite all the evidence to the contrary), and
>"authoritative=true" which is being rejected out of hand as unworkable.

text/plain might not be workable. If and Safari find they have to
change as well, then the spec will have to change too.

I don't think this answers Sam's question. What's the difference
between considering the encoding as input, but not another parameter?

BR, Julian