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.
Is there a bug on removing the decoder? What happens if someone needs the encoder? Does Gecko use utf-8 instead or some such?
(In reply to comment #1)
> Is there a bug on removing the decoder?
> What happens if someone needs the
> encoder? Does Gecko use utf-8 instead or some such?
Yes, uses UTF-8.
Removing stateful encodings will affect some types of attack such as:
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.
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.
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.
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.
(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?