Meeku, > Punycode exists at the Whois for Internationalised Domain Names and you > could easily put a Y2K project management with a timeline for ending old > type ASCII registrations and where new type Punycode registrations would > commence at ASCII names. ASCII names would get processed via the Punycode > field like you have with IDN and your previous ASCII field shuts, that's > all. The main point of punycode is that pre-IDN ASCII domains are encoded with themselves in ASCII while other unicode Characters could be encoded with a sequence of ASCII characters, so that IDN could be implemented on existing DNS infrastructure. ASCII domain names *are* in fact punycode domain names by definition. As soon as you want to encode ASCII characters with something else, you'll need a new parallel DNS infrastructure and at this point a new version of DNS protocol that works natively with UTF-16 or b64 encoded UTF-16 or UTF-8 (oh, wait, UTF-8 also encodes ASCII characters as themselves) could just as well be developed. But the bottom line is that there is no way to develop a "new punycode" encoding ASCII domain names with something else then ASCII and implement that on existing DNS infrastructure without completely breaking the Internet, period. > Software applications would catch-up to this via the Y2K sort project > management and also via market. Unicode got accepted then Punycode at > ASCII registrations compatibility should also get accepted. You were complaining yourself in your correspondence with ICANN representative how slowly IDN are being implemented by software developers (even though this implementation is a simple matter of adding a Unicode-to-punycode translation routine, provided the application is actually using Unicode functions to process text in the first place). Do you seriously think they would implement faster a new name-lookup protocol that might require them to completely rewrite large portions of their code? > You have Punycode existing at IDN then you can also use same at ASCII. > Only the registration window get's changed and you have an extended > Punycode that also changes ASCII registration into Punycode. The user > community would really become happy because you would get quicker IDN > implementation and a new type registration that are Multilingual. > Software application integration would happen early. This would help > those people that speak / write more than one language. People could then > interact better and with virtue atmosphere than before they were able to > with only their single language domains and software applications. You > find that there are countries where the railway stations are using their > traditional languages as well as the english language. The world has > become more cosmopolitan and thus you need this to happen very urgently. Frankly I can't really see the point of all this. The only reason why the users sometimes need to use "raw" punycode strings is because IDNA is not properly implemented in all software yet. Once the software catches up, the users won't really need to care how exactly punycode works. Yes, it takes time to implement IDNA to the point where it can be widely used, like it also took quite some time to implement Unicode in text processing (even now it is still not implemented in all applications and some features of Unicode are not implemented at all). Consider btw that the reason why UTF-8 encoding scheme gained so much popularity is because of its ASCII-transparency and backward-compatibility with octet-oriented applications. In any case IDNA, as defined by the current standard, can be realistically implemented much faster and easier then any alternative solution that is not backward-compatible with current applications and I can't see why you are so unhappy with it. Ruszlán _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf