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

Julian Reschke wrote on 07/05/2008 03:39:59 AM:
>
> Ian Hickson wrote:
> > On Thu, 3 Jul 2008, Dave Singer wrote:
> >> Next up:  a server that always adds the "I mean it" attribute, even
when
> >> it doesn't, and the subsequent invention of the "No, really, come on,
> >> you have to believe me, scout's honor, I really truly mean it"
> >> extension.
> >
> > This is exactly why this won't work. Sites will use this correctly,
then
> > someone will set some default somewhere incorrectly, or copy and paste
a
> > correct site somehow, or misunderstand a tutorial or something, and
deploy
> > it without testing in IE8. And it will work fine in all the browsers
>  > ...
>
> Well, only if the other UAs do not adopt the proposal.
>
> I'm not saying they should (yet), but why wouldn't it work if all UAs
> did the same thing here?
>
> > except IE8, an then IE8 will be patched to make this attribute trigger
a
> > slightly different (and smaller) set of content-sniffing instead...
except
> > that the set won't be quite what was intended, because there will be
some
> > bug, and then there will be sites that DO test with this patched IE8,
but
> > end up relying on this slightly different content sniffing...
> >
> > ...and ten years from now we'll have four different content sniffing
modes
> > with four different ways of triggering it and the next generation will
> > look back at 2008 and wonder what we were thinking.
> >
> >
> > 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?
>
> Sounds inconsistent to me.

Permit me to rephrase that in the form of a question, based on a live
example.  I just changed the content type of feed validator test cases from
"text/xml" to "text/plain; charset=utf-8".  I did this with the following:

http://feedvalidator.googlecode.com/svn/trunk/feedvalidator/testcases/.htaccess

I verified the content type returned using:

curl --head
http://www.feedvalidator.org/testcases/atom/1.1/brief-noerror.xml

I then fetched the file using IE 7.0.5730.13, Firefox 3.0, Safari 3.1.2,
and Opera 9.50.  IE and Firefox rendered the content as a feed, Safari as
html, and Opera as text/plain.

As I read the spec, content sniffing as defined by sections 2.7.2 (and
perhaps 2.7.3, despite the fact that my charset was sent as lower-case
utf-8 despite my specifying this parameter using upper case) specifies that
content served as "text/plain" effectively is an opt-out from further
content sniffing.

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.

> BR, Julian

- Sam Ruby