W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2008

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

From: Ian Hickson <ian@hixie.ch>
Date: Sun, 6 Jul 2008 01:53:51 +0000 (UTC)
To: Sam Ruby <rubys@us.ibm.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, "public-html@w3.org" <public-html@w3.org>
Message-ID: <Pine.LNX.4.62.0807060126260.11210@hixie.dreamhostps.com>

On Sat, 5 Jul 2008, Sam Ruby wrote:
> > > 
> > > There are only two workable solutions. [a and b]
> >
> > [b] fails to achieve the only goal here, interoperability. So there's 
> > only one workable solution.
> 
> Slight disagreement here: there are multiple potentially workable 
> solutions.

You said there were two, I pointed out why one of those two isn't a 
solution, and now there are multiple? I'm confused.


> > the key is to find a solution that can reach a steady state. The "I 
> > really mean it" parameter doesn't (since it will end up used on pages 
> > that aren't labelled correctly, and so other browsers won't support it 
> > as it would lead to them supporting fewer pages).
> 
> Any documented solution, including the one in the current draft, suffers 
> from the above. Pages will be lagelled incorrectly.  Yes, even with the 
> rules captured by the current draft of HTML5.

I think you are missing the key difference here.

With what the spec says, which is the status quo plus or minus the delta 
between implementations, we have already run through the people making the 
mistakes and have already gotten to a pretty stable steady state. Getting 
from here to a state where all the browsers do the same thing is a small 
change.

With a radical new parameter, we are much further from the status quo, and 
so it would take significantly more to get to a steady state. Furthermore, 
since the new parameter is in fact identical in semantic meaning to the 
origin Content-Type header, there's not really any reason to believe that 
that final steady state wouldn't look exactly like today's near-steady 
state (except more complicated, since it would have more inputs).


> If a page *can* be interpreted as text/plain (and in general, most html 
> pages and feeds can), then there is no reason that the consistent error 
> recovery couldn't provide *some* combination of parameters where the 
> sniffed type matches the official type.  In fact, I would go so far as 
> to say that making sure that this is always the case would be a worthy 
> goal.

I agree, and indeed currently HTML5 says to honour text/plain in all cases 
where the content is valid text/plain content. Personally I think it's a 
security risk to treat text/plain as anything but.


> Another factor to consider is that the http working group is concerned 
> with more user agents than browsers.

I should hope everyone is. However, that doesn't change anything -- it's 
still the same ecosystem, and the same content. We don't want tools 
treating content different than each other, whether they are Web browsers 
or not.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Sunday, 6 July 2008 01:54:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:53 GMT