Subject: [idn] IDN WG Last Call: draft-ietf-idn-punycode-00.txt

From: Marc Blanchet <[email-masked]>
Date: Mon, 28 Jan 2002 12:06:15 -0500

Title: Punycode version 0.3.3

Abstract:
Punycode is a simple and efficient encoding designed for use with
Internationalized Domain Names [IDN] [IDNA].  It uniquely and
reversibly transforms a Unicode string [UNICODE] into an ASCII
string.  ASCII characters in the Unicode string are represented
literally, and non-ASCII characters are represented by ASCII
characters that are allowed in hostname labels (letters, digits,
and hyphens).  Bootstring is a general algorithm that allows a
string of basic code points to uniquely represent any string of code
points drawn from a larger set.  Punycode is an instance Bootstring
that uses particular parameter values appropriate for IDNA.  This
document specifies Bootstring and the parameter values for Punycode.

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

This two weeks WG last call ends Feb 11th 2002, 23h59 GMT-5.

This document is for standards track.

The co-chairs see a wg rough concensus on this document.
Please send any proposed modification of the text to the wg mailing list as
well as to the wg co-chairs, stating clearly the text to be modified and
the new text.

Marc & James

---

From: "Mark Davis \(jtcsv\)" <[email-masked]>
Date: Tue, 29 Jan 2002 08:19:51 -0800

The decoding process is a bit hard to follow. I would recommend adding
some annotated examples of decoding to Punycode in a section 7.1 and
referencing them from the text. E.g.
...
3. Bootstring description

    Bootstring represents an arbitrary sequence of code points (the
    "extended string") as a sequence of basic code points (the
    "basic string").  This section describes the representation.
    Section 6 "Bootstring algorithms" presents the algorithms as
    pseudocode. [[[Section 7.1 "Annotated Decoding Examples"
    provides some examples of the decoding process which may
    be useful in understanding the following text.]]]
...

...
7.1 Annotated Decoding Examples
The following provides two examples of the decoding process. One
example contains mostly ASCII letters with a few accented characters,
while the other has only non-ASCII characters:

[[[The deltas are just pulled out of a hat for illustration; you'd run
your program to generate them.]]]

1. "Proprostnemluvesky-uyb24dma41a"

Since there is a delimiter, the basic string consists of:
  "Proprostnemluvesky"
and the delta codes are:
  "uyb24dma41a"
The delta codes provide instructions on where to insert other
characters in the stream.
The first delta is contained in "uy", and produces the number +YYYY
It inserts <ccaron> = U+XXXX at position 3, giving:
  "Pro<ccaron>prostnemluvesky"
[[[insert the rest of the steps]]]
The final result is:
  "Pro<ccaron>prost<ecaron>nemluv<iacute><ccaron>esky"

2. "ihqwcrb4cv8a8dqg056pqjye"

Since there is no delimiter, the basic codes are empty to start with,
and the entire encoded string consists of deltas.
The first delta is contained in "ih", and produces the number +XXXX.
It inserts <4ED6> at the start, giving:
 <4ED6>
[[[insert the rest of the steps]]]
The final result is:
<4ED6><4EEC><4E3A><4EC0><4E48><4E0D><8BF4><4E2D><6587>

Mark

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 29 Jan 2002 13:20:02 -0500

An editorial comment: would it be possible to capitalize instances of the
RFC 2119 directives "must", "may", "should", etc.?  Doing so will make it
far easier for implementers to not miss something that might come back to
bite them later.

-Scott-

---

From: "xiang deng" <[email-masked]>
Date: Wed, 30 Jan 2002 10:53:33 +0800

----- Original Message ----- 
From: "Mark Davis (jtcsv)" <[email-masked]>
> <4ED6><4EEC><4E3A><4EC0><4E48><4E0D><8BF4><4E2D><6587>

The final result is:
<4e16><754c><62e5><6709><4e0d><540c><7684><6c11><65cf><3001><6587><5316><3001><5386><53f2><ff0c><624d><663e><5f97><751f><52a8><53ef><7231>
<5f7c><6b64><5c0a><91cd><3001><76f8><4e92><5e2e><52a9><3001><5145><6ee1><4ec1><7231><ff0c><4e16><754c><624d><6709><660e><5929><7684><7f8e><597d><4e0e><548c><5e73>

Deng xiang

---

From: "Adam M. Costello" <[email-masked]>
Date: Wed, 30 Jan 2002 04:31:02 +0000

"Hollenbeck, Scott" <[email-masked]> wrote:

> An editorial comment: would it be possible to capitalize instances of
> the RFC 2119 directives "must", "may", "should", etc.?

It would certainly be *possible*.  :)

> Doing so will make it far easier for implementers to not miss
> something that might come back to bite them later.

I remain skeptical of that claim.  I personally find the all-caps MUST
SHOULD etc. to be distracting and not at all helpful.

If the group demands this then I'll write an awk script to take care of
it, but I'd rather not.

"Mark Davis (jtcsv)" <[email-masked]> wrote:

> I would recommend adding some annotated examples of decoding to
> Punycode in a section 7.1 and referencing them from the text.

Good idea.

AMC

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 30 Jan 2002 13:30:24 +0100 (CET)

> If the group demands this then I'll write an awk script to take care of

I think the RFC 2119 upper case terms are more exact and allows
distinguishing between regular english use of these terms, such as
"an implementor should consider the performance ...", and
rather exact statements about the requirement levels in the specification.

Thus it shouldn't be a search and replace everything with upper case.

Also, there appears to be "should not" even though the "not" terms are not
listed in the 2119 referencing text.

  Erik

---

From: "Adam M. Costello" <[email-masked]>
Date: Wed, 30 Jan 2002 21:42:49 +0000

Erik Nordmark <[email-masked]> wrote:

> distinguishing between regular english use of these terms, such as "an
> implementor should consider the performance ...", and rather exact
> statements about the requirement levels in the specification.

That's one of the reasons I don't like capitalizing those words.  What
if I'm reading a spec in which "must" is usually capitalized, but in one
sentence it is lowercase.  Am I required to obey that sentence or not?
At that point I think we're making distinctions that don't exist.

> Thus it shouldn't be a search and replace everything with upper case.

If I were persuaded to capitalize those words, I would manually check
each instance, and if it shouldn't be capitalized, I'd reword the
sentence to avoid that word altogether.  So in the end, those words
would be capitalized everywhere they appear.  Then I'd keep my master
copy uncapitalized and unpaginated, and use a script to add the
capitalization, pagination, and internet-draft/RFC boilerplate.

> Also, there appears to be "should not" even though the "not" terms are
> not listed in the 2119 referencing text.

Thanks, I'll revise the list of terms to match RFC 2119.

AMC

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 30 Jan 2002 14:36:30 -0800

>At that point I think we're making distinctions that don't exist.

Yes.  "MUST" and "must" are equivalent.  Where one intends
another meaning than that defined by RFC 2119, one should
use a different word.

IMO, it's good to uppercase these imperatives so that
cases where an imperative was used unintentionally are easily
noticed and corrected during the editing and review process.

Kurt

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 31 Jan 2002 08:20:19 +0100

> another meaning than that defined by RFC 2119, one should

Actually, in the IESG we have the policy of treating all-caps versions of
the words exactly like defined in RFC 2119, and lowercase as "information
to the reader".

So, what Scott explained is not uncommon.

Of course, if one can choose other words for non-normative use of the terms
that is better, but, that is not always possible.

I therefore suggest using all-caps for the terms that is to be treated as
defined in 2119.

   paf

---

From: "Adam M. Costello" <[email-masked]>
Date: Thu, 31 Jan 2002 21:27:39 +0000

Am I the only one who prefers must/should/etc. over MUST/SHOULD/etc?  If
there is anyone else, please speak up now.

If there is no rough consensus, I can only use my own best judgement,
but if everyone agrees except me, I'll go along.  (This pertains to the
Punycode draft).

AMC

---

From: Rick H Wesson <[email-masked]>
Date: Thu, 31 Jan 2002 13:39:41 -0800 (PST)

As an implementor I also prefer MUST/SHOULD/etc verses the lower case
equivalents.

-rick

---

From: Dave Crocker <[email-masked]>
Date: Thu, 31 Jan 2002 13:40:03 -0800

>If there is no rough consensus, I can only use my own best judgement,

or you could take the safest path.

This means limiting the use of those words to only normative references, 
and use other vocabulary for other purposes.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

---

From: "Adam M. Costello" <[email-masked]>
Date: Thu, 31 Jan 2002 22:05:51 +0000

Dave Crocker <[email-masked]> wrote:

> This means limiting the use of those words to only normative
> references, and use other vocabulary for other purposes.

I will do that in any case.  The question is whether those words will be
all-caps or not.

AMC

---

From: Dave Crocker <[email-masked]>
Date: Thu, 31 Jan 2002 15:18:26 -0800

>I will do that in any case.  The question is whether those words will be

all-caps is the standard practise in the IETF.

d/

----------

---

From: "Adam M. Costello" <[email-masked]>
Date: Thu, 31 Jan 2002 22:05:51 +0000

AMC

---

From: Dave Crocker <[email-masked]>
Date: Thu, 31 Jan 2002 13:40:03 -0800

d/

----------

---

From: Rick H Wesson <[email-masked]>
Date: Thu, 31 Jan 2002 13:39:41 -0800 (PST)

-rick

---

From: "Adam M. Costello" <[email-masked]>
Date: Thu, 31 Jan 2002 21:27:39 +0000

AMC

---

From: Dave Crocker <[email-masked]>
Date: Thu, 31 Jan 2002 15:18:26 -0800

d/

----------