vint at google.com
Thu Sep 3 18:54:20 CEST 2009
I think we intended that our definition of A-label excluded presence
of upper case ASCII.
So the presence of such characters makes the object NOT an A-label.
an A-label is a subset of allowed DNS labels (see Non-Reserved LDH-
The labels with the xn--prefix but which contain upper case ASCII
punycode representation of the U-label appears are not A-labels by
any clarification we can manage on this point will likely be helpful.
On Sep 3, 2009, at 11:41 AM, Andrew Sullivan wrote:
> 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
> 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
> Best regards,
> Andrew Sullivan
> ajs at shinkuro.com
> Shinkuro, Inc.
> Idna-update mailing list
> Idna-update at alvestrand.no
More information about the Idna-update