Registry restrictions

[John C Klensin]

--On Monday, 05 May, 2008 21:42 +0100 Gervase Markham
<gerv at mozilla.org> wrote:

> Paul Hoffman wrote:
>>> (3) For any given thing we try to push off to the registry,
>>> are we offering advice or do we think we have some leverage
>>> on telling registries what they "MUST" do?
>> 
>> The former, only. We can't force anyone to do anything.
> 
> Which I think leads to a useful principle. We can "safely"
> leave to registries any action, the failure to do which will
> impact only that registry or its customers. They have full
> permission to shoot themselves in the foot. We should embed in
> the protocol any safety measure or restriction which, if not
> followed, allows a registry to shoot other registries or their
> customers in the foot.

While I agree with this as a principle, I wonder how practical
it is as a guideline for making decisions.   While there are
certainly some things that could, in principle, be done in
either the protocol or in registries, I see a number of things
that simply cannot be done anywhere but in the registries.    

As an example, it has been suggested many times that labels
should generally be restricted to having all characters in the
same script.  Registries and national administrations have
identified important exceptions to that principle such as, e.g.,
the need to mix Romanji, Kana, and Kanji in Japanese labels.
While I think there is general agreement that arbitrarily mixing
scripts in labels is a bad idea ("unsafe") and can create some
risks for users who invoke domain names, I see no choice other
than to leave specific rules about what should or should not be
allowed in combination up to registries.  

Similarly, I'm a fairly big fan of JET, and JET-like, "variant"
systems, but those systems can be applied only by registries and
by registries who are willing and able to make the decisions
needed to support them.  But, from an IETF point of view, we can
do little with those systems other than to describe them clearly
and possibly even to recognize existing practice and standardize
the mechanisms (not in the charter of this WG, but possible),
describe the types of problems for which they are useful, and
recommend to registries that they consider them as appropriate.

To respond to a more general part of this thread, an IETF
standard is ultimately just a recommendation about ways to do
things that are likely to maximize interoperability, Internet
performance, and good user environments.   We can make
recommendations to protocol implementers and, in this space, to
those who put names into the DNS.  We have been doing so for
years -- the LDH rules are ultimately nothing more than a
registry restriction.  We can also keep our own protocols
consistent -- it would not be surprising to see provisions that
"enforce" IDNA rules in protocols that call on it, any more than
it should be a surprise that LDH is "enforced" by SMTP.

Ultimately, if someone has a "better idea" for IDNs, whether it
be different mappings and a different prefix, a completely
different coding system, fundamental DNS changes (like my old
'new class' proposal), or even a complete replacement for the
DNS, nothing the IETF could do can stop them from trying... and
most of us know better than to try.  There may be other
pressures on them to not do that -- pressures from users whose
software may not interwork with the new ideas, pressures from
other implementers who consider the new ideas problematic, and
perhaps even pressures from enterprises and regulators who have
strong opinions about things that they might see as risks to
users.  But none of those are really IETF problems, even if we
provide the standards and advice that enable them.

    john