On Three-Character Restriction in gTLD Strings

[Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>]

Staff,

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.
Eric