Bug#944920: Revise terminology used to specify requirements

[Guillem Jover <guillem@debian.org>]

On Wed, 2020-01-29 at 14:42:08 -0700, Sean Whitton wrote:
> On Sun 26 Jan 2020 at 03:48AM +01, Guillem Jover wrote:
> > I think one of the nice things about RFC2119 is that it uses uppercase
> > versions for the normative keywords, so that these are very clearly
> > distinguished both when writing and readin, from sentences that may
> > use some of the common words but that do not carry any normative
> > meaning. Was there any consideration in using uppercased keywords?
> 
> Well, Russ has now gone through and eliminated non-normative use of the
> keywords, so I think the question is moot.

Ok, let me try again, because I'm not sure I expressed my concern
clearly.

Some of the words chosen to convey normative meaning are glue words
used to build pretty mundane sentences, so having them appear around
while they might not convey normative meaning seems rather confusing,
and is a mental overhead when reading or drafting new text. Probably
more for non-native speakers.

For example in ch-scope.rst in the entry describing the *may* keyword
the following sentence uses also «may». :) The ch-archive.rst contains
several «may» instances that do not feel like the normative *may*, at
least the ones in the DFSG?

Perhaps instead of the potentially ugly uppercased keywords, marking
them as *keyword* like in the definition of the terms would go a long
way?


BTW I guess the instances of «might» and «shall» need to be converted,
or added to the keyword list? What about «may not», or «can», «can't»,
«cannot» and «could»? And I'm probably missing other words. :)

Thanks,
Guillem