Response to comments received during the public review ======================================================= 11-MAR-2003 |1) gb2312 != gb2312-80. gb2312-80 and gb2312-1980 are a part of iso-2022, |which is different from euc-cn and gb2312. The maintainer should look at |the IANA alias table and this note |http://sources.redhat.com/ml/libc-alpha/2000-09/msg00210.html Accepted. We will fix the problem regarding gb2312-80. | |2) IANA, Windows and Java have many more aliases for GBK Accepted. We will update the alias table for GBK. | |3) I find it very odd that names are changed for the "STANDARD NAME". |For example, HKSCS-BIG5 is the name of BIG5-HKSCS. I presume this follows a |similar idea of UTR #22, but it's a little confusing why this was done. |The FAQ might want to mention why this was done. Rejected. The reason why HKSCS-BIG5 was adopted as the standard name was that BIG5-HKSCS did not follow the rule defined in the specification. The reason why we chose the rule in the specification is described in the Q&A document. Q18. Why are numeric characters not allowed for STRING1 of CODESET? A18. There are a couple of conventions that are used for the ISO/IEC 8859 series of coded character set. One is ISO8859-1 and the other is ISO-8859-1. In order to not make this guideline ambiguous, we decided to not allow numeric characters in STRING1. Therefore ISO-8859-1 is recognized as a standard locale name and ISO8859-1 becomes a user/implementation-defined locale name. | |4) I recommend using |http://oss.software.ibm.com/cvs/icu/~checkout~/icu/source/data/mappings/convrtrs.txt | as a cross-reference. I have fixed many alias bugs with it lately, and it |tags the source platform of each alias. I still have to work on glibc. | Accepted. Thank you very much for your suggestion. OpenI18N/LADE subcommittee is maintaining the character set alias table and will try to make fully use of the ICU mapping table to keep our table accurate. [End]