Occasionally, I find myself needing to think of a product name or domain name for a web site. Ideas can knock on my head at any time: at lunch, in the toilet or waiting in the queue. I could note it down on a generic note taker on the phone, or jot it down on a piece of paper, but nothing beats being able to instantly find out if the domain is available and keep track of it in a dedicated app. Hence, DomainTool was born.

As with any great app, it should be simple to use, and addresses a focused need. Thus, you’ll find the following grand feature list:

• Query WHOIS servers to find out if a domain name is taken. Similar to the command line whois tool
• Bookmark a domain name, and query it again anytime
• Supports all TLD that has a published WHOIS server: COM, NET, ORG, BIZ, INFO, CC, JP, CN, TW, KR, MY, SG, PR, DE, EU, and many more!
• Supports Internationalized Domain Names (IDN)

Some screenshots:

By now, I suppose you’re dying to try it out on your iPhone, and I can certainly sympathize with that. It can be yours for USD0.99 (or the equivalent in your currency) — 70% of which goes to my coffee bank, and the rest goes to Mr. Jobs.

Get it here!

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

While NeuStar already has many Latin-based IDN languages in its portfolio, one may wonder why we would bother making the Venn diagram so complicated. Just define a Latin script-based table and be done with it! Well, since we tend to take a more conservative approach with IDN, it is safer to have each language table contain only the characters used by that language proper and nothing else¹. After all, we’re here to provide value and not to make a quick buck (at least that’s how I see it.)

¹ Language is constantly evolving. Often, it is not easy trying to determine if a character used in borrowed words is well-assimilated in the culture to be considered part of the language. There are no clear rules, do we follow the guidelines from the trademark offices’ of the countries in which the language is used? Or do we follow the ccTLD registry (if we do, does it make sense for a gTLD?) Or language institutions? Thankfully, there are many great resources to draw from.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

I was very excited to hear that and wanted to blog about it but there was much to catch up at work so I let it slide.

Two days ago, an update from ICANN on this project:

ICANN today finalized the IDN .test Evaluation Plan and continued taking steps toward insertion of IDN strings in the root zone. Recent changes to the plan are based on comments received on the IDN public forum and also from consultations with ICANN Technical Advisory Committees. This last version was approved by the ICANN Board at their 14 August 2007 meeting. The resolution directs ICANN Staff to implement the IDN .test Evaluation Plan, and report back to the ICANN Board following the conclusion of the evaluation.

Specifically, the Board approved the delegation of eleven evaluative top-level domains representing the term ‘test’ translated into: Arabic, Persian, Chinese (simplified and traditional), Russian, Hindi, Greek, Korean, Yiddish, Japanese and Tamil. Following this ICANN Board approval, the delegation request will now go through standard IANA procedures for insertion of top-level domains into the root zone. The technical evaluations of IDN TLDs and their usability in various applications will proceed following their delegation.

This is a major milestone in the IDN Program Plan and signals a significant step forward towards Internationalization of the DNS. It is currently anticipated that delegation of these TLDs and the evaluations, as described in the plan, will commence in September 2007.

I would like to applaud ICANN (specifically Tina) on bringing the project this far. This is a major undertaking, and an important one too, for the following reasons:

1. It works across the Internet — not just an isolated test that involved a couple of PCs running in a lab environment; they are going to insert these labels into the root zone! This is the only way to involve the most diverse mix of participants in the test bed. The fact that it requires no special setup (like tweaking of hint files) may lower the barrier for entities such as ISP’s, who are traditionally seldom interested in the development of IDN, to participate.
2. As a result, it allows the most diverse array of test cases possible. Just imagine how an innocent domain name gets passed around applications, resolvers, recursive and authoritative DNS servers through a myriad of functions, API calls and networking protocols. It’s supposed to work but who knows for sure?
3. It tests major scripts used by regions with an immediate need for IDN-TLDs (Latin would have induced yawns)

I’m sure there are skeptics and ICANN-haters out there who will dismiss this for time-wasting activity, etc. The truth is, no one has actually tested IDN TLD’s on Internet-wide scale before. And no, country-wide deployments will not suffice because the diversity of software environments and cultures simply isn’t there.

And if you’re a proponent of the Just-do-it school of thought, this should be seen as a move in the right direction. If no major problem was found during the live test, it will shut the mouths of those who are doubtful.

We should take advantage of this test to file bugs for your favourite software vendors and get them to support IDNs! When was the last time IANA inserted a test TLD to the root? Tell them that if IANA agreed to put these test strings in the freakin’ root, this is not a default ignorable technology alright!

So, help spread the word and test the Internationalized Internet!

नमस्ते

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

