Comments on draft-ietf-idnabis-defs-10

John C Klensin klensin at
Tue Sep 1 02:03:58 CEST 2009

--On Monday, August 31, 2009 14:08 -0400 Andrew Sullivan
<ajs at> wrote:

> 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.

Let me make an extremely tentative suggestion ("tentative" in
the sense that I'm not sure it is right and I'm very easily
persuaded to do something else):

(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

(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.

(e) Go through Protocol and Defs, ideally with Paul's help,
identify all of the places where case-insensitive actions are
taken or specified, and make sure that they don't need tuning or
additional notes.

The terms "note" and "reminder" are explicitly intended to be
flags to help the unwary, i.e., non-normative statements that do
not change the spec.

If that works for folks, I'll sit down with the documents and
try to craft specific text for WG review.


More information about the Idna-update mailing list