ICANN ICANN Email List Archives


<<< Chronological Index >>>    <<< Thread Index >>>

On Three-Character Restriction in gTLD Strings

  • To: three-character-variant@xxxxxxxxx
  • Subject: On Three-Character Restriction in gTLD Strings
  • From: Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>
  • Date: Mon, 04 Jan 2010 11:23:00 -0500


Since the first version of the DAG Werner and I have commented that the three-character restriction in gTLD strings was (a) unnecessary and (b) culturally specific, favoring users of alphabetic scripts over users of ideographic scripts. I am therefore, glad to see the restriction for IDNs reduced to two IDN characters. However, there remains several related problems, the subject of this note.

There are several problems with the quoted text below, from Section 4, page 6.

"Protecting two-character ASCII codes is essential.

All possible two-character ASCII codes should be set aside for use by the ISO 3166 Maintenance Agency, and neither those codes nor any other codes that are visually confusable with them should be allowed in the gTLD space. Two-character codes that are not visually confusable with the ASCII 3166 codes should not be restricted. Rules should be formulated to ensure consistency with established rules and procedures, to protect the two-letter ASCII 3166 codes.

ICANN must communicate with the TC46/ISO 3166 Maintenance Agency to achieve better and mutual understanding of how each organization operates in areas pertaining to the domain name space."

First, as has been pointed out on several prior occasions, "all possible two-character ASCII codes" is significantly greater than the subset of the alpha-two set of code points allocated or reserved by the iso3166/MA. The former is a 36x36 element array, or 1296 possible values, the later is a 26x26 element array, or 676 possible values. When the 10x10 array of "all digits" is removed from the "all possible" array, ICANN is still creating the presumption that it, or some other source of authority, is creating 520 code points which could be allocated, similar to the iso3166/MA's allocation of alpha-2 code points.

This conflicts with the policy taken by the IANA in 1994: "The IANA is not in the business of deciding what is and what is not a country." Source: RFC 1591 at page 5, "Country Codes".

If a rational is sought for not allowing applications for "4U" (or "0x06F5, 0x0055" which looks like "Heart U", to use an IDN example), a more conservative rule could be "no digits", a reasonable extension from the no leading, trailing, or repeated hyphen rule of long standing, and utterly consistent with all TLD label use from the HOSTTABLE period to the present date.

Second, despite the impassioned representations of the ccNSO that the "subsidiarity principle" allows ccTLDs to be repurposed, it is ahistorical, as ccTLDs have been repurposed as commercial operations offering unrestricted registrations for a very long time, and capture of ccTLDs by commercial operators continues. Exploits based upon confusability go back to the .bz vs .biz exploit, and continue with current .co vs .com browser lookup order algorithm.

The principle invoked should not perpetuate the fiction that that South Georgia and the South Sandwich Islands and the Peoples Republic of China are "alike", or dispense with the fiction that .eh shouldn't be delegated, but that .um should be delegated.

When we speak about principles, the principle of correctness is more important than the principle of asserting there exist two particular regimes, and then reasoning about them.

Third, the communication with the iso3166/MA is both overdue, and not sufficient to meet real requirements.

It should not be necessary for the League of Arab States or other regional or culturally significant international treaty organizations to use values outside of the alpha-2 set, while allowing the European Union the gimmick of promoting a currency code to a territorial code. Further, it should not be necessary for the iso3166MA's decision to allocate a dozen code points to regional intellectual property associations to restrict the set of values available for allocation to users of the DNS.

In sum, the "all possible two-character ASCII codes" set is an unnecessary, and unwise expansion of the use of the alpha-2 set maintained by the iso3166/MA, a "no digits" rule may suffice, and the interaction with the iso3166/MA must result in code point creation, not because the IANA is in the business of deciding what is and what is not a country, but because if two or more countries decide to seek a label, that exercise should not be culturally determined by ICANN, favoring only the European Union.

I am of course, employed by CORE, which has an interest in the outcome, though as usual, this is offered in my individual capacity.


<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy