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

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

From: Sam Ruby <rubys@us.ibm.com>
Date: Mon, 20 Aug 2007 16:57:54 -0400
Message-ID: <46CA0052.80909@us.ibm.com>
To: Ian Hickson <ian@hixie.ch>
CC: "public-html@w3.org WG" <public-html@w3.org>

Note:snippets from three separate emails on the same thread.

Ian Hickson wrote:
> On Mon, 20 Aug 2007, Sam Ruby wrote:
>>> So while it may be valuable to have a way to say "this is really the 
>>> content type, please don't sniff", your example does not make a very 
>>> strong case for it, since browsers are in their rights to do custom 
>>> rendering of any XML content type based on the namespaces used in the 
>>> contents.
>> If I changed my content type to text/plain, would that change your 
>> answer?  I would gladly change my Content-type to text/plain if only I 
>> could get browsers to respect that.  Gladly.  But they don't.
> 
> For what it's worth, I strongly agree with you that (for security reasons 
> if nothing else!) you should never have text/plain documents that only use 
> non-<control> characters sniffed and treated like HTML, RSS, or Atom. 
> Those documents should be treated as text/plain.
> 
> At the moment, the spec backs that up.

Unfortunately, while you and I are on the same side, I can "pull an Ian" 
here, and provide plenty of counter examples. [1]  :-(

> The problem is that integrates very tightly with the way that browsing 
> contexts work, and integrates tightly with how session history work, both 
> of which are tightly integrated with how the Window object works, which 
> itself is tightly integrated with event dispatch and parsing. It's also 
> directly related to the section on hyperlinks, which is directly related 
> to <a>, <link> and <area>.

Amusingly these types of things is precisely why I named my site the way 
I did.  :-)

> So I would add a fifth condition: (5) the parameter is chosen such that 
> browser vendors cannot ever get a competitive advantage by not supporting 
> it or by supporting it incompletely.

Unfortunately, based on the quick list I gathered below, there is a 
competitive advantage to be gained by ignoring the spec as it currently 
stands.

Furthermore, the abstract way in which you have framed the problem means 
that it applies to pretty much every feature and addition that is 
present in HTML5 that isn't supported in IE6.

Finally, that competitive advantage thing can work both ways.  In a 
field not too distant from the one that we are discussing, I've seen 
cases where enough vendors have grown to support Atom specific features 
simply because if the did not, they would be at a competitive disadvantage.

All theory aside, My read is that if we simply picked something like 
";important" to append to the content type and if IE8 supported it, and 
if a few of us actually deployed content that behaved better if it were 
honored, and publicized the fact that we did so, there would not be an 
issue.

- Sam Ruby

[1] here's a few feeds that are served as text/plain, but would sniff as 
feeds.  A few might be generated by the same software, but from a quick 
pass, it appears that the bulk are generated by separate and unique 
codebases:

http://hellern.homelinux.org/feed.rss
http://jewczuk.net/blog/blog.rss
http://paranoid.net.ua/news.rss
http://pelloud.ovh.org/pelloud.rss
http://primo.anti-emo.org/podcasttest.rss
http://raystedman.org/messages.rss
http://softwaresummit.com/coloradosoftwaresummit.atom
http://upwebdesign.com/fashionsite2.rss
http://users.rcn.com/mmathews.dnai/feed.rss
http://www.amazingwondersoftheworld.com/wowRSS2.rss
http://www.armencomp.com/tradelog/trader_tax_topics.rss
http://www.asstr.org/~sub01/updates.rss
http://www.bitec.de/bitec.rss
http://www.centerforrationaldebate.com/rss/rational.rss
http://www.digitalarte.co.uk/news-and-updates.rss
http://www.edalty.com/DaltonSystems/rss/index.rss
http://www.efectovirtual.com/efectovirtual.rss
http://www.goascendant.com/testrss.rss
http://www.kikogolf.com/features.rss
http://www.martinjspeed.com/rssfeed.rss
http://www.musicfrombrazil.com.br/mfb-pt.rss
http://www.resiper.net/paginas/misitio.rss
http://www.roda-schule.de/news.rss
http://www.seojorge.com.br/rss/comicFeeds.rss
http://www.soullip.com/soullip.rss
http://www.stephen-kiernan.com/Site/feed/articlefeed.rss
http://www.toyzetc.com/podketeer/xml/rss.xml
http://www.trywatersedge.com/testrssfeed.rss
http://www.tyffanie.com/rss/tyffanie.rss
http://caamanquehue.cl/phpnews/caa.rss
http://www.madcowdisease.org/madcow.rss
http://nitrogen.guj.de/test/HD2.rss
http://astoryaweek.com/story_a_week_podcast_jp.rss
http://beigebrigade.co.nz/loop/byc/bycfeed.rss
http://hjem.tele2adsl.dk/aanaes/feed.rss
http://topfotologs.com/rss/fotologs_superiores_hoy.rss
http://www.alexhenley.com/alex.rss
http://www.cmediscovery.com/podcasts/cmepodcasts.rss
http://www.comp.nus.edu.sg/%7Edaifei/PluginDT/rss/feed.rss
http://www.ebooksatoz.com/newsletters/newsfeed.rss
http://www.ezstreetasphalt.com/news/pothole-repair-news.rss
http://www.ihsa.org/ihsa-scorezone.rss
http://www.infotile.com.au/RSS/infotile.rss
http://www.revistadircom.com.ar/adm/reporte.rss
http://www.sutrodigital.com/test1.xml
http://cs.uns.edu.ar/~ldm/rss/novedades.rss
Received on Monday, 20 August 2007 20:58:10 UTC

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