This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 20599 - Remove ISO-2022-KR encoder (or the entire encoding) from the spec
Summary: Remove ISO-2022-KR encoder (or the entire encoding) from the spec
Status: RESOLVED FIXED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: Encoding (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: Unsorted
Assignee: Anne
QA Contact: sideshowbarker+encodingspec
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 16687 16691 19942
  Show dependency treegraph
 
Reported: 2013-01-08 13:32 UTC by Masatoshi Kimura
Modified: 2013-08-24 20:07 UTC (History)
5 users (show)

See Also:


Attachments

Description Masatoshi Kimura 2013-01-08 13:32:04 UTC
Currently Gecko doesn't support the encoder. I would not like to implement it only to comply with the spec. Is there any reason it is needed in the spec?
I'd rather remove the decoder if every encoding requires both encoder and decoder.
Removing ISO-2022-KR is also proposed on www-international.
http://lists.w3.org/Archives/Public/www-international/2012OctDec/0039.html
Comment 1 Anne 2013-01-08 13:44:27 UTC
Is there a bug on removing the decoder? What happens if someone needs the encoder? Does Gecko use utf-8 instead or some such?
Comment 2 Masatoshi Kimura 2013-01-08 13:59:11 UTC
(In reply to comment #1)
> Is there a bug on removing the decoder?

Filed <https://bugzilla.mozilla.org/show_bug.cgi?id=827796>.

> What happens if someone needs the
> encoder? Does Gecko use utf-8 instead or some such?

Yes, uses UTF-8.
Comment 3 Masatoshi Kimura 2013-02-18 18:13:09 UTC
Removing stateful encodings will affect some types of attack such as:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20886#c3
Comment 4 Zack Weinberg 2013-02-18 18:16:30 UTC
It would be unfortunate if we had to continue supporting legacy stateful encodings just to avoid a hypothetical attack based on something *not* getting interpreted in a legacy encoding.
Comment 5 Anne 2013-02-19 11:00:52 UTC
http://zaynar.co.uk/docs/charset-encoding-xss.html lists another problem with not supporting ISO-2022-KR but also notes that IE already has this problem. And this problem might already exist for ISO-2022-CN too.
Comment 6 Jungshik Shin 2013-08-22 22:13:04 UTC
I also proposed the same by email. ISO-2022-KR should be removed from the spec entirely. It's not for Web. No sane person would use it on the web. Moreover, it's a potential security risk like any other non-ASCII 7bit encoding. 

We have to live with ISO-2022-JP, but no other non-ASCII 7bit encoding should be specified for the web.
Comment 7 Anne 2013-08-23 10:35:17 UTC
Jungshik, was that quite a while ago? I don't have any recent email from you suggesting that, but I recall you might have said that on a mailing list at some point.

In any event, two implementers willing to take the plunge works for me.

https://github.com/whatwg/encoding/commit/01f872bf168e138533d5aa67405d358f8c2fdc94
Comment 8 pub-w3 2013-08-24 20:07:28 UTC
(In reply to comment #6)
> We have to live with ISO-2022-JP, but no other non-ASCII 7bit encoding
> should be specified for the web.

The encoding standard currently includes the 7-bit Chinese HZ encoding — should that one be removed as well?