This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
There is a note saying that current EUC-JP encoders do not encode JIS X 0212. Is that the case for ISO-2022-JP encoders as well? If so, a note to that effect should probably be added to the specification. Otherwise, the algorithm needs to be modified.
ISO-2022-JP doesn't contain JIS X 0212 from the start. (But ISO-2022-JP-1 and ISO-2022-JP-2 do.)
Indeed, I was using the term ‘ISO-2022-JP’ improperly to refer to a series of related encodings including JIS (the predecessor of ISO-2022-JP), ISO-2022-JP, ISO-2022-JP-1, ISO-2022-JP-2, ISO-2022-JP-3 and ISO-2022-JP-2004, as well as hybrids and variants. The issue I was trying to raise is that the encoder does not mirror the decoder, and that this asymmetry is not mentioned.
As you were probably alluding to, the various versions are not necessarily handled identically. Safari and Opera both distinguish between at least two variants: If the MIME charset is ISO-2022-JP-2, JIS X 0212 is decoded and encoded. For ISO-2022-JP, on the other hand, JIS X 0212 characters are encoded as deciamal character references, and Safari does not decode JIS X 0212 data either.
I don't see the point of differentiating ISO-2022-JP variants. We already treat some ISO encodings as just aliases of Windows encodings. Regarding the asymmetry, I agree to add some explanations.
It looks like I misinterpreted your comment twice. Sorry about that. I think we are in agreement. Given that IE has never supported JIS X 0212 (not sure about recent versions), it probably makes sense to use it only for the decoder. Only a note acknowledging the asymmetry is missing.
https://github.com/whatwg/encoding/commit/04d78180f9dc07f471ae432cebe34915c03412de