It's to do with partial name resolution. I was a problem in the early 1990s but is porobably not a big issues any more. See: http://www.ietf.org/rfc/rfc1535.txt

Hi Bret,

We requested ICANN to release the two-character names because of the large prevalence of two-character names in Asia (when transcribed from the local character set), and because .name now begins to get more traction in Asia (partly as a result of the .name partnership with Yahoo! Japan), the two-char names are being requested by large portals - so they can offer .name to their customer base.

Over 250M people in China alone have a two-character last name, and we think it is deeply unfair and simply wrong that these should be blocked from getting a personalized address on .name. (For some stats on Chinese names, see: http://en.wikipedia.org/wiki/List_of_common_Chinese_surnames)

The core of the technical issue lies, as you point out, around RFC 1535. The reliance on this RFC is misplaced if not irrelevant. In fact, RFC1535 is outdated and amended by RFC 1536. In evaluating RFC 1535, it is important to consider the following:

1) RFC1535 is not specific to two-character names (it affects any domain length) and describes _bad_ resolver behaviour that was corrected in RFC1536.

2) There are already massive TLDs where this would be a serious issue if RFC1535 were relevant (thus, it is not): There are already domains like li.com, li.net, and name.com, name.de, and co.uk, me.uk, co.jp etc already active on the Internet. If one concludes that RFC1535 leads to instability or security issues related to .name two-character names, one must also conclude that the Internet today is unstable. Clearly this is not the case. For example, the issue has never seriously been discussed in the GNSO, CCNSO or SSAC as a current stability threat. It would have been a serious issue for e.g. .org, .com, .net or Colombia (.co) to have substructures like .co.uk, .com.au or co.jp if RFC1535 was still relevant.

3) RFC1535 behaviour was deprecated in BIND 13 years ago: The behaviour described in RFC1535, was fixed in release 4.9.2 of BIND in 1993, more than 13 years ago (!). The BIND 4 resolver is officially deprecated (http://www.isc.org/sw/bind/bind4.php) (it is now in version 9). We should not restrict .name two-character names because of an old deprecated resolver which poses no threat to security that would exist anyway because of 2). The only resolver in the 4 series that can be used, if one has to, is 4.9.11 which does not have this bug.


Therefore, why should people with two-character names be blocked? With no technical issue with opening up two-character names on .name, it is only right to let people with two-character names use them on .name. There are around 250M people in China alone with such names, not including Korea, Japan and other countries where two-char names are also prevalent (e.g. NG (Korea)). We should release these names to the Internet for the benefit of people worldwide.

If any readers have a two-character surname and think it should be made available for sharing on .name - tell ICANN. The email address for comments is gnr-proposal-comments@icann.org

Friendly regards,

Hakon Haugnes
Global Name Registry