ICANN Approves Non-Latin ccTLDs 284
Several readers including alphadogg tipped the news that ICANN has approved non-Latin ccTLDs at its meeting in Seoul. "Starting in mid-November, countries and territories will be able to apply to show domain names in their native language, a major technical tweak to the Internet designed to increase language accessibility. On Friday, the Internet's addressing authority approved a Fast-Track Process for applying for an IDN (Internationalized Domain Name) and will begin accepting applications on Nov. 16. The move comes after years of technical testing and policy development... Currently, domain names can only be displayed using the Latin alphabet letters A-Z, the digits 0-9 and the hyphen, but in future countries will be able to display country-code Top Level Domains (cc TLDs) in their native language. ... 'The usability of IDNs may be limited, as not all application software is capable of working with IDNs,' ICANN said in a 59-page proposal (PDF) dated Sept. 30 that describes the [application] process." Reader dhermann adds, "Great, now even less chance I can identify NSFW links before they are blocked by my work's big brother app and my boss is notified... again."
Comment removed (Score:4, Informative)
Re:Encoding? (Score:5, Informative)
To avoid breaking all the DNS-related code out there that assumes (ie correctly, based on the current spec) only alphanumerics and '-' in each component.
If you wish to rewrite every single bit of DNS-dependent code, in every laptop, server, embedded network device, etc, etc, ... well assume that it can't be done, and with this mechanism it doesn't need to be. Though I bet a few bits of code will barf at the '--' anyhow...
Rgds
Damon
Re:Encoding? (Score:2, Informative)
I am not DNS guru, but guessing. RFC882 - November 1983. RFC2044 - October 1996.
Re:ICANN has lost it! (Score:2, Informative)
Re:Phishing aid (Score:4, Informative)
I think the limitation that nationalized character sets will be restricted to the country TLDs where that language is native is a good first step. Additionally, I believe you're not allowed to use the latin alternative form characters from unicode (like 0xFF20-0xFF5F).
If you're really paranoid, you could just be extra suspicious of domains that end in two letters (and yes, I am including .us), particularly when the 2nd level name is something you recognize, like paypal, ebay, etc. If you're in China, there may indeed be a legitimate paypal.cn, but I suspect it would set off my spidey sense to see a URL like that show up in my e-mail.
Re:Phishing aid (Score:2, Informative)
There are letters in the Cyrillic alphabet that have different character codes than their look-alike letters in the Latin alphabet.
Remember we are talking about ccTLDs. There are no more than 200 countries that would like to use non ASCII ccTLD, and they can be inspected manually. Russia wasn't awarded Cyrillic .ru because it looks like Latin .py (Paraguay). They will get .fr (Russian Federation) that looks like 0p (0 with vertical bar).
Re:TLDs only? (Score:3, Informative)
It's already been in use for the rest of the domain name under certain TLDs for some time.
it just got easier to phish (Score:4, Informative)
Yay. Now you can can register yourbankname.com with some funky characters that render in exactly the same way as the letter you are used to.
Re:And the answer to that... (Score:5, Informative)
You don't understand. Punycode is how second-level domains are already implemented, even on top of relatively old browsers. This is an extension of Punycode to be usable in the TLD as well.
In other words, your current version of Firefox will be able to visit pages in IDN TLDs when they're implemented, and so if someone does create a .örg TLD today, you can go to www.anysite.örg to your heart's content already.
Note that this doesn't mean you can go to www.anysite.örg in NCSA Mosaic or anything, because these old browsers were around when Punycode wasn't even a standard. You can go to www.anysite.xn--rg-eka and NCSA Mosaic will recognise that, though. The seamless IDN TLD usage is just going to be present in the more modern browsers. I expect that Opera 8+, IE 6+, Firefox 2+ and recent Safari/Konqueror/Epiphany are going to be able to visit www.anysite.örg and 'hide' the xn--etc- access details from you, the user.
Happy surfing!
Re:Its to do with people with the wrong keyboard . (Score:4, Informative)
How exactly do you think you'll be able to type in a URL in mandarin or russian on west european keyboard?
You enable Chinese keyboard layout (dunno what's it called), and type it. The letters printed on the keys of your keyboard aren't some sort of magic that lets your computer input languages written in them, you know.
I don't have any keyboards with Russian characters on them, but I happily type in Russian regardless (in fact, I only first realized that I do actually truly touch type when I first ran into this problem, which turned out to not be a problem in the end).
Re:terrorist level domain (Score:3, Informative)
That has been possible for years.
This is about registering bankofamerica.cõm or lloydstsb.cø.ûk
The part AFTER the dot.
Re:ICANN has lost it! (Score:3, Informative)
if you want to go changing that there needs to be a damn good reason
I don't have any first-hand experience, but according to the BBC story when one enters a native-script domain name into one's browser, the domain name is entered normally (for the locale) and then to enter, e.g., ".in", one needs to press a key combination to shift the keyboard into latin-mode, then, enter the two letters, then shift the keyboard back into native mode.
It's a usability problem. I sure would be annoyed if .com had to be rendered in Kanji on my system.
Re:Um, can they be more specific than "Unicode"? (Score:3, Informative)
Several mistakes there.
First of all any domain name is going to have to be encoded as a stream of bytes somehow because far too much stuff is already implemented to handle the string that way. As others pointed out punycode is used.
Second, UTF-8 is smaller than UTF-16 for all languages, even Chinese. This is because all the ASCII 0x00-0x7F characters are smaller, and therefore the encoding will be smaller if there are more of these than there Unicode 0x800-0xFFFF characters. This seems incorrect for Chinese but you have to realize that ASCII includes spaces, newlines, numbers, and all XML and HTML markup and therefore any reasonable sized Chinese document will be smaller in UTF-8.
Translating encodings to "wide characters" is a mistake, as you have noticed. You should write your software to deal with it in it's original encoding because that is the only way to intelligently deal with errors in the string. The fact that Windows uses UTF-16 for an encoding a lot seems to be confusing people no end, but please check exactly what they do when that UTF-16 has surrogate pairs, or even "invalid" surrogate halves. They are handling the original encoding, they are not "translating it to Unicode".
Re:Here comes the Phishers! (Score:3, Informative)
If ICANN did not standardise this then nations will just implement their own systems which will be different and incompatible with each other, much like China and Thailand have already done.