Registry restrictions (was: Re: Domain names with leading digits (Re: Determining the basic approach))

Erik van der Poel erikv at
Mon May 5 19:46:29 CEST 2008

On Mon, May 5, 2008 at 10:12 AM, John C Klensin <klensin at> wrote:
>  --On Monday, 05 May, 2008 18:50 +0200 Harald Tveit Alvestrand
>  <harald at> wrote, responding to Paul Hoffman...
>  >...
>  >> Of course. But the WG is relying on registry rules and
>  >> recommendations  for many other things that are being changed
>  >> from IDNA2003. We need to  be consistent on this point: can
>  >> we remove things from the IDNA  protocol and have them be
>  >> enforced by registries, or can't we?
>  > Let's list them and do them case-by-case (in another thread,
>  > please).
>  Just to clarify the model that was used to shape the existing
>  documents, the assumptions are:
>         * There will be things that cannot be done strictly in
>         the protocol that are, nonetheless, important.  We hope
>         that they can be handled by registry restrictions and
>         believe that registry restrictions (heavyweight or
>         lightweight and independent of the methods used) are an
>         important part of the picture, not just desirable.
>         * There will be things that cannot be done strictly by
>         registries that are, nonetheless, important.  We hope
>         that they can be handled by protocol provisions (at
>         registration time, lookup time, or both) and believe
>         that such protocol provisions are an important part of
>         the picture, not just desirable.
>         * So, even though we are not, in general, prepared to
>         tell registries what provisions and restrictions they
>         should (or must) apply, we believe that some things are
>         better done by registries than by protocol.
>         * We also believe that there are some things that
>         dangerous or treacherous enough, or that raise long-term
>         issues that are potentially problematic enough, that
>         they have to be checked in the protocol, not just left
>         to registration-time activity.  The most important
>         example of this involves characters that are invisible
>         out of context, notable the joiners, but we believe that
>         special measures for unassigned and disallowed
>         characters are also in order.
>  That obviously leaves three sets of questions for the WG:
>  (1) Is that model reasonable?
>  (2) What very specific things should be pushed off to the
>  registries (remembering that "registry" equals "any zone in the
>  DNS") and which ones left in the protocol (at registration time,
>  lookup time, or both)?

I believe both the model and the specific things are reasonable (as
currently stated in the drafts). However, one of the biggest remaining
issues that this WG must address is the fact that we don't have
consensus regarding the reason(s) for checking and prohibiting labels
at resolution time, for both disallowed and unassigned characters.
See, in particular, Martin's recent email pushing for clear reasons
from yourself and Patrik. My response to that email was apparently not
on the mark, since Martin did not respond further. We basically need
to explain why resolvers should check and prohibit, rather than simply
refraining from *displaying* "dangerous" or confusing labels. (Again,
my emphasis on display issues here may not be addressing Martin's and
others' concerns.)

>  (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?

I think we need something between those 2 extremes (advice and MUST).
I.e. strong recommendations, since we can't force national registries
to do anything. But it wouldn't hurt to point out that resolvers and
displayers are the final line of defense between rogue zones and
users. You may not want to say anything like that in the RFCs, but it
is simply a fact.


>  Just IMO.
>      john
>  _______________________________________________
>  Idna-update mailing list
>  Idna-update at

More information about the Idna-update mailing list