Comments on draft-ietf-idnabis-defs-10

[Andrew Sullivan]

On Wed, Sep 02, 2009 at 02:30:08AM +1000, Wil Tan wrote:
> >
> Agreed. I'm not actually advocating special rules for A-label matching, just
> pointing an inconsistency where label1 is a valid A-label, and is equivalent
> to label2 which is an invalid A-label.

Yes, this is a strange property of A-labels, but it's ok: A-labels are
a subset of LDH-labels.  Until you drew attention to this, it wasn't
obvious to me that even if different LDH-labels matched, one of them
being an A-label was not enough to make the rest of them A-labels.
It's still ok, but it is a subtle point, and the sort of sharp corner
that can snag when people implement for sure.

> If the A-label qualification is just a definition, it wouldn't matter much.
> But it's how we define registration and lookup behavior where A-label is
> concerned that I'm afraid this could cause unintended consequences in
> software implementations.
> 
> As it is currently defined, IDNA2008 protocol allows a conforming
> applications to behave in different ways (even without mapping).

This is exactly what I am denying.  I think that the definitions are
complete enough that truly conforming applications will never have
this situation.  (There is, however, a nasty corner case as a result
of the 0x20 stratagy: as currently defined, no IDNA2008 domain is
compatible with the 0x20 strategy, which is an important thing for
DNSEXT to hear.)  Of course, it is quite likely that, working from the
current text, an implementation might not be "truly conforming",
because this subtle point (matching LDH-labels, one of which is an
A-label, need not all be A-labels) could get overlooked.  I claim that
conforming applications won't behave in different ways because upper
case ASCII characters turn out not to be allowed in A-labels.  That's
pretty amazing, but it appears to be true.

A

-- 
Andrew Sullivan
ajs at shinkuro.com
Shinkuro, Inc.