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

Barry Leiba <> Thu, 19 April 2018 22:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 39DDF12D882 for <>; Thu, 19 Apr 2018 15:36:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9bgfwekWrwEt for <>; Thu, 19 Apr 2018 15:36:35 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BA773126CF6 for <>; Thu, 19 Apr 2018 15:36:35 -0700 (PDT)
Received: by with SMTP id s78so7050757qkl.8 for <>; Thu, 19 Apr 2018 15:36:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=tLClmaHl4AdkUykGNgYPRDnGM6tNMMByo9dnCdDqap4=; b=HoZfL5so/fZVDRlU365657EGFEaaVdhPDtD/dTkkxeA9GAKOb2u6u602uZrpVYPKJD H5mpojIUwe7gkDu78Py8AniYkb2nuiDDMefhD8QzCVt3XcbeWLxQOyqOGmku3g39LCAI uFcs5BNGVkl+z5UF4Ac04M7JWDWmaXk1Xe4LMyEgXSPc4BCpMO19SLrpQWw11iSYwDXI B3/Wz1OfLGtFdJIGmA5WILXISGbWULdGMrx3oH7RKAP1hc4LNfD/DLjFPTeZXSpajkKu 8lg5ftsemmX6ydcQLNySVc8EP94Pp9nAD2cx/EuQbhp5pv3T8NCkOQiHJpVhSva0va9c jEBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=tLClmaHl4AdkUykGNgYPRDnGM6tNMMByo9dnCdDqap4=; b=Q/k9PNA+KT2UATU6YQ7ygFt44aX9SrUUmvE1dywWtOqRjwcve+piAV3LLYobQLotpY TVzChmD354uyQAzvpITjR31sA8LYf+OtTmKwvzeNHyWtVgcVxgjbrOzFORT298GLW0Cz pev0TF0Jgzbb5FDUN1o8+xGtyN7ndEG4DdoydQAPWNn572OKqOjMd4t12DXVtIqTU/ax zxVpyWf3ywCL3VMKF6qC2bJ8X3LnK5yjxROhAmq1ldqyqMZgtJHDiGJtUWzGmcEqJkxm /bWDm1mcvpeDLeUHaX060ohT995PbII6MWpQUEDclGpBEA6RdEnClnHpUn0Nw4qwMaGz xatw==
X-Gm-Message-State: ALQs6tAJouBp5DLaRI8BDN3KR9aFL/AnfdFDEI7v92InyZPff4TGh0qs lxBlfLEjcbi6GC9wEcj7GF8OigPV50mewabV3Sk=
X-Google-Smtp-Source: AB8JxZqARMWEnznxSsiV7yJvulOcS8wrS1jl6iC6/pi87cvgcAJLJv4i4np+8m5/rvkK/DN0EtXnv3gX+c7+juaY+gI=
X-Received: by with SMTP id l3mr7751279qkf.32.1524177394791; Thu, 19 Apr 2018 15:36:34 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 19 Apr 2018 15:36:34 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: Barry Leiba <>
Date: Thu, 19 Apr 2018 18:36:34 -0400
X-Google-Sender-Auth: 5p1xb_k5muRmHklnt-Jmwm3ArAo
Message-ID: <>
To: Arnt Gulbrandsen <>
Cc: Randall Gellens <>, morg <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [MORG] [Technical Errata Reported] RFC6154 (5265)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Messaging Organization <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Apr 2018 22:36:38 -0000

Arnt, I agree with you, but...

The problem is deciding how many times (and where) to say it.  We
often have a "terminology" section at the beginning, which has things
like the 2119 boilerplate, explanations of "C:" and "S:" in examples,
and such.  I figure that's a good place to put a notation about
case-sensitivity.  But that still leaves the issue that it's specified
in one place in a large document, and we still expect the reader to
read that particular bit out of the large document.

It's easy to say that one gets it right and another doesn't, but when
they both essentially have the rule in one place... what makes the one
right and the other not.


On Wed, Apr 11, 2018 at 3:33 AM, Arnt Gulbrandsen
<>; wrote:
> 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 mailing list
> Note Well: