Charter changes and a possible new

[Cary Karp]

Quoting John:

> * For reasons Patrik has outlined and a few more, I believe that
> starting over with an attempt to define a new charter and a new
> base document would set us back at least another year and
> probably longer, regardless of the final content of that charter.
> 
> * As a corollary to that point, I do not believe that any of us
> have unlimited time to invest in IDNs.

One of the things that may be so frequently snagging the discussion
here into non-convergent iteration, is the lack of objective criteria
for determining what is realistically and reasonably implementable by
IDN zone administrators, and what, without any alternative, must be
determined by protocol.

There is nothing particularly unusual for, say, the policy restrictions
in force at a TLD registry to be relaxed in a manner that makes labels
available that previously were not. When such things happen, the
registry needs to figure out how to deal with registrants who would
certainly have registered labels in the new form had they been available
earlier, but accepted compromises, and now don't wish to see the new
labels being delegated to entirely different entities.

A common enough registry stance is to treat this as an inevitable
attribute of an expanding market, with frank acceptance of the risk of
two separate entities having similar domain names, and the resulting
potential for confusion in user community. The alternative is also
implemented frequently enough, but involves potentially intricate local
decisions about sunrises, bundling, and blocking, without there being
any reasonable way to factor out a single aspect of this into the
protocol realm. (This is where ICANN's IDN Guidelines enter into the
picture, a subject about which I will gladly say more if it appears to
be of further interest.) 

This situation long predates the advent of IDNA, and releasing a body of
newly-available labels by extending the permissible character
repertoire doesn't change the registry operator's fundamental policy
concerns one jot. What it may do is render it advisable for the
registry operator to seek advice about the reasonable needs of the
language communities being targeted by the added code points. One
obvious basis for that discussion is by establishing script-based
venues such as the one that resulted in the JET Guidelines (RFC 3743),
and the Arabic Script IDN Working Group (ASIWG) currently hard at work.

It seemed for a long while that the input from such efforts, together
with that of ccTLD registries serving well-defined language communities
to which they themselves belong, was being heeded closely by the folks
working on the IDNA revision. But the discussion here has now reverted
to questioning such things as whether an equitable internationalization
of the identifier space really does require severing the bond to an
earlier version of Unicode, or even if we need to be sensitive to
requirements  that are being articulated with reasonable clarity by
non-Anglophone communities.

It therefore strikes me as more than slightly paradoxical that an effort
triggered in no small part by lack of faith in the ability of TLD
registries to compensate in policy for ambiguous details in IDNA2003,
is preparing to make such heavy reliance on the ability of TLD
registries to tie up similar loose ends in whatever protocol statement
it ultimately produces.

/Cary