Remider: BIDI inter-label tests in -02

[Erik van der Poel]

On Fri, Sep 5, 2008 at 3:12 PM, Andrew Sullivan <ajs at commandprompt.com> wrote:
> Moreover, we have a similar issue in the presence of wildcards.  If
> there's a wildcard at 3.com, then <ALEF>.3.com ought to be valid.  But
> according to this test, it won't be.  Why not?  certainly not because
> of any property of <ALEF>.  And not because of any property of 3.com
> either.  What we're really doing is inserting a new rule that doesn't
> match step 3 in section 4.3.2 of RFC 1034 (that's the one that starts
> "Start matching down, label by label, in the zone.").

I don't think that's what was intended by the IDNAbis bidi draft. The
software that implements that section of RFC 1034 is not expected to
perform any IDNA processing.

In other words, I think you've hit the nail right on the head: The
IDNA drafts are referring to a separate process that occurs *prior to*
those steps of RFC 1034. I rather like your new term "pre-resolution".
It makes it clear that the IDNA process is separate from and prior to
the actual DNS resolution, which, as you say, is the established term
in that world.

By the way, most of the open source pre-resolvers and resolvers are
implemented as separate procedures already. For example, the GNU
libidn library only takes care of the IDNA part, while gethostbyname()
takes care of the DNS part.

If a registrant registers a label that does not violate the IDNAbis
bidi rules (using the normal parent and parent's parent and so on) and
if an HTML document then refers to an FQDN consisting of that label
and the rest of the labels, then we have started off with a perfectly
legitimate situation.

Later, if someone specifies a DNAME for any part of that FQDN, we
still don't have any immediate problem. It is only when e.g. some
other HTML document starts to refer to a *different* FQDN that is
comprised of pieces that *would* resolve in DNS space via DNAME but do
*not* obey the IDNAbis bidi rules that we start to have a problem.

The original FQDN in the original HTML document is still valid
according to the IDNAbis bidi rules, and of course, it still works in
DNS too.

In other words, people will have to be careful with DNAMEs and FQDN
generation. If, say, a Web site is implemented as a set of HTML
templates that are used to automatically generate the final HTML using
FQDNs generated from old sub-trees and new DNAME targets, we could
easily end up with FQDNs that do not obey the IDNAbis rules, hence
leading to lookup or display failures. It may be easier to detect such
problems if they lead to lookup failures, since display failures might
not be noticed as quickly.

Erik