Registry restrictions

Andrew Sullivan ajs at commandprompt.com
Tue May 6 17:21:47 CEST 2008


On Tue, May 06, 2008 at 09:32:02AM -0400, Vint Cerf wrote:

> The purpose behind the standards is to try to reduce the likelihood
> of harmful registrations and to maximize the benefit of IDN use. We
> plainly are drawing a line between the use of the standards for this
> purpose and the recommendation that other kinds of protection
> (restriction) be left to registries to implement.

I don't feel real comfortable with the IETF's track record on
maximizing benefit or reducing likelihood of harm; but, I think we have
a history of careful definitions of interoperability.  So I would
prefer to stay with a target of good interoperability.

We might therefore say that the purpose of the standards is to ensure
that IDNA2008-enabled querying clients can rely on predictable
behaviour on the part of IDNA2008-providing DNS and registration
systems.  I know that IDNA doesn't really change the DNS _per se_, but
since we are carting the use-value of a label around by applying a
special semantics to the bit-value of that label, "DNS query +
subsequent IDNA2008 interpretation" is one (the?) practical operation
that needs to be tested for interoperation.

I think that means I agree with Gervase Markham, in that anything that
may merely affect operations between a registry and its customers may
(or, I'd say, should) be left out of the protocol, because the
"surprise" in that case lies with the policy rules around what is in
and out of a registry; but inter-domain safety is a matter for the
protocol.

If we accept that, I think it means that Stephane's example of the
wildcard is an unfortunate historical mistake, to be lamented and not
perpetuated.  That conclusion pulls a lot of what I used to think of
(when wearing my registry operator hat) as registry policy right into
the protocol.  Is that what we want?  (I wonder whether registry
operators would agree to implement such a protocol.)

I also think the above means that the bidi case that started this
discussion probably does need to remain in the protocol, even though I
have some sympathy with the view that it feels very much like a
registry policy.

In my opinion, if the plan is to have a protocol-ish part to the
documents that is really a collection of things registries who want to
play nice really-really-should-do-we-mean-it-earnestly, then another
document is probably needed.  It should target BCP and be a set of
recommended policy rules for registration of IDNA2008.  When I was
implementing things for registries, I would pay attention to protocol
rules and to BCPs, and also to contractual requirements.  Side
observations in protocol documents about things that maybe should be
taken into consideration by implementors will be ignored by
implementors when it is convenient to do so.  One may argue that such
implementors may just as easily ignore the BCP; but at least in that
case, there would be no ambiguity over what they were ignoring and
what they were attending to.  If we were to go this route, I also
think that being more conservative in what goes into the protocol
itself becomes more practical.  I suspect that registry operators
would feel more comfortable with such an approach (although, since I'm
not one any more, I can't speak authoritatively on that).

A

-- 
Andrew Sullivan
ajs at commandprompt.com
+1 503 667 4564 x104
http://www.commandprompt.com/


More information about the Idna-update mailing list