W3C home > Mailing lists > Public > public-html@w3.org > August 2007

Re: review of content type rules by IETF/HTTP community

From: Ian Hickson <ian@hixie.ch>
Date: Mon, 20 Aug 2007 19:36:57 +0000 (UTC)
To: Sam Ruby <rubys@us.ibm.com>
Cc: Julian Reschke <julian.reschke@gmx.de>, Dan Connolly <connolly@w3.org>, "public-html@w3.org WG" <public-html@w3.org>
Message-ID: <Pine.LNX.4.64.0708201931430.8981@dhalsim.dreamhost.com>

On Mon, 20 Aug 2007, Sam Ruby wrote:
> 
> At the moment, the spec with respect to sniffing of feeds reflects a 
> relatively recent and relatively incomplete approach implemented by 
> MSIE7. One that doesn't handle utf-16.

Yes, UTF-16 is intentionally not included, because we're trying to keep 
the sniffing to an absolute minimum and UTF-16 doesn't seem to be required 
to be compatible with the majority of content. Thus, if you're using 
UTF-16, you are forced by this algorithm to Do The Right Thing, and we can 
keep the sniffing under control.

> One that doesn't handle the content type recommended for RSS 1.0.

Could you elaborate on this?


> One that doesn't handle Atom 1.0 when using namespace prefixes.  I can 
> go on and on.

Again, this practice is rare enough that we don't have to sniff for it. We 
want to keep the sniffing to an absolute minimum; sniffing is only done to 
keep compatibility with legacy content and legacy browsers. Sniffing is 
not an attempt to solve authoring problems.


> The last time I checked, Firefox's implementation differed from IE's in 
> that it respected the mime type recommended for RSS 1.0 feeds. When I 
> reported that to Mozilla, the response I got wasn't "oh, dear, we're 
> incompatible", it was "great! We're better!"

Yes, supporting more MIME types seems within the letter and spirit of the 
current HTML5 draft, and should be encouraged.


> This leads one to conclude that, failing an explicit indication to the 
> contrary, HTML5 specification can describe how content-types SHOULD be 
> interpreted, but not how type MUST be interpreted.

The idea is that the rules MUST be followed, but the rules are open-ended 
in some specific ways that allow, for instance, for the support of more 
MIME types and for the support of more sniffing in the one case where it 
is useful, namely when the Content-Type header is omitted.


> Content-Type needs a css like !important qualifier.  If it can be 
> designed in a way that is ignored by IE6, and implemented by IE8(*), 
> then everything else will follow.  And I personally have no problem with 
> the default being that the content type is a hint.

The problem is that eventually there will be a browser that finds that it 
can get "better" results by inoring the qualifier, and then we're back to 
square one.


> (*) This begs the question: will those who are in a position to 
> influence IE8 actually participate in this discussion?  Or is this 
> merely an Ecma-376 like activity, without the benefit of Microsoft's 
> participation?

One of the Microsoft representatives is also the chair of this group... 
hopefully they are going to comment on the spec.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 20 August 2007 19:37:20 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:48 UTC