looking up domain names with unassigned code points

[John C Klensin]

--On Monday, 12 May, 2008 05:57 +0200 Patrik Fältström
<patrik at frobbit.se> wrote:

> In the implementations of IDNA I am writing (more for DNS
> registration side than lookup side) I am definitely doing
> multiple A-label => U-label => A-label iterations to ensure
> the string is "stable" and accepted regardless of whether the
> string start with an A-label or U-label. That is the easiest
> way to check that the string is "ok" (programmatically).
> Instead of having different rules depending on how the label
> "enter the system".
> 
> I would be very very nervous if some document made it
> "impossible" to do such tests.

I would be very nervous if some document did not _require_ the
equivalent of such tests.  In other words, regardless of what is
done on the lookup side, I believe that it is the responsibility
of every registry -- every zone administrator-- to put only
those labels into the DNS that are consistent with the standards
applicable to those labels.  For ASCII labels intended for
normal (e.g., not SRV) use, that means the LDH rules must be
followed.  For IDNs, it means that anything that looks like an
A-label must be an A-label and that the U-label form not contain
unassigned characters, disallowed characters, or anything that
violates contextual or bidi rules.  

Of course, some zone administrator might choose to violate that
standard.  What will happen to them if they do so is not an IETF
matter, except insofar as standards about lookup (and software
that conforms to those standards) makes the non-compliant names
hard to find.   From an IETF point of view, non-conformant
systems are just outside the standard and it is pointless to try
to make them conformant to some other model of conformance.

FWIW, although the usual qualifications about things being
subject to change apply, the forthcoming version of Protocol
more clearly reflects the above model.

    john