protocol-15

Andrew Sullivan ajs at shinkuro.com
Thu Sep 3 17:41:22 CEST 2009


Dear colleagues,

I have reviewed the changes in draft-ietf-idnabis-protocol-15.  I
think we have closed the gap about which we were worried, but I want
to confirm we've got it quite right.

Protocol-15 does not actually forbid the registration of A-labels
containing upper case ASCII characters.  Section 4.1 says that
registries sSHOULD accept registrations onlt for A-labels (with maybe
some related U-labels).  Section 4.2.1 is a little more encouraging of
accepting the U-label form as well, but still regards the A-label form
as primary.  However, it only requires the downcasing of the A-label
form in case both forms are available; otherwise, if the A-label form
is accepted at all it is apparently accepted as provided.

Protocol-15 does not actually forbid the lookup of A-labels containing
upper case ASCII characters.  Section 5.3 says that if the input
starts with xn--, then the application MAY do some conversion
(although it now specifies that the conversion should start by
downcasing the entire A-label).  The document is entirely silent on
what an application does with an A-label in case it does not convert
the label to a U-label for validation, &c.

As John suggested in the discussion leading up to this, I think the
above is correct: A-labels are, in one sense, just plain DNS names,
and I am pretty sure we don't want to be making changes to the rules
about what may be entered or looked up in the DNS in every case.
Nevertheless, since this is what people were worried about, I want to
draw attention to it.

Given the results of the previous discussion, I'm still fairly certain
that the existing definitions prohibit A-labels that have any upper
case letter in them.  But I concede that this depends on certain
non-obvious premises, and therefore an implementer who really wanted
to get upper case ASCII into an apparent A-label would have an
argument that they were conforming with the protocol as it stands.  I
therefore think it would be nice to add a sentence to Defs that
reminds the reader that A-labels turn out always to be lower case,
(maybe it ought to go in Rationale instead).  My suggestion is
something like the following: "A consequence of the restrictions on
valid characters in U-labels turns out to be that mixed-case
annotation, of the sort outlined in [RFC3492] Appendix A, is never
useful.  Therefore, since a valid A-label is the result of Punycode
encoding of a U-label, A-labels always happen to be only lower case,
despite matching other (mixed- or upper-case) potential labels in the
DNS."

In any case, I think the changes made to Protocol are all that are
needed for the purposes of addressing the issue of upper case in the
A-label.

Best regards,

A

-- 
Andrew Sullivan
ajs at shinkuro.com
Shinkuro, Inc.


More information about the Idna-update mailing list