Unknown text/* subtypes

Ian Hickson ian at hixie.ch
Sun Jan 13 06:47:27 CET 2008


On Fri, 28 Dec 2007, Frank Ellermann wrote:
> 
> Years later (after 2616bis) it might be possible to upgrade "default 
> ASCII" to UTF-8, Latin-1 was a dead end.  As soon as we're back to 
> "default ASCII" just let RFC 2277 finish it off.

FWIW, a number of specs are already overriding both MIME and HTTP when it 
comes to character encodings. For example HTML4 says to not default to any 
encoding at all [1], CSS defaults to a complicated heuristic [2], HTML5 as 
currently proposed defaults to an even more complicated heuristic [3], and 
so on.

In the "real world" the implementations are following the heuristics 
described in CSS2.1 and HTML5 (or something close to them), and those 
differ for text/css and text/html, so it would seem pointless for HTTP to 
try to define something here: it would just get ignored.

IMHO the best option is for HTTP to stay out of the discussion altogether 
and let the lower level specs (MIME) and the higher level specs (XML, 
HTML, CSS, etc, defining the formats) figure it out amongst themselves.


-- Footnotes --

[1] http://www.w3.org/TR/html4/charset.html#h-5.2.2
This text explicitly says that HTTP's default is useless. It then 
recomments behaviour that is even more useless, but that's another 
problem altogether...

[2] http://www.w3.org/TR/CSS21/syndata.html#charset

[3] http://www.whatwg.org/specs/web-apps/current-work/multipage/section-parsing.html#determining

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


More information about the Ietf-types mailing list