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

[Abdussalam Baryun <[e-mail]>]

The confusion if occured between English authors may mean that we can get
confusions among non-English authors as well, I recommend if a guidance
draft is written we will need many non-Enlish native speekers involved.


AB

On Mon, Mar 28, 2016 at 9: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
> >
> >
>
>