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

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.

Barry

On Wed, Apr 11, 2018 at 3:33 AM, Arnt Gulbrandsen
<arnt@gulbrandsen.priv.no> 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
> MORG@ietf.org
> https://www.ietf.org/mailman/listinfo/morg
> Note Well: http://www.ietf.org/maillist.html