See bug 16773. Without conclusive data it would be dangerous to just add labels. E.g. from experience we know that euc_jp cannot be treated as euc-jp (which is why we do not follow UTS22). I'm inclined to mark this WONTFIX.

Also, that GitHub repository seems to confuse encodings with labels of encodings.

The list in the github appears to be a list of encoding labels found by crawling e.g. the W3C list archives. The existence of bad encoding labels in that list does not imply that user agents (or anyone else) interpret them properly or that they *should* interpret them. So I concur that this should be WONTFIX. The best way to get broken implementations fixed is for users to call up and complain that it doesn't work.

Addison writes:  "The best way to get broken implementations fixed is for users to call up and complain that it doesn't work."

By "implementations" do you mean "web pages"?  Because, if so, that approach doesn't work.  If you mean "browsers", I doubt that browsers will add one-off support for random labels like these.

For web pages the best fix is to change the page to use the proper label. Making the broken label "work" is a bad idea.

In this case, my mind (first cup of coffee) fixated on the email aspect of the scraped data. If your mailer generates a bad encoding label, then you probably should call up and complain.

I agree about mailers.

Reporting broken web pages is itself a broken process: it horribly fails to scale, and frequently there is no one to complain to.  That's why we have to tolerate broken markup and have even needed to make a broken-markup standard.  Broken encoding labels are just another part of that.

It's all very well to say "Move everything to UTF-8", but if it were that easy, XHTML would have been a smashing success.

Changing encodings is much easier than completely revamping development practices, but this bug is about adding labels and per comment 1 that does not seem like a good idea without conclusive data.