[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[idn] Re: character tables



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