Re: Effect of “should certainly do foo” in policy
Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr> writes:
> There are package management programs that depend on the synopsis to be
> short for proper display. A 90 columns synopsis is probably a minor
> bug, but a 200 column is probably at least "normal", a 1000 columns
> synopsis is probably "serious".
Yeah, I suppose that's probably true, particularly since a 1000 column
synopsis is likely to not actually be because someone wrote 1000
characters in that field but rather that their package build system
exploded in some sort of messy way and ate all the line endings in the
debian/control stanza.
> I am not sure this is desirable. The policy is a technical document and
> not a legal document and should be easy to read. We should assume that
> developers will interpret policy in good faith and not try to find
> loop-hole to justify package brokenness. Making the policy language less
> natural will negatively affect developpers that read policy to follow it
> in good faith.
I'm probably biased from having done lots of standards work in the IETF,
but I find RFC 2119 language to be fairly natural and not impede
readability, but good for avoiding unnecessary confusion. We're
essentially doing something similar already, except that we're defining
regular lower-case words in our preamble instead of capitalizing them to
draw attention to the specialized meaning, and we don't have quite the
same definition or quite as complete of a description.
The intent is not to make it a legal document or to try to avoid any
possible ambiguity, but rather to think clearly about each requirement and
whether it's mandatory, a strong suggestion for which we recognize there
will be exceptional cases, or an optional practice. I think RFC 2119
isn't quite rich enough in that Policy has an additional distinction
between mandatory and serious and mandatory but not serious, so we may not
be able to adopt RFC 2119 directly without some fiddling.
Basically, it would be nice to have a standard terminology to distinguish
between the following states:
1. You must (or must not) do this, and doing otherwise is an RC bug.
2. You must (or must not) do this, but doing otherwise is a normal (or
important, or minor) bug.
3. You should (or should not) do this unless you really know what you're
doing and have thought about the consequences, but there are some
legitimate exception cases.
4. You're explicitly permitted to do this (used primarily when something
else could be read as implying that you're not allowed to do so, or to
be clear about what other software can assume).
RFC 2119 says that the first is MUST, the third is SHOULD, and the fourth
is MAY. It doesn't have a keyword for the second case. We currently use
"must" for the first case, "should" for the second case, and "may" for the
fourth case and have no keyword for the third case (but sometimes reuse
"should" to mean that as well).
When working on RFCs, I've found assumed use of this sort of language to
be wonderfully clarifying. It forces people proposing language to think
more deeply about whether they're proposing a requirement or a
recommendation, and think about what the implications of not following
that requirement or recommendation would be.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: