Comments on draft-ietf-idnabis-defs-10

[Vint Cerf]

andrew,

can it be argued that the only way a domain name containing an xn- 
label could be formally registered in the DNS with upper case ASCII  
present would be through violation of the IDNA2008 protocol specs? In  
a strange way, while one would actually find and match such a domain  
name because of DNS rules, that object, if returned with its upper  
case components, would fail to convert to a proper U-label. Somewhere  
in here we might want to say that such an object (an A-label with  
upper ascii characters in it MUST not be registered).

does that help? we already say something like that by definitions I  
think.

v

On Aug 31, 2009, at 2:08 PM, Andrew Sullivan wrote:

> On Mon, Aug 31, 2009 at 10:58:53AM -0700, Paul Hoffman wrote:
>
>> Andrew, a developer who actually read the Punycode RFC, missed the  
>> subtlety.
>>
>> Wil alerted the list months ago, and all of us still missed this  
>> subtlety.
>>
>> It would be an act of absurd optimism to think that developers will
>> get this without us being very explicit in both documents about what
>> we mean.
>
> In my case, it's actually worse: I waded into the thread Wil started
> months ago precisely because I was worried about what he was raising &
> wanted to avoid having it conflated with another, unrelated problem.
> Alas, I think I contributed to the confusion instead of keeping the
> discussion focussed.  But I still missed this in my review, much to my
> embarrassment.
>
> Therefore, I do think we need to make this issue completely plain, but
> I am also still not sure whether there is anything to change here.  If
> I understand the situation correctly, there is no such thing as an
> A-label that includes an upper-case ASCII character.  This is because
> A-labels are defined in terms of being convertible to and from
> U-labels, and there's no such thing as a valid U-label that includes
> those upper case characters.
>
> Now, there's an interesting upshot of all this, and that is that every
> A-label also compares as equivalent to some number of R-LDH labels;
> the resulting set of labels is every permutation of the A-label in
> question with the ASCII-range characters uppercased.  None of those
> labels are A-labels, because they don't obey the restriction that they
> can be produced by conversion from a U-label (because no U-label may
> contain such characters).  So far, however, this sounds to me like a
> note that ought to be highlighted, but not a formal part of the
> definitions or protocol.  I'm still open to persuasion otherwise.
>
> A
>
> -- 
> Andrew Sullivan
> ajs at shinkuro.com
> Shinkuro, Inc.
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update