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
- [MORG] [Technical Errata Reported] RFC6154 (5265) RFC Errata System
- Re: [MORG] [Technical Errata Reported] RFC6154 (5… Barry Leiba
- Re: [MORG] [Technical Errata Reported] RFC6154 (5… Roy A. Gilmore
- Re: [MORG] [Technical Errata Reported] RFC6154 (5… Arnt Gulbrandsen
- Re: [MORG] [Technical Errata Reported] RFC6154 (5… Barry Leiba
- Re: [MORG] [Technical Errata Reported] RFC6154 (5… Randall Gellens
- Re: [MORG] [Technical Errata Reported] RFC6154 (5… Arnt Gulbrandsen
- Re: [MORG] [Technical Errata Reported] RFC6154 (5… Barry Leiba