protocol-15
John C Klensin
klensin at jck.com
Thu Sep 3 19:39:34 CEST 2009
--On Thursday, September 03, 2009 12:54 -0400 Vint Cerf
<vint at google.com> wrote:
> Andrew,
>
> 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- labels).
> The labels with the xn--prefix but which contain upper case
> ASCII where the
> punycode representation of the U-label appears are not
> A-labels by definition.
Vint,
I think there is an edge case that Andrew's proposed clarifying
note --and I take it as a clarifying note, not a change--
addresses. ACE-like strings that contain upper case characters
that, when converted back to Unicode form, would produce, given
the now famous Appendix A, upper case _ASCII_ (undecorated basic
Latin) characters are clearly problematic and clearly (at least
IMO) not A-labels. But reasonable people can read RFC 3492 as
allowing a result of all-upper-case ACE strings even when the
input is unambiguously a U-label (i.e., no upper case or other
DISALLOWED characters). I cannot read it that way, but
apparently others disagree. Those strings are essentially
harmless as far as the DNS is concerned because they will be
subjected to case-insensitive matching. They are even harmless
as far as conversion back to Unicode is concerned _as long as
they don't contain any ASCII characters_. But, if they are
[valid] A-labels, their presence implies that comparisons
between A-labels must be made in an ASCII-case-insensitive way
even though comparisons between U-labels can be made on a
bit-string-identity basis.
I think we are headed toward clarifying that they are not valid
as A-labels, thereby restricting A-labels to lower case. In a
more perfect world, I would go so far as to deprecate Appendix A
of RFC 3492, but "deprecate" not in the standards sense of
"declare obsolete and prohibit" but in the more conventional
meaning that is roughly equivalent to "call it a lot of bad
names". However, not only would doing so involve us in a
time-wasting discussion involving protocol- and
charter-lawyering, but it is unnecessary: the first paragraph of
Appendix A pretty clearly separates that idea from IDNA, even
the revised version of IDNA.
> any clarification we can manage on this point will likely be
> helpful.
Indeed.
john
More information about the Idna-update
mailing list