- From: <bugzilla@jessica.w3.org>
- Date: Tue, 01 Jul 2014 12:57:23 +0000
- To: www-international@w3.org
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