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

[John C Klensin <[e-mail]>]

--On Tuesday, October 09, 2007 3:20 PM +0200 Stephane Bortzmeyer 
<[e-mail]> wrote:

> On Mon, Oct 08, 2007 at 12:42:41PM -0400,
>  John C Klensin <[e-mail]> 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).

We also tend to forget that compliance with IETF standards is 
voluntary.   If someone looks at a specification and says "that 
makes no sense to me", the odds of their implementing it just 
because the IETF says so are not high, certainly not as high as 
if they could look somewhere and say "ah, that was done for the 
following reason... even if I don't completely agree, it makes 
sense".

It seems to me to be particularly important if we are modifying, 
rather than just following, some practice or existing form of a 
standard that is out there.  One of the best reasons for doing 
so is if the existing practices are not consistent and the IETF 
work is an attempt to draw things back together or outline a 
path for the future, but that makes it all the more important to 
provide a rationale, lest people simply continue to do whatever 
occurs to them first.

> 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.

I think we are in violent agreement.

     john