Remider: BIDI inter-label tests in -02

[Alireza Saleh]

Andrew Sullivan wrote:
> 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.").  
>   
Do you think that for example, if I have x.y.com CNAME xn--mgb.3.com 
<ALEF.3.com>, the x.y.com will not resolve according to the current bidi 
draft ?
> 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
>
>   

Alireza