Re: Fuzzy words [was Uppercase question for RFC2119 words]

[Scott Bradner <[e-mail]>]

fwiw - seems to me that the basic idea that MUST and must are the same is wrong and will lead to 
even more confusion

imo - any clarification should (not SHOULD - i.e. the english language) say
	1/ some authors capitalize some words for emphasis and clarity
	2/ there is no requirement to use capitalized words 
	2/ when capitalized words are used RFC 2119 says what the capitalized words mean
	3/ non capitalized words are interpreted using normal English 

Scott

> On Mar 28, 2016, at 4:30 PM, Barry Leiba <[e-mail]> wrote:
> 
> Brian, I think your note goes to how important it is to write clearly
> and to get a lot of eyes on it before we publish it.  Well-written
> documents, with or without 2119 key words, and with or without
> lower-case look-alikes, can still be clear.  Fuzzily written documents
> will be fuzzy.
> 
> In particular:
> 
>> they mean? It can be very unclear. If a node receives a message containing
>> an element covered in the spec by "allowed" instead of "OPTIONAL", is the
>> receiver supposed to interoperate or to reject the message?
> 
> Well, this is where 2119 advises that we *use* the key words when
> interoperability is at stake.  It's fine to be fuzzy when it doesn't
> matter, though even then, I'd argue for more explanation:
> 
>   Every frobotz MUST contain a valid bleeg.  The glorp field in the
>   frobotz is an unsigned integer that is normally between 0 and 666,
>   inclusive.  Values greater than 666 are allowed, but recipients
>   using older software might not be able to handle such values.
> ...
>   When processing a frobotz that does not meet the requirements in
>   section 3.1.4, it is permissible to reject the frobotz outright, or to
>   attempt to process the parts of it that make sense; the choice is
>   an implementation decision.  However, any frobotz that does not
>   contain a valid bleeg MUST be rejected.
> 
> That sort of thing.
> 
> Barry
> 
> On Mon, Mar 28, 2016 at 3:58 PM, Brian E Carpenter
> <[e-mail]> wrote:
>> There are times when I think RFC2119 was a really bad idea, despite it having
>> become probably the most frequently cited RFC (inside and outside the IETF).
>> It seems to create as much confusion as it avoids.
>> 
>> There are four words whose RFC2119 meaning is different from the dictionary
>> meaning: should, recommended, may and optional. Having special typography
>> for them is useful, because it signals the RFC2119 meanings. But if a spec
>> uses, for example, a mixture of SHOULD and should, who knows what the authors
>> intended? To that extent, the proposed clarification is helpful.
>> 
>> The other words (must, shall, required, not) mean what they always mean.
>> The only argument for upper-casing them is aesthetic symmetry. If a spec
>> uses alternatives like mandatory, necessary or forbidden, they are just as
>> powerful.
>> 
>> So
>>> these definitions are only meaningful if the words are capitalized
>> can be applied to should, recommended, may and optional if we want,
>> but strictly doesn't apply to must, shall, required, not, mandatory,
>> necessary, forbidden, need, or any other such words.
>> 
>> Where we can get into real trouble is if a spec contains should, recommended,
>> may and optional *plus* other non-categorical (fuzzy) words like ought,
>> encourage, suggest, can, might, allowed, permit (and I did not pull those
>> words out of the air, but out of draft-hansen-nonkeywords-non2119). What do
>> they mean? It can be very unclear. If a node receives a message containing
>> an element covered in the spec by "allowed" instead of "OPTIONAL", is the
>> receiver supposed to interoperate or to reject the message?
>> 
>> If we are issuing guidance, it should probably include a specific warning
>> to use any such fuzzy words with extreme care.
>> 
>>   Brian
>> On 29/03/2016 03:13, Scott O. Bradner wrote:
>>> one minor tweak
>>> 
>>>> On Mar 28, 2016, at 10:09 AM, Barry Leiba <[e-mail]> wrote:
>>>> 
>>>>> The wishy washy descriptive rather than proscriptive language in the abstract was because I,
>>>>> the IESG and the community were not of one mind to say that the use of such capitalized
>>>>> terms should be mandatory - quite a few people felt that the english language was at
>>>>> least good enough to convey  the writer’s intent without having to aggrandize specific words.
>>>>> Thus the abstract basically was saying: if you want to use capitalized words here is a standard
>>>>> way to say what they mean
>>>> 
>>>> Ah.  Then perhaps the clarification needs to go a little further and
>>>> make this clear:
>>>> - We're defining specific terms that specifications can use.
>>>> - These terms are always capitalized when these definitions are used.
>>> 
>>> these definitions are only meaningful if the words are capitalized
>>> 
>>>> - You don't have to use them.  If you do, they're capitalized and
>>>> their meanings are as specified here.
>>>> - 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.
>>>> 
>>>> ...and I'd like to add one more, because so many people think that
>>>> text isn't normative unless it has 2119 key words in all caps in it:
>>>> 
>>>> - Normative text doesn't require the use of these key words.  They're
>>>> used for clarity and consistency when you want that, but lots of
>>>> normative text doesn't need to use them, and doesn't use them.
>>>> 
>>>> Barry
>>> 
>>> 
>>