> > > How about ToACE and FromACE > > No, because the output of ToUnicode is not always ACE, and the input > of > ToASCII is not always ACE. >
My choice of using ACE due to that we are dealing with a new form of encoding - punycode in ASCII. ( By the way, I like punycode, it is technically sounding and cute to be used among programmers.) It is another level of encoding using ASCII. Traditionally (in the last three decades), we call them input-encodings, Big5 encoding, Chinese telegram code, keyboard encoding, Five-Strok code, ... it is easily to name a thousand of them, since there are over 600 such recorded names eight years ago in China when I did the research. While ToASCII and FromASCII may win more vote on this list, but the output/input implys it may contain NLDH following your reasoning, which contradicts to Stringprep/nameprep spec! Since the name will never match exactly what it is anyway, giving some consideration to existing usages of the terms should have a little more weight than we are giving them at this point. Afterall this will be the interface between IDN to all applications for many different natural languages as well as programming langages, especially related to the existing usage on Unicode, GB, Big5, JIS, KSC, ISO8859... At this stage, we may consider it is a minor difference among us, but it is an interface we are designing for a huge mess we know very well is out there watching and waiting. I don't consider the naming is a minor subject in discussing. Another note regarding the use of Unicode in China, it is a table of a supper set of Han characters including CJK and many other human characters( a glyph with sound and name). It is used as the character set standard for newly published dictionaries already. If our naming use toUnicode, then it says two things: 1. We allow the complete set of USC to be published at this time, in fact, only Latin code blocks are in nameprep and able to pass the examination. Which the Chinese user community already has raised complain and have asked CJK to be formally exculded at this time. 2. It excludes other possible encoding forms. Since DNS does not forbit other encoding to pass through, we will have to provide more explanation regarding the undefined area of IDN. Liana
