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