Lookup for reserved LDH labels
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
> 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