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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf