Remider: BIDI inter-label tests in -02

[Andrew Sullivan]

Dear colleagues,

This is probably rambling.  I'm still trying to make clear the problem
I've been picking at since Dublin.

On Fri, Sep 05, 2008 at 11:15:51AM +0200, Harald Alvestrand wrote:

> (As a personal preference, I would prefer to make it a SHOULD, or even a 
> "MUST if the following label is known by the BIDI test" - but that did 
> not seem to be the WG's consensus in Dublin, so that's not what the text 
> says).

I oppose very strongly anything stronger that MAY.  The basic problem
is that the BIDI test as it stands is not restricted to application
space -- that is, it's not out in the area where DNS doesn't need to
care.  

The current protocol document has the BIDI test happening at
registration time.  Now, if what we claim is that a zone operator MUST
NOT register a label that violates the principle in the current text,
then what we are requiring is that the operator test all possible
resolution paths for the label.  This could be quite a serious
checking burden -- particularly when one considers that one presumably
ought to check against future conversion of the parent name to a DNAME,
which creates a new path that one didn't have when one did the
checking.  Since we haven't invented a mechanism by which to tell the
parent operator, "Hey, I got a BIDI down here!  Don't screw up!" we
can't really perform such a check.  Therefore, this registration check
is a hedge, but not an assurance, about the validity of the entire
FQDN.  The DNAME example isn't just hypothesizing, either, since many
operators seem to be planning to do "variant" work with various DNAME
tricks.

Worse, the _other_ thing that the protocol document currently says is
that the BIDI rules SHOULD be applied at resolution time.  What an
inter-label validity check does is invent a whole new category: the
"validity" or "invalidity" of a FQDN, where that (in)validity comes
not from some property of some label, but from an emergent property
of the combined labels at a given moment in time.  Again, remember, it
is trivial to introduce a problem here with a DNAME.  If I were the
registrant of alephnull.com (it's a real name -- I just checked), I
might be very tempted in future to make it a DNAME for <ALEF>-0.com.
But this could easily create problems, and problems that would be
obvious nowhere at the level where a DNS operator will look.  (If the
answer is, "well, then, we need to specify that here", then I'll point
out that you are thereby committing yourself to updating DNAME at the
very least.)

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.").  

Now, maybe all of this is just the unfortunate use of the word
"resolution" in the protocol document, and maybe that's actually what
needs to change.  It seems to me, after all, that what protocol is
talking about is neither registration nor resolution, but
pre-registration and pre-resolution.  It's like a filter that goes on
before you get to the resolver.  I imagine the IDNA application calls
getidnbyname().  That is a bunch of rules that performs preprocessing,
makes decisions, and then either errors or hands on to
gethostbyname(), which then does the usual DNS handling.  In case of
an error, there are two possible kinds: IDN errors and DNS errors.
The former aren't even related to the latter in a strict sense: DNS
error codes are only ever going to be for things that reach the DNS itself.

If we adopted that sort of language, I'd probably be a lot more
comfortable.  But I don't think that's the way the documents are
currently expressed (even if it's what's intended).  Until we get
close to something like that, I have to oppose recommendation or
requirement of any inter-label checking.

A

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