Subject: [idn] draft-costello-rfc3492bis

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 9 Oct 2003 13:21:48 -0700

Title		: Punycode: A Bootstring encoding of Unicode for
			  Internationalized Domain Names in Applications (IDNA)
	Author(s)	: A. Costello
	Filename	: draft-costello-rfc3492bis-00.txt
	Pages		: 0
	Date		: 2003-10-6

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-costello-rfc3492bis-00.txt

-----

 From the draft:

This document is a revision of RFC 3492.  None of the changes alter
the protocol; that is, any correct implementation of RFC 3492 is
a correct implementation of this document, and vice-versa.  The
changes are as follows:

At the end of section 2 "Terminology", added a statement of
the assumption that all values from zero through maxint can be
represented.  RFC 3492 relied on this assumption without stating it.

In section 5 "Parameter values for Punycode", in the paragraph
following the first list of parameter values, fixed the remark about
code points D800..DFFF, which RFC 3492 claimed were not code points
at all.  Technically they are code points, but they do not occur in
any valid Unicode string.  In the same section, in the paragraph
discussing uppercase and lowercase, clarified that the restrictions
on encoder output apply only to the non-literal portion of the
encoded string.

In sections 6.2 "Decoding procedure" and 6.3 "Encoding procedure",
added statements to emphasize that overflow handling is REQUIRED,
NOT OPTIONAL.

In section 6.4 "Overflow handling", fixed the definition of maxint.
The definition in RFC 3492 was nonsense.

In the first paragraph of section 7.1 "Sample strings", clarified
the significance (or insignificance) of mixed case in the examples.

In section 9.2 "Informative references", alphabetized the
references, and updated the references to [IDNA] and [NAMEPREP].

In appendix C "Punycode sample implementation", fixed and clarified
several comments in the C code, quieted some compiler warnings
caused by implicit type conversion, and changed the interface to use
size_t rather than punycode_uint for array lengths, for consistency
with customs established by the standard C library.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: [email-masked] (Martin v. Löwis)
Date: 17 Oct 2003 00:03:13 +0200

> added statements to emphasize that overflow handling is REQUIRED,

"NOT OPTIONAL" is not a keyword of RFC2119. "OPTIONAL" is, and it is a
synonym of "MAY". The usage of "NOT OPTIONAL" is redundant with the
"MUST".

It's not immediately obvious why some operations (e.g. inside adapt)
don't perform overflow checking, but (without further review) I assume
there is some guarantee that it can't overflow.

Regards,
Martin

---

From: "Adam M. Costello" <[email-masked]>
Date: Fri, 17 Oct 2003 08:42:21 +0000

> synonym of "MAY".  The usage of "NOT OPTIONAL" is redundant with the

Maybe I got carried away with the emphasis.  I wouldn't mind removing
all instances of "NOT OPTIONAL", leaving just "MUST" and "REQUIRED".

> there is some guarantee that it can't overflow.

You raise an interesting question.

In the main encoding and decoding functions, for any values of maxint
and the constants (base, tmin, tmax, etc), you can make overflow happen
by providing a long enough input.

In adapt(), on the other hand, the possibility of overflow can be ruled
out regardless of the input, if the constants aren't too extreme.

adapt() cannot overflow if

    (base - tmin + 1) * ((base - tmin) * tmax) div 2) <= maxint

and

    base * (log(maxint) - log(0.5 * tmax)) / log(base - tmin)
    + base - tmin <= maxint

The former condition can be rewritten to avoid overflow in the condition
itself:

    base - tmin <= ( (maxint div (base - tmin + 1)) * 2 + 1 ) div tmax

This is the first time I've carried the analysis to this level of
detail, so watch out for errors.  (I would welcome independent analyses
for comparison.)

For Punycode, this boils down to maxint >= 16380, and I've never
heard of a platform with maxint smaller than 32767.  For other
parameterizations of Bootstring, it could be more of a concern.  In any
case, those checks can be performed once per platform; there is no need
for a runtime check.

Perhaps the draft should discuss this.

By the way, I just noticed that the conditions on tmin and tmax in
section 4 are insufficient.  It currently says:

    0 <= tmin <= tmax <= base-1

We need to strengthen that in order to avoid infinite loops.

    0 <= tmin <= base-2
    1 <= tmax <= base-1
    tmin <= tmax

I suppose that's a technical change in Bootstring, but it has no effect
on Punycode, whose parameters already obey the stronger constraints.

AMC