comments on last call drafts
John C Klensin
klensin at jck.com
Sun Oct 25 23:35:27 CET 2009
As with the previous note, commenting only on things not
reflected in the Change Logs (or trivial) and omitting the Bidi
--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
> 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.
> * 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.
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
> * 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
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.
More information about the Idna-update