Remider: BIDI inter-label tests in -02

[Andrew Sullivan]

On Mon, Sep 08, 2008 at 05:57:41PM -0700, Erik van der Poel wrote:
> > but it may entail a pretty significant effect.
> 
> My guess is that you meant "effort" here.

Yes, sorry.

> I still wonder whether it is absolutely necessary for the operator to
> test all possible resolution paths whenever a label is registered or a
> CNAME or DNAME is defined. 

It isn't under the current wording, no.  You'll recall that what I
originally said is that I can live with the "MAY" as Harald has it in
the current draft.  I can live with this mostly because it allows
people to perform minimal tests for the obviously-broken cases, and
yet doesn't require anything more rigorous.  Anything stronger than
MAY would be bad, IMO, because of the reasons I've been arguing.

> What is the actual objection here? Do you object that IDNAbis-aware
> apps would refuse to pre-resolve some U-label FQDNs corresponding to
> A-label FQDNs that otherwise function perfectly within the DNS itself?

As long as the text says, "Here be dragons; be careful, and be
prepared for surprising failures," I'm ok with it.  Anything that
starts to smell like, "You have to prevent these cases," is in my view
impossible to satisfy.

> If so, would you be satisfied if the IDNAbis rule says instead that
> apps are allowed to resolve such FQDNs, but are not allowed to
> *display* them in Unicode (since they are ambiguous and confusing
> according to the bidi draft principles)?

I'm pretty uncomfortable with the IETF getting into trying to specify
what may be displayed by whom under what conditions.  We simply don't
have the user interface expertise around here to do that well.
 
> Either way, I think we need to specify the rules for registration. For

I think we've heard pretty clearly from some larger registry operators
that we'd _better not_ try to specify the rules for registration.  And
if I still were working at a large registry provider, I'd be joining
that chorus.  

> example, we might say that a registrant must specify the entire FQDN
> for the label being registered. Then we might specify that the

So you're saying that if I'm the operator of
some.deep.level.example.com, and I want to accept registrations in my
zone, my registrants have to tell me whether they're registering
<ALEF>.some.deep.level.example.com?  This is either trivially true or
meaningless.  Here's why:

a.  I'm already the authority for some.deep.level.example.com.  So if
someone tells me "register <ALEF>", I already know where it's going to
go.  This is sort of like the $ORIGIN statement in a
presentation-format zone file.

b.  I have no way of enforcing anything about what level.example.com
does.  Maybe it causes a redirection that sets off a chain that will
violate the proposed rule anyway.  (I can't think of a way right now,
but I suspect that's because I haven't thought hard enough about it yet.

c.  I can't do anything about the registrant of
3.some.deep.level.example.com: maybe they'll later register <ALEF>
inside their 3.some.deep.level.example.com.  If they do, of course,
they'll be violating the rule you're proposing.  But that's why this
is meaningless: you can't enforce rules in the zones below you once
you've delegated that zone away.

> operator must attempt to resolve that FQDN, and that if any CNAMEs or
> DNAMEs are encountered along the way, then the registrant's original
> FQDN is "rewritten". When all of the CNAMEs and DNAMEs in a chain have
> been processed, we end up with the final FQDN. At this point, the
> operator must convert to U-labels (if any A-labels appear), and
> perform the bidi test across the entire FQDN. If there is a failure,
> then the operator must report the entire final FQDN to the registrant,
> so that s/he may have some idea of what happened.

There is no way that large TLD operators are going to do that kind of
processing in the 800ms some of them have to register a domain name.  

> > And anyway, as I've already suggested, making the BIDI test mandatory
> > automatically makes wildcards illegal for any domain that starts with
> > a digit.
 
> I suppose wildcards could be prohibited at such sites, 

I think you're going to have a very hard time getting through an IDNA
document that purports to update RFC 1034 or RFC 1035, which is what
you'd have to do to prohibit wildcards in some circumstances.
Moreover, this is sneaking the inter-label test through the back door,
because you're basically making validity rules for one label's values
based on the values of another label.  This would represent a very big
change of principles to the DNS.  

> We cannot change that algorithm, but we might be able to work around
> it using bidi overrides (LRO and RLO), which get rid of the ambiguity.
> I don't know whether the WG members like that idea though. We might
> want to list the pros and cons of such a proposal.

I think it would be interesting to explore this (or be pointed at
previous explorations of it).

A

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