You may be wondering if there is any connection between our Korean launch and the localization of EchIDNA. Aside from yours truly being involved in both projects, it is purely coincidental. We have been preparing for the Korean launch for a few months, and in doing so have consulted with NIDA (National Internet Development Agency in Korea) and have adopted their language table (with 2,350 KS X 1001 Hangeul characters). The table is available here: http://www.neulevel.biz/idn/KR_Table.pdf and will be posted to the IANA Repository of TLD IDN Practices soon.

If you have a .BIZ Korean IDN and would like some free links, submit it to IDNSearch.net!

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

First of all, EchIDNA is now localized to Korean thanks to Jaeyoun Kim (www.김재연.kr) who took the initiative that triggered a collaboration between us where he translated the EchIDNA user interface into Korean and I added localization support to the code. While I have long been thinking about localizing EchIDNA, I never did get around to doing it so I’m really glad that it’s finally out.

Here’s a screenshot of it in action:

This move was largely motivated by the disheartening news that Verisign discontinued its IDN Web Navigation system on July 25th 2007. A bit of explanation of the so-called IDN Web Navigation System is in order. Basically, every IDN registered in the com and net TLD gets one or more A records inserted into the zone that points to a Verisign web server(s). These are not punycode domain names but binary representation of the IDN in local code pages where it is likely used, plus maybe some IE-specific behavior. The latter refers to an IE5/6 quirk that will encode the individual bytes of the domain name in the system code page to UTF-8 by treating them as ISO8859-1 characters. By doing so, users who are using non-IDN aware browsers will be redirected to Verisign’s web service which will then offer them the ability to download its i-Nav plug-in, and at the same time select the correct IDN domain to navigate to. Since the A records are binary representations, there is a possibility of collision which explains why the users have to select. It’s not hard to imagine that the general Internet users may mistake i-Nav to be the Web Navigation system that they were using, and since it works why bother downloading anything? So my guess is that many users simply ignored the i-Nav download part and click through to the site they wanted to go to. When the service was discontinued these users were lost. It didn’t take long for the domain owners to notice and complaints started flooding into the registrars and hosting providers. Some of these complaints also made it to NIDA which had an agreement with Verisign to distribute the i-Nav plug-in (and since users confuse i-Nav with the IDN web navigation system, it just looked like “i-Nav stopped working”.)

While I agree that this is really a hack and that the service cannot run forever, it is simply too soon as IE7 is not even one year old in Korea. Even though there is technically nothing wrong with discontinuing a hack, I can’t help but question the ethical validity of the decision, given the obscene amount of cash made from these TLDs. I wonder if the transition could be made smoother by first disabling the navigation feature and explaining to the users that they really need to be using an IDN-aware browser or download a plug-in.

Many ccTLD registries (CN, DK, JP, KR, TW to name a few) that offer IDN registration also run a similar web navigation system for their TLD, and AFAIK are still running it.

So, back to EchIDNA. The localized version was released on August 15th, 2007 and is available on http://idn.isc.org/

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

So we just opened the flood gates for Chinese and Japanese IDNs for .BIZ. This has been my brainchild for the past half a year or so, and represents a significant step forward for our registry in terms of internationalization. As one might expect, no support for Chinese IDN is complete without bundling as specified in the JET guidelines and RFC4713.

The tricky part to supporting both Chinese and Japanese IDN within a single registry is that the two languages share a large repertoire of Han characters. While the concept of Simplified and Traditional Chinese is well-understood within the Chinese communities, Japanese generally do not use variants the same way. Two characters that may be considered variants by a Chinese user may be seen as distinct characters with different semantics from the Japanese’ point of view. To implement a registry that respects the culture and expectations of both language communities while offering a high degree of protection against homographic attack is a juggling act in itself. I dare say that NeuStar is the first unsponsored gTLD registry that Got It Right ™.

So, how does it work? Well, suppose you registered 電車.biz with the Chinese language tag, you will automatically get the simplified version of the domain, 电车.biz, placed into the DNS for you. No one can register any combination of variants of the domain, e.g. 电車.biz and 電车.biz.

What if you registered a mixed version 電车.biz, also with the Chinese tag? Well, you get that PLUS 電車.biz (traditional) and 电车.biz (simplified) giving you 3 domains in total! That is because we respect the registrant’s request, even if it looks like a mixed- traditional and simplified string. Whatever you asked for, if it doesn’t clash with another registered domain, will always be given to you.

If, however, the Japanese tag was used to register 電車.biz, that would be the only domain that you’d get. Once that is registered, other variations of the domain name in Chinese will not be allowed to register. This is a slight deviation from JPRS‘s appraoch, which treats them as distinct domains. We feel that this conservative approach offers better protection for the registrant.

So that was the skinny on our Chinese and Japanese Internationalized Domain Names offering. Is it me or do Han characters look very good with .BIZ? =)

Usual disclaimer about this being my personal opinion applies.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Recent discussions about security and phishing on the OpenID list got me thinking about the problem space.

