Subject: [idn] Editorial comments on punycode

From: Erik Nordmark <[email-masked]>
Date: Fri, 3 May 2002 20:59:05 +0200 (CEST)

draft-ietf-idn-punycode-01.txt
------------------------------

I've reviewed the punycode document to make sure it is
ready for IETF last call.

Here are some editorial comments that it would be useful to
fix before the last call.

Overall the document looks very good.

The introduction of "bootstring" in the abstract is a bit odd - almost
made me look for bootstring in the references section.
Saying "This document defines bootstring as a general algorithm ..."
is more clear.

Section 4 talks about mixed-case annotations but it hasn't been mentioned
earlier in the document - a bit surprising to the reader. Thus it would be 
good to introduce this optional possibility earlier in the
document. E.g. in section 1.2 stating that this optional capability
exists in the algorithm but that it isn't needed for IDNA.

Section 6.2 says at the end what the decoder need not re-encode its output.
Why would it ever need that? I think there is some context missing but I
can't guess what that context is.

Section 6.3 talks about overflow - but is the information in that paragraph
common to the decoder and encoder? (The text lives only in the encoder 
section.) If not what are the size requirements for the integer data type
for the decoder?

Section 7.1 talks about "the IDNA signature prefix" but the IDNA
spec uses the term "ACE prefix".

Split normative vs. non-normative references.

---

---

From: "Adam M. Costello" <[email-masked]>
Date: Fri, 24 May 2002 21:30:44 +0000

The changes from Punycode draft 01 to 02 are all editorial, not
technical.  Almost all were motivated by Erik Nordmark's comments, shown
below.

> made me look for bootstring in the references section.

Fixed.

> Section 4 talks about mixed-case annotations but it hasn't been
> mentioned earlier in the document

It was mentioned at the end of section 1.1, but not described at all.
Now it is briefly described there.

> Section 6.2 says at the end what the decoder need not re-encode its
> output.  Why would it ever need that?

That is now explained.

> Section 6.3 talks about overflow - but is the information in that
> paragraph common to the decoder and encoder? (The text lives only in
> the encoder section.)

Yes.  That information has been relocated to section 6.4 "Overflow
handling".

> spec uses the term "ACE prefix".

Fixed.

> Split normative vs. non-normative references.

All references are non-normative, and the section title now reflects
that.

Additional changes:  A reference to ASCII has been added (RFC 20).  The
description of example S has been fixed to remove an erroneous claim
that it breaks the rules of Nameprep.

AMC