Re: Fwd: I-D Action: draft-hansen-nonkeywords-non2119-04.txt

[Brian E Carpenter <[e-mail]>]

On 04/03/2016 06:44, Theodore V Faber wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> On 3/2/16 07:02, Dave Crocker wrote:
>> Folks,
>>
>> G'day.  We'd like to see whether there is interest in getting the 
>> enclosed published.
> 
> Quite excellent and useful.  A useful set of bits to be able to which
> to redirect authors, to be sure.

I'm not so sure about that. When I first saw the draft several years ago,
that was my own reaction, but please consider carefully what Dave Cridland wrote:

> It's not entirely clear to me that if a specification says "support for
> FOOBAR is necessary in order to support BLURDYBLOOP", that this is anything
> different from "implementations MUST support FOOBAR in order to support
> BLURDYBLOOP". 

When reviewing documents for Gen-ART I quite often find myself asking the
authors something like this (extracted from a recent thread on the Gen-ART list):

>>>
>>> Firstly, shouldn't that "should" be a SHOULD?
>>
>> Yes, that should be a SHOULD. Good catch

Now if that "should" had been disguised as "ought to" I would probably not
have noticed, but it ought to have been changed to "SHOULD" anyway.

So we do need precision, but IMHO adding synonyms will reduce precision,
not improve it. There are days when I think that RFC 2119 is a complete
mistake, but it does have the advantage of reducing ambiguity. Synonyms
that are superficially different but fundamentally mean the same thing
(especially for the more subtle keywords like SHOULD and MAY) increase
my confusion about what a specification really means and therefore
about what I must write in my software.

    Brian