Re: [rtcweb] Uppercase question for RFC2119 words

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 30 March 2016 at 15:34, Dave Crocker <dhc@xxxxxxxxxxxx> wrote:
On 3/30/2016 7:09 AM, Adam Roach wrote:
- There are similar-looking English words that are not capitalized,
and they have their normal English meanings; this document has nothing
to do with them.

Yes. This. This, this, this, a million times, this. If we published a
document that said only this, it would be a huge net win for the community.


Assuming that merely documenting this explicitly is sufficient, perhaps.

That such a rule differs from natural English -- which does not typically alter semantics based on case -- and that most readers of RFCs will not have such detailed knowledge of RFC2119 nor read RFCs with the care such a rule demands, my question BARRY and adam and EveryOne Else, is what makes anyone think that such a rule must (MUST?) ensure proper reading of RFCs so as to distinguish between normative portions and advisory portions?


Sorry, I think that's nonsense. RFC 2119 and its capitalized keywords are well known to anyone reading any specifications, these days. I think we can actually assume a priori knowledge of RFC 2119, for the most part. What I think would be far more surprising is this notion that the keywords, noted and referenced in capitals, also have the same precise meaning and force when written normally.

I'd note that in typical technical books, different typefaces are often used to indicate verbatim commands or code, placeholders, etc - the practise of using typographical conventions not normally found in written English in technical literature is not only extremely prevalent, but in this case in particular this is the assumption of the vast majority of those likely to read it.

If you don't believe me, go look at a XEP, or a PEP, or a W3C-TR, or any of hundreds of ad-hoc specifications from community efforts to proprietary HTTP APIs - they all use RFC 2119 language, often without even bothering to cite the document.

That's not to say that when reviewing a document, a lower-case "must" might not be better as a "MUST" - but I don't see it as any different to a similarly lower case "ought" being phrased better as a "SHOULD" if that's really what was meant. The keywords exist to enhance clarity - but nothing more. A mandatory requirement can be expressed without the "M" word. We can mention that not implementing a feature causes interoperability issues without using the "S" word. Knowing that we may read such text does not make it "OPTIONAL".

Finally, I'd note in passing that "bill" and "Bill", "will" and "Will", "heather" and "Heather", all have different semantics based on case - not that this is particular relevant.
 
It's worth distinguishing between rules that make the writers more comfortable, from rules that aid the reading efficacy in practical terms.

d/

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]