Re: draft-klensin-net-utf8-06

Stephane Bortzmeyer <> Fri, 12 October 2007 17:30 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1IgOLb-0004aN-UL; Fri, 12 Oct 2007 13:30:51 -0400
Received: from discuss by with local (Exim 4.43) id 1IgOLa-0004Wp-MQ for; Fri, 12 Oct 2007 13:30:50 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1IgOLa-0004UT-Bn for; Fri, 12 Oct 2007 13:30:50 -0400
Received: from ([] by with esmtp (Exim 4.43) id 1IgOLR-0006Lg-Hv for; Fri, 12 Oct 2007 13:30:50 -0400
Received: by (Postfix, from userid 10) id 7439F240826; Fri, 12 Oct 2007 18:30:04 +0200 (CEST)
Received: by horcrux (Postfix, from userid 1000) id 4E6B6157D25; Fri, 12 Oct 2007 10:10:17 +0200 (CEST)
Date: Fri, 12 Oct 2007 10:10:18 +0200
From: Stephane Bortzmeyer <>
Subject: Re: draft-klensin-net-utf8-06
Message-ID: <>
References: <93F25E18AB3DA3EB0599F092@p3.JCK.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <93F25E18AB3DA3EB0599F092@p3.JCK.COM>
X-Transport: UUCP rules
X-Operating-System: Ubuntu 7.04 (feisty)
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

On Thu, Oct 11, 2007 at 03:49:22PM -0400,
 John C Klensin <> wrote 
 a message of 66 lines which said:

> I hope we are converging:

My opinion is that, yes, the document is better and more stable than
it was.

I've read and reviewed -06 and I find it suitable for Last Call, with
no serious pending issues.

> (2) There are many ways in which the document could be more or less
> radically reorganized.

The "historical" or "rationale" sentences (such as "In retrospect, one of
the advantages of ASCII [X3.4-1978] when it was chosen was that the
code space was full when the Standard was first published") could
certainly be more separated from the normative text but I do not see
this issue as a serious problem. The text seems clear.

> (8) While a few people advocated it, I can't see making the NFC
> requirement a MUST.  [...] Second, if NFC on sending is a MUST, then
> receivers have the right to expect that they will see only
> NFC-normalized forms on input.  That assumption is dangerous, since,
> in general, there is no way to know whether a sender is following
> this spec.

While I agree with the SHOULD, I do not think the reason given above
is a good one. If we follow it, *all* MUST in RFCs could be changed to
SHOULD, in the name of the robustness principle. 

IMHO, the best reason for keeping the SHOULD ("applications should
send a NFC-normalized stream") is the argument about libraries that
the application does not control.