Re: [MORG] [Technical Errata Reported] RFC6154 (5265)

Arnt Gulbrandsen <arnt@gulbrandsen.priv.no> Wed, 11 April 2018 07:33 UTC

Return-Path: <arnt@gulbrandsen.priv.no>
X-Original-To: morg@ietfa.amsl.com
Delivered-To: morg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A851242EA for <morg@ietfa.amsl.com>; Wed, 11 Apr 2018 00:33:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXJRcxUrJUIc for <morg@ietfa.amsl.com>; Wed, 11 Apr 2018 00:33:52 -0700 (PDT)
Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CC54124235 for <morg@ietf.org>; Wed, 11 Apr 2018 00:33:51 -0700 (PDT)
Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 5E397FA0084; Wed, 11 Apr 2018 07:33:49 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1523432029; bh=Otbg/CdyY+m377gY54p5fIEbhn23vUJORnvTiHgK9B4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XFmCnumHygroyB8sdHSc29xQ3miTs600etbkWNo7ufC7fDDfso+kMF85pVSqadQVH gqvMSPpWgvzkzOAGkRXbuLAcEjwWX7kstUC95tAbJyZnHDWl5+lfn5g7tde664V/4d oqNOTacLjNQFLfKZbDVHp9Uqd1fQRwiM0r/tHWv0=
Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1523432028-16144-31493/11/23; Wed, 11 Apr 2018 07:33:48 +0000
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
To: Randall Gellens <rg+ietf@randy.pensive.org>
Cc: morg@ietf.org
Date: Wed, 11 Apr 2018 08:33:47 +0100
User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Devuan GNU/Linux 1.0 (jessie)
Mime-Version: 1.0
Message-Id: <243b4d3d-b6e6-477c-a436-232a4ef838a6@gulbrandsen.priv.no>
In-Reply-To: <492D42AA-73E5-401D-866F-F6D7AFC2CA31@randy.pensive.org>
References: <20180225161655.11CA8B80C6A@rfc-editor.org> <CALaySJK7hM4JufHPOvrUH=8Gx0Eh3f1rWdG5i-XjDpwgu8LkUA@mail.gmail.com> <aadbd868-b9e2-4944-a02e-48fbbc007a42@gulbrandsen.priv.no> <492D42AA-73E5-401D-866F-F6D7AFC2CA31@randy.pensive.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/morg/y4mpHFHWpzTFexdqMMEYQe9JHsw>
Subject: Re: [MORG] [Technical Errata Reported] RFC6154 (5265)
X-BeenThere: morg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Messaging Organization <morg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/morg>, <mailto:morg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/morg/>
List-Post: <mailto:morg@ietf.org>
List-Help: <mailto:morg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/morg>, <mailto:morg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2018 07:33:55 -0000

I'm saying that specification writers should make up their minds: Either a 
particular feature is case-sensitive or it isn't. "Every implementer should 
treat foo as case insensitive, but I myself am going to treat it as case 
sensitive" is ungood. When a writer does that it's a sign that he/she 
doesn't actually like that aspect of his/her own spec.

A lot of RFCs get it right. Take line wrapping in line-oriented protocols: 
Just next to the first example there's often a a sentence such as "lines 
are wrapped for editorial clarity only".

And a lot get it wrong. Take RFC 3501. There are examples on about 45 
different pages, all of them use upper case for all keywords, and none of 
those 45 pages mention that this consistency is no rule, and none of the 
neighbouring pages do, either.

The rule is clear once you do find it. It's like some of those privacy 
settings on Facebook: Clear once you find them, not at all findable.

The target audience for that writing is the kind of implementer who will 
read an entire 108-page document before writing any code. Which I suppose 
mrc would consider a laudable incentive, not bad writing.

Arnt