Unicode versions (Re: Criteria for exceptional characters)

Cary Karp ck at nic.museum
Tue Dec 19 11:12:04 CET 2006


> Suppose that in the protocol we allow Hebrew, but recommend against
> (for some reason) final forms of letters. Registries and user-agents
> can then start by following those recommendations, but if it turns
> out to be necessary to allow them in (either fully or in limited
> circumstances), it is relatively easy for them to do so. Baking a
> prohibition against final-forms of letters into the protocol is a
> much different matter -- it takes quite a while for everyone to
> update to a new version. (And during that time, I have no doubt that
> we will hear charges of discrimination...)

The TLD registries that are introducing support for IDN in a measured
manner all seem to be doing so with extreme caution. The predominant
practice is to select highly limited subsets of the available repertoire
on the basis of the language requirements of the communities the
registry serves, and to support those languages subject to further
policy restrictions that may be appropriate from registry to registry.
(Please note the distinction between "registry" and "registrar". The
latter may or may not provide a front-end to the IDN policy engine
provided by the registry operator -- otherwise falling back to a
pre-established mechanism for enforcing the hostname rule -- but is not
likely to be imposing any intermediate constraint.)

These registries are fully aware of the need for reducing the latitude
for interpretation that attaches to IDNA2003, and look forward to the
increased focus of IDNA200n, both because of the direction it will
provide to the operators of lower-level registries, and because of its
potential for reducing less laudable manifestations of differing
interpretations of IDNA among competing TLD registries.

The TLD registries are perfectly capable of assessing the language
requirements of their local constituencies without our assistance. If
the operator of the Azbukastani national TLD registry doesn't feel that
they have an adequate understanding of the extent to which the
final-form characters in the Azbukastani alphabet can be treated as
optional components of a DNS-safe orthography, they will turn to
expertise in the proximal academic community. What may then be a rather
intricate pedagogical exercise in explaining any trade-offs between
orthographic detail and DNS-safety will similarly be a matter of local
concern.

There is still a clear need for a channel through which registries can
communicate the core documentation resulting from such local discussion
to other registries that may also wish to support a language, but do not
have the same immediate access to members of a community in which it is
in regular business use.

The IANA effort at providing this venue will require significant
bolstering if it is to become truly useful, and there is some discussion
about establishing an alternative if it is not the appropriate point of
anchorage. I doubt, however, that we would be able to find a single TLD
registry that feels it reasonable for the IDNA revision to be delayed
because participants in the normative action who are not otherwise
involved in TLD registry operation have allowed their attention to be
diverted by that separate dialog.

A meaningful revision of IDNA cannot leave us with need for an extensive
narrative detailing all of the pitfalls that still haven't been
eliminated. The residual common-sense details that are nonetheless
certain to remain, need to be on a scale that can be comfortably
articulated in the ICANN IDN Guidelines, or a planned successor
instrument. (If anyone wishes to discuss that action in detail, ICANN
maintains a separate list for it.)

/Cary


More information about the Idna-update mailing list