Comments on draft-ietf-idnabis-defs-10

[Wil Tan]

On Wed, Sep 2, 2009 at 2:50 AM, Andrew Sullivan <ajs at shinkuro.com> wrote:

> 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.
>
>
I think I'm ok with this. Again, not too concerned about definitions, except
how they are interpreted in the protocol.



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


I'm not that familiar with the practical aspects of rfc2119, so I could well
be wrong. In idnabis-protocol-14, section 5.3 A-label input:

    If the input to this procedure appears to be an A-label (i.e., it
   starts in "xn--"), the lookup application MAY attempt to convert it
   to a U-label and apply the tests of Section 5.4 and the conversion of
   Section 5.5 to that form.

So an application doesn't _have_ to convert it to U-label, and goes ahead to
lookup the domain name. This would be true of non IDNA-aware applications,
as well as conforming IDNA2008 applications that chooses the easy way out
(it just cannot display the label in native form.)

   If the label is converted to Unicode
   (i.e., to U-label form) using the Punycode decoding algorithm, then
   the processing specified in those two sections MUST be performed, and
   the label MUST be rejected if the resulting label is not identical to
   the original.

If an application gets to this stage, it then MUST validate the U-label, and
if there are uppercase characters in there, and MUST refuse the lookup.


(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'm not too worried about that though. IDNA2008 is supposed to work at a
higher level than DNS, keeping constant the DNS underlying case-insensitive
property. As long as the resolver library keeps the original
case-permutations and restores it from the answer as part of the demux step,
all that case-mutilations only happens on the wire, no?



>  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.
>
>
It may just be a case of my not seeing it through the same lenses as you.
Please see my earlier comments.

Thanks.


=wil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20090902/4bc38405/attachment-0001.htm