Re: draft-klensin-unicode-escapes-05 and draft-klensin-net-utf8-05

Stephane Bortzmeyer <> Tue, 09 October 2007 13:30 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1IfFAX-0006cG-Pp; Tue, 09 Oct 2007 09:30:41 -0400
Received: from discuss by with local (Exim 4.43) id 1IfFAW-0006br-9y for; Tue, 09 Oct 2007 09:30:40 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1IfFAW-0006bi-0B for; Tue, 09 Oct 2007 09:30:40 -0400
Received: from ([] by with esmtp (Exim 4.43) id 1IfFAP-00086h-QJ for; Tue, 09 Oct 2007 09:30:39 -0400
Received: by (Postfix, from userid 10) id DFA3F24080E; Tue, 9 Oct 2007 14:30:02 +0200 (CEST)
Received: by horcrux (Postfix, from userid 1000) id 88C41157D25; Tue, 9 Oct 2007 15:20:25 +0200 (CEST)
Date: Tue, 9 Oct 2007 15:20:25 +0200
From: Stephane Bortzmeyer <>
To: John C Klensin <>
Subject: Re: draft-klensin-unicode-escapes-05 and draft-klensin-net-utf8-05
Message-ID: <>
References: <D88739D9B4DB164FDD94809C@p3.JCK.COM> <> <40631CD1A59A65DA1B88F394@[]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <40631CD1A59A65DA1B88F394@[]>
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: 93238566e09e6e262849b4f805833007
Cc:, "Clive D.W. Feather" <>
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 Mon, Oct 08, 2007 at 12:42:41PM -0400,
 John C Klensin <> wrote 
 a message of 82 lines which said:

> I could try to incorporate a little more text along those lines in
> the document, but please remember that it has already been
> criticized for containing too much history and explanation rather
> than just laying out the rules.

Allow me a personal soapbox. I find that typical RFCs are terribly
lacking rationales, history and background details. The focus on 'pure
specification' makes difficult to understand the choices and is a sure
recipe for reinventing bad ideas from time to time (or, worse, to
violate a specification because it seems suboptimal).

The standard IETF reply 'Read the archives of the working group, they
are public, anyway', is a joke: no normal human being can digest two
or three years of a typical WG mailing list archive and still do
actual work.

I understand the need to separate the specification from the rationale
(for large RFC, this could be done by a split between two RFC, one
standard and one informational) but this should not prevent us to have
a 'Rationale and design choices' section.