[Bug 23646] "us-ascii" should not be an alias for "windows-1252"

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23646

--- Comment #41 from Jirka Kosek <jirka@kosek.cz> ---
(In reply to Henri Sivonen from comment #40)
> As for the TextEncoding API, it doesn't support non-UTF-* encodings anyway,
> so the issue of "us-ascii" is moot. 

Fortunately, it doesn't. But there is still generic definition of encoder which
allows any encoding. And there is nothing in the Encoding Standard which
prevents creation of another APIs which will allow more encodings and sooner
and later will cause interop problems with encoding libraries that strictly
follow IANA defintions of characters available in each encoding.

> I think we should focus the spec on the Web Platform--i.e. browsers. As
> other systems find the need to consume Web content, they'll eventually grow
> Encoding Standard-compliant encoding subsystems.
> 
> It's clear that there exist encoding libraries whose label handling is
> IANA-oriented. Those will probably stick around for a long time for
> compatibility with their old selves. It's unfortunate that the Web behavior
> and e.g. the IANA-oriented JDK behavior differ, but we should just admit the
> existence of two different legacies and not try to mix e.g. the JDK legacy
> into Web specs.

OK, so what about if the scope of the Encoding Standard will incorporate what
is in two paragraphs above and also it would state that encoding and decoding
algorithms are defined in a way that it's compatible with the existing usage on
the web and that any APIs build on the top of the Encoding Standard should
support only utf-* encodings, otherwise interop with other encoding libraries
is not guaranteed?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Tuesday, 1 July 2014 12:57:25 UTC