protocol-15

[John C Klensin]

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