DNS plays a critical role in the security of OpenID because

1. URL is the identifier type used
2. User should only trust the OP with which he/she has an account with.

The “Phishing and OpenID” discussions on the OpenID list actually hinges on point #2 above. Ben Laurie wrote about it here. In short, OpenID opens the door for a malicious RP to send a user to a spoofed OP-lookalike and collect his/her password.

Back to DNS. I have, on numerous occasions in the past, tried to look for a list of domains where registrations are open for public. This varies from TLD to TLD, e.g. .biz accepts registration directly on the second level, .us also does but delegates two-letter subdomains to US states, and .uk only accepts registrations on the third level after .co.uk, .ac.uk, etc.

Well, it turns out that the Mozilla folks needed this list in order to disallow web sites setting cookies for the entire .co.uk or similar domains. Currently, they block just the TLDs so example.com cannot set a cookie for .com, but 2nd level onwards domain cookies are allowed. This could easily cause cookies to be stolen by any site rooted in the same domain.

So, this advisory started this bugzilla entry at Mozilla and it eventually led to the creation of this API and this list (see attachment). They call it the “Effective TLD” list, which is really a misnomer because they are not necessary just TLDs. It was decided in the bug discussions that the term “effective TLD” is easier to digest that anything else, though I’d prefer to call it “Security Restricted Domains”. Whatever, as long as it gives me the content I want.

Many will probably criticize Mozilla for creating yet another list that gets stale the moment it is created. Indeed, TLDs get created and 2LDs within TLDs are introduced and deprecated so often that such a list will be hard to maintain. Moreover, many organizations assign names to registrants at a level that doesn’t involve the TLD registry. Examples include CentralNIC’s .<country-code>.com and *.blogspot.com, and countless others. Add to it the introduction of IDN TLD may well be in less than 2 years. Keeping a definitive list is not feasible. Nevertheless, I would argue that depending on your needs, this list could still be very valuable, as is the case with the cookie problem that they are trying to solve.

So, what has this got to do with OpenID? I shall leave that to a different post.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

I’d like to take this opportunity to thank DK-Hostmaster, ISNIC, NORID, NIC-SE and Cary Karp of MuseDoma for their help and advice on these tables. The work on these tables really started 2 years ago when we first had the intention to launch additional languages, so I am very proud and relieved that they made it out!

Here’s a summary of the non-ASCII characters available for registration:

If you’re looking to register a Scandinavian or Spanish domain name, visit your favourite domain registrar to get yourself one.
When you’re done and made a web site out of it, don’t forget to submit it to IDNSearch.NET!

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

September 30 – RFC4690 – Review and Recommendations for Internationalized Domain Names was published. Here’s the abstract from the document:

This note describes issues raised by the deployment and use of Internationalized Domain Names. It describes problems both at the time of registration and for use of those names in the DNS. It recommends that IETF should update the RFCs relating to IDNs and a framework to be followed in doing so, as well as summarizing and identifying some work that is required outside the IETF. In particular, it proposes that some changes be investigated for the Internationalizing Domain Names in Applications (IDNA) standard and its supporting tables, based on experience gained since those standards were completed.

Yes, you heard right – it is a proposal to update the IDNA standard. The story is this: IDNA is based on Unicode version 3.2 which means that many newly added characters (especially many African scripts) will not be usable as domain names. Unicode is at version 5.0 now and is continually being updated. The fact that IDNA has no versioning feature is a massive headaches for the standards bodies and implementors alike.

October 18 – The much anticipated IE7 was officially released. Internet Explorer is the last but largest major browser to support IDN, making this the most important event for the world of IDN.

October 23 – Afilias announces new scripts (Polish, Swedish, Danish, Hungarian, Icelandic, Latvian, Lithuanian and Korean) for IDN in .INFO (Press Release).

More IDN news to follow, stay tuned.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

The final release of IE7 is fast approaching … and I mean really fast … and will be delivered to customers via Automatic Updates a few weeks after it’s available for download.

The #1 feature in IE7 that interests me greatly is its support for IDN. Yes, it’s a little late (3.5 years after the IDNA standard was published and more than 4 years after Mozilla implemented it in the browser.) Still, being the most popular browser on the planet this marks a very important milestone in the history of IDN. In fact, JPRS saw the IDN registration numbers soar after Microsoft announced that IE7 will support IDN. I’m sure many other IDN-enabled registries experienced similar surges too.

I’ve been using the RC1 version of IE7 for about a month now, and have been using IDNSearch.net to find example IDN URLs. So, if have IE7 installed and want to see a real-life IDN in action, head over to IDNSearch.net.

If you’re an IE6 user, I would encourage you to upgrade.

Download IE7 here: http://microsoft.com/ie
Find IDN examples here: http://idnsearch.net/

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.