Subject: Re: [rtcweb] Uppercase question for RFC2119 words

From: tom p. <[email-masked]>
Date: Fri, 1 Apr 2016 11:33:19 +0100

----- Original Message -----
From: "Dave Cridland" <[email-masked]>
Sent: Wednesday, March 30, 2016 8:00 PM

> On 30 March 2016 at 18:59, Barry Leiba <[email-masked]>
wrote:
>
> For future reference, I tend not to zero-index my sentences. ;-)
>
> I think that MUST/SHOULD/MAY (the former two tempered by NOT) are
> well-understood, although the strength of SHOULD is usually
underestimated.
> OPTIONAL is probably obvious enough (though its implications may not
be),
> and SHALL/RECOMMENDED are uncommon enough that they're probably not
> understood nearly as well.

I would echo Brian's earlier comment that it is SHOULD and MAY that are
troublesome, while MUST and SHALL mean what they usually do and so do
not require further thought.  I read an I-D for a protocol using HTTP as
transport that said that if the server found the client not authorised
to access a resource, then it SHOULD return a 404 but MAY return a 403.

I think that that usage is ok but I also think it not compliant with
RFC2119 and it is the kind of scenario that the RFC ought to address.
The underlying issue I see for this case is that 'we are using HTTP and
have no control over what it says and you will be using an off the shelf
HTTP package and so will have no control over what it generates so like
it or lump it (strictly a personal interpretation of this).

Also, I see a number of ADs pushing for a SHOULD to be accompanied in
the I-D by the valid reasons why it will not happen, as opposed to
leaving it up to the implementor, and again, I see this as not
compliant, but again, I see it as a good idea.

Tom Petch

> > As a complete side thing, I wonder how this all seems to
> > German-speakers, as German uses initial caps for all nouns.  I
wonder
> > if anyone even notices if someone fails to do that.  I wonder if it
> > becomes puzzling, perhaps in some instances.
> >
> > Barry
> >
>

---

From: Lee Howard <[email-masked]>
Date: Fri, 01 Apr 2016 13:07:43 +0100

On 4/1/16, 11:33 AM, "ietf on behalf of tom p." <[email-masked] on

>compliant, but again, I see it as a good idea.

The above is what I would expect.

"there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.²

Some examples of those cases is useful in understanding why ³SHOULD² is
used. It might not be an exhaustive list.

Lee

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 3 Apr 2016 15:18:57 +0200

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 <
[email-masked]> 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 <[email-masked]>
> 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
> >
> >
>
>

---

From: Francis Dupont <[email-masked]>
Date: Sun, 03 Apr 2016 20:55:14 +0200

As a draft reviewer I often found the RFC 2119 really needs a small
update about this particulat point so I STRONGLY support your idea!

Thanks

[email-masked]

PS: I am for option 2: only uppercase keywords are keywords, others
simply belong to the English language.