Lookup for reserved LDH labels

Simon Josefsson simon at josefsson.org
Thu Nov 8 10:20:20 CET 2012

Andrew Sullivan <ajs at anvilwalrusden.com> writes:

> On Wed, Nov 07, 2012 at 09:51:05AM +0100, Simon Josefsson wrote:
>> The problem is that any implementation that takes an all-ASCII string
>> (like "foo" or "ad-acta") and follows the steps in section 5 of RFC 5891
>> will (if the string is permitted for lookup) end up in a punycode
>> encoded string.  For example, the input "foo" will be converted into
>> "xn--foo-".
> I don't believe this is true.  You're only supposed to do the
> processing on A-labels (or putative A-labels).

According to what text?  Section 5.5 says:

   The string that has now been validated for lookup is converted to ACE
   form by applying the Punycode algorithm to the string and then adding
   the ACE prefix ("xn--").

If "ad--acta" is subject to other processing in section, it seems it
would be the subject of processing of section 5.5 as well.

> Your examples are just LDH-labels, and they shouldn't get processed.

According to my understanding of what John said (which I admit does not
match my understanding of the specs), the rest of section 5 applies to
those strings too.

>> To avoid this problem, I suspect implementers typically check whether
>> the input is all ascii before proceeding with the section 5 stuff.  This
>> has a side effect that your string will be permitted.
> It might be that they're checking for "all ASCII", but that's probably
> not quite right.  They should be checking for NR-LDH or Non-LDH, I
> guess, and making a decision on that basis.
> I'm not too keen on your proposed text.  What about instead, in 5.1,
> the following:
>     If the string is an NR-LDH label, it proceeds directly to DNS Name
>     Resolution (see Section 5.6).

Interesting, this would have the effect of permitting lookup of
"ad--acta", right?  I like this wording, but it doesn't seem to match
what others have said earlier here.


More information about the Idna-update mailing list