comments on last call drafts

[John C Klensin]

As with the previous note, commenting only on things not
reflected in the Change Logs (or trivial) and omitting the Bidi
comments...

--On Tuesday, October 13, 2009 14:41 -0400 Dan Winship
<dan.winship at gmail.com> wrote:

>...
>   * 2.3.1:
> 
>         That subset is called 'XN-labels' in this set of
> documents.
> 
>     The term gets imported into rationale-13, but it is not
> actually     really *used* anywhere outside the defs document.
> Grepping for     "xn--" shows some places that definitely
> could be using it.

This is the sort of editorial change I'm very reluctant to make
at this late stage.   The terminology has been changed too many
times and I'm afraid of accidental side-effects.   Please try to
remind me, if needed, when we produce Draft Standard versions of
these documents.  Of course, I'm mentioning it here in case the
WG or IESG feel strongly about the issue.

> rationale-13:
> 
>   * 7.4 (The Question of Prefix Changes) and its subsections
> are still     worded as though IDNA2008 was a work in
> progress. Eg:
> 
>         An IDNA upgrade would require a prefix change if...
> [t]he         conversion of an A-label to Unicode (i.e., a
> U-label) yields         one string under IDNA2003 (RFC3490)
> and a different string         under IDNA2008.
> 
>     If the (current) goal of the section is to document the
> sorts of     changes from IDNA2003 that *would have* required
> a prefix change,     then it should be more past-tense-y. If
> the goal is to document     the sorts of possible changes that
> might require a prefix change     *in the future*, then it
> should contrast IDNA2008 with that future     spec, not
> IDNA2003 vs IDNA2008.

Changed tense.  I'm not completely sure that is the right fix
(there is, indeed, some desire to give guidance to future
versions and considerations), but, given that the document is
not normative, maybe that is close enough.  I hope I've gotten
it right, but it should be close enough that any loose ends can
be sorted out with the RFC Editor.

> protocol-16:
>...

I've made some of your suggested changes to Protocol, but others
fall into the editorial and terminology category mentioned above.


>   * 3.1. (Requirements) forbids putting a U-label into an
> IDN-unaware     slot, but doesn't say what an app needing to
> convert a U-label to     an A-label actually *can* do in this
> case, since there is no     protocol for converting a U-label
> that you are neither registering     nor looking up.
> 
>     I'm assuming you're supposed to use the lookup protocol,
> minus the     actual DNS lookup step, but nothing anywhere
> actually says that     you can/should do that. (Maybe there
> are security issues with     handing an A-label to an
> IDN-unaware app that might warrant     additional checks
> beyond the lookup case?)

Yes.  There might be such issues depending on the specific
application.  I tried to figure out what to say about this, but
there are just too many cases and situations.  A little earlier
in the process, I might have suggested adding more non-normative
text to Rationale to discuss the "not going to be looked up" (or
registered) cases, but I think that, at this stage, the right
thing to do is to leave the situation open and suggest that
protocols and situations that intend to use non-ASCII character
strings have to specify how to use them and what they mean.
That approach is, I think, consistent with the discussions in
RFCs 2181 and 4343.  If the WG or IESG strongly disagree, it
will obviously need to be fixed, but I contemplate a lot of work
and disagreements.

>...
>   * 4.2.4. (Registration Validation Summary) shouldn't really
> be     called a "summary", since it introduces two new
> restrictions not     previously mentioned ("at least one
> non-ASCII character" and "63     or fewer characters long in
> ACE form"). Also, I think the     reference to Section 4.2
> should be to Section 4.2.3? (Otherwise     you get infinite
> recursion...)

I changed "Summary" to "Requirements" and fixed the reference.
This is exactly why I'm reluctant to make small changes to
terminology or document organization.


>   * 4.4 Punycode Conversion:
> 
>         The failure conditions identified in the Punycode
> encoding         procedure cannot occur if the input is a
> U-label as determined         by the steps above.
> 
>     But "the steps above" require running the Punycode encoding
>     procedure on the putative U-label to determine its length
> when ACE     encoded, so you won't know if it's a real U-label
> until after     running Punycode and possibly overflowing. So
> if this sentence was     meant to imply that you don't need to
> check for overflow, then     it's wrong (and if it's not meant
> to imply that, then it's     misleading.)

Sigh.  Back when we had a 63-octet limit on U-labels, overflow
was not possible.  We removed that limit and no one thought to
check this.  Have restructured the sentence.

>...

   john