[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