Comments on draft-ietf-idnabis-defs-10

[John C Klensin]

--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
>> prefix?)
> 
> 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.

>  This
> 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
>> results.
> 
> 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
> case-folded. 

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.

     john