[idn] Re: character tables

[Cary Karp <[e-mail]>]

Quoting Erik van der Poel:

> I note that this particular conversation is between a browser 
> developer (Gervase) and one of the IDNA authors (Paul), neither of 
> which is a registry representative, so why exactly are you 2 
> having this conversation? :-)
>
> Sorry, I'm half joking. Half, because you two have every right to 
> discuss whatever you wish. The other half because I believe 
> browser developers can afford to focus more on their end of 
> things.

Under the assumption that the discussion might be furthered by a 
registry rep describing that end of things --

I'm responsible for the development and maintenance of the policies 
for .museum. This is a sponsored gTLD (sTLD), which means that there 
are eligibility requirements for name holders, and restrictions on 
the way names may be structured and used. The policies specific to 
IDN are stated in detail at http://about.museum/idn/idnpolicy.html, 
which includes links to both the general policy statement and the 
listing of permitted characters and code points. Although 
prospective name holders are unlikely to read the fine print, the 
detailed statement provides an unequivocal reference in the 
case-to-case discussions about policy instantiation that we 
frequently conduct with individual museums. That dialogue provides 
an effective barrier to deliberate abuse of the .museum namespace 
(which we are contractually obligated to prevent) and is also a 
safeguard against inadvertent homographic confusion.

There are significant differences in the operation of an 
unrestricted gTLD (uTLD), where there may be a far greater volume of 
registration traffic, and direct contact between the registry and 
registrant is not a part of the registration process. In this 
situation, such things as restriction on IDN registration need to be 
fully automated, with sentient review being a remedial device when 
it is noted that something the algorithmic filter is intended to 
stop has nonetheless passed through.

The gTLD registries are as concerned by and with the present 
homograph alert as is any other group attempting to curb the risk 
for such damage. In addition to the range of operating conditions 
implied above, there are differences in the way the registries have 
interpreted and implemented ICANN's IDN Guidelines. That document 
states, "As the deployment of IDNs proceeds, ICANN and the IDN 
registries will review these Guidelines at regular intervals, and 
revise them as necessary based on experience." We are now clearly at 
such a juncture, and the revision process is already being 
initiated. Reducing the latitude for interpretation of the 
Guidelines will bring the registries one important step closer to 
being able to establish a best practice that can bring an end to the 
concern about point-of-registration control that is currently being 
expressed.

The development of these best practices would be further abetted by 
the candidate IDN repertoire being purged of the graphic symbols and 
other signs that are not needed in a naming system (using that term 
in a sense that a linguist might regard as reasonable) but clearly 
exacerbate the risk for malicious exploitation. There is similar 
utility in freeing IDNA from its current lock to Unicode 3.2. Since 
both of these concerns can only be addressed through revision of 
nameprep and stringprep, that action is of priority concern to the 
registries.

There is more to be said about gTLD perspectives on the role IDN 
plays in the communities that we serve, but I'll save that for 
separate communication.

/Cary