Comments on draft-ietf-idnabis-defs-10
John C Klensin
klensin at jck.com
Thu Sep 3 20:15:40 CEST 2009
--On Thursday, September 03, 2009 06:56 -0700 Paul Hoffman
<phoffman at imc.org> wrote:
> At 9:23 PM -0400 9/2/09, Vint Cerf wrote:
>> as far as I am aware, we have not modified punycode algorithm
>> in any way.
> At 9:24 PM -0400 9/2/09, John C Klensin wrote:
>> I believe that it doesn't. It restricts the input to Punycode
>> but, so, albeit differently, do ToASCII and ToUnicode. Do you
>> see it doing anything else?
> Section 4.4 says:
> This document updates RFC 3492
> only to the extent of replacing the reference to the
> discussion of the ACE prefix. The ACE prefix is now
> specified in this document rather than as part of RFC 3490
> or Nameprep [RFC3491] but is the same in both sets of
> That's why I put the smiley: it does modify it, explicitly,
> but not in a noticable way.
Well, 3492 doesn't specify the prefix. It just refers to one,
by reference and usually in oblique ways. The first paragraph
of the introduction describes an ACE but describes the ACE as
consisting of a prefix followed by the Punycode-encoded string.
That makes it fairly clear to me that "Punycode" doesn't include
the prefix itself. The references to 3490 and 3491 are at the
end of that paragraph and just says "For the details of the
prefix and constraints, see [IDNA] and [NAMEPREP].", a sentence
that, in context, cannot possibly be interpreted as normative
(and, indeed, those two RFCs are listed as informative, not
The text that follows is similarly careful and oblique about the
However, if anyone really wants to engage in nit-picking about
this (and I don't think you, Paul, do), the paragraph quoted
could be changed to:
This document does not update or alter the Punycode
algorithm specified in [RFC3492] in any way. That
document does make a non-normative reference to the
information about the value and construction of the ACE
prefix that appears "in RFC 3490 or Nameprep [RFC3491]".
For consistency and reader convenience, IDNA2008
effectively updates that reference to point to this
document. That change does not alter the prefix itself.
The prefix, "xn--", is the same in both sets of
If anyone thinks that would be even a slight improvement, it
would only take me a few seconds to patch it in.
More information about the Idna-update