This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The updated euc_kr table now has the following entries: ---8<--- 5916 0xFFFD � (REPLACEMENT CHARACTER) 5917 0xFFFD � (REPLACEMENT CHARACTER) 5918 0xFFFD � (REPLACEMENT CHARACTER) 5919 0xFFFD � (REPLACEMENT CHARACTER) 5920 0xFFFD � (REPLACEMENT CHARACTER) 5921 0xFFFD � (REPLACEMENT CHARACTER) [snip] 5948 0xFFFD � (REPLACEMENT CHARACTER) 5949 0xFFFD � (REPLACEMENT CHARACTER) 5950 0xFFFD � (REPLACEMENT CHARACTER) 5951 0xFFFD � (REPLACEMENT CHARACTER) 5952 0xFFFD � (REPLACEMENT CHARACTER) 5953 0xFFFD � (REPLACEMENT CHARACTER) ---8<--- They correspond to byte sequences A0 5B..60 and A0 7B..80, which are gaps between UHC ranges. I don't think Bug 16691 intended this (as they are the only occurrences of U+FFFD throughout the indices at the moment). This causes an otherwise valid decoder to accept those sequences even when the fatal mode is in the use.
Should I remove the space from your Korean name? Other contributors with a Korean name do not have a space there. See https://encoding.spec.whatwg.org/#acknowledgments for context. Anyway, that's an aside, thanks a lot for spotting for this! This was a stupid mistake when regenerating the index. https://github.com/whatwg/encoding/commit/7991e7b9add2a6d1ccd34e637d2c4e15ae7bbf7c
That is intended (i.e. I personally prefer that), but if you want to be consistent I don't mind normalizing that.
Thanks, I added a note so I don't forget about your preference. It'll stay as is.