comments on drafts

[John C Klensin]

Hi.

Same disclaimers as on the previous two notes...

--On Wednesday, October 14, 2009 10:06 +1100 James Mitchell
<james.mitchell at ausregistry.com.au> wrote:

> Comments on draft-ietf-idnabis-defs-11
> 
>    A consequence of the restrictions on valid characters in
> U-labels    turns out to be that mixed-case annotation, of the
> sort outlined in    RFC 3492 Appendix A [RFC3492], 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.
>...

This is a rat's nest.  In retrospect, it probably would have
been wiser to update RFC 3492 to explicitly deprecate Appendix A
and require that lower case strings be produced.  Of course, it
is too late for that now and it still would not have solved the
problem of comparison between A-labels produced under IDNA2008
and ACE forms produced under IDNA2003 in upper case.   I've
applied corrections in the places you identified and hope they
are adequate.

>...
> Comments on draft-ietf-idnabis-protocol-16
> 
>    If the input to this procedure appears to be an A-label
> (i.e., it    starts in "xn--"), the lookup application MAY
> attempt to convert it    to a U-label, first ensuring that the
> A-label is entirely in lower    case, and apply the tests of
> Section 5.4 and the conversion of    Section 5.5 to that form.
> If the label is converted to Unicode    (i.e., to U-label
> form) using the Punycode decoding algorithm, then    the
> processing specified in those two sections MUST be performed,
> and    the label MUST be rejected if the resulting label is
> not identical to    the original.  See Section 8.1 of
> [IDNA2008-Rationale] for additional    discussion on this
> topic.
> 
> The label MUST be rejected is the resulting label does not
> match the original.
> 
> Again, one cannot determine the implementation of punycode
> used to produce the A-label.

The intention of "first ensuring..." was to force that
conversion if necessary.  That has been made explicit.

>...

regards,
   john