Comments on draft-ietf-idnabis-defs-10

[John C Klensin]

--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
> documents.
> 
> 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
normative, references).

The text that follows is similarly careful and oblique about the
prefix.

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
	documents.
	
If anyone thinks that would be even a slight improvement, it
would only take me a few seconds to patch it in.

    john