Comments on draft-ietf-idnabis-defs-10
John C Klensin
klensin at jck.com
Tue Sep 1 05:53:25 CEST 2009
--On Tuesday, September 01, 2009 10:17 +1000 James Mitchell
<james.mitchell at ausregistry.com.au> wrote:
>> (1) Insert a note into Defs that explicitly points out that no
>> valid A-label can contain any upper case characters (at least
>> after the "xn" -- does the WG have a preference about the
> XN--KGBECHTV is a valid A-label;
No. Because it cannot be produced by the defined transformation
from a U-label, it is not. The difference between it an a valid
A-label is harmless, and both translate back to exactly the same
U-label, but that doesn't make it a valid A-label.
The distinction is more useful than the one I think you are
proposing because yours, with its special rule about Latin
characters, is a little too subtle. And subtlety leads to bad
implementations, at least in my experience. YMMD.
> xn--Bcher-kva is not.
It is not either for the same reason (generation from a
U-label). By contrast, you think it not that is only because of
the ASCII character relationship, which is what I think is too
subtle to make a good rule.
> behaviour is only with the ASCII characters which are not
> encoded/decoded as part of the punycode algorithm.
>> (2) In Protocol, put in reminders in the Punycode invocation
>> steps that indicate that, since the U-label cannot contain
>> upper case characters, the A-labels that come out will be all
>> lower case and that looking up an A-label that contains upper
>> case characters is non-conforming and may produce surprising
> xn--Bcher-kva is not an A-label, however do not think that
> looking it up will produce surprising results. Non-IDN domain
> names are case-insensitive, IDNA2003 case-folded, and we have
> a mappings document that recommends that characters are
But that is not required.
> I thought the issue was the symmetry of XN-labels.
> XN--BCHER-KVA, whilst equivalent in the DNS, is not equivalent
> in IDNA2008 because they produce different Unicode strings.
> Perhaps something along the lines of 'If one has an XN-label
> and wants a putative A-label then they must first lowercase.'
> is all that is needed?
That is one way of doing it, and what was suggested early on.
But it has the effect of requiring a mapping and significantly
weakening the clarity of the A-label definition and the U-label
<-> A-label relationship.
More information about the Idna-update