--On Thursday, August 11, 2016 13:38 +0000 "Dearlove,
Christopher (UK)" <chris(_dot_)dearlove(_at_)baesystems(_dot_)com> wrote:
Plenty of standards use shall, but never must, as their
imperative word. For example (the first standard I had to
hand) ISO 27001 has many occurrences of shall (not
capitalised, that seems to be an IETF special) and none of
must.
...
Hi.
This may be OBE given Barry's recent note about dropping the
text deprecating the synonyms but let me try to explain one
other issue just in the hope of increasing understanding as we
go forward. Several people have commented that (most or all)
other standards bodies tend to use "SHALL" rather than "MUST",
etc. At least some of the reason is that they, historically,
have thought about standards-writing in terms of conformance.
One "shall" do something if one is to conform and, because there
is almost never a notion of partially conforming, terms
equivalent to the way we use "SHOULD" have no role.
Traditionally, the IETF and its predecessors have been more
interested in interoperability than in conformance. In an
interoperability context, statements like "you MUST do things
this way if implementations are to interoperate" and "you SHOULD
do things this way because it will increase the likelihood of
interoperation and operational success" make perfect sense.
If the wording sounds a little awkward relative to the way other
SDOs write about conformance, that may actually be an advantage
for alerting people to the difference.
There is an additional complication: we make a formal
distinction between Technical Specifications (which should
always be about whet is needed for interoperability) and
Applicability Statements (which may reasonably contain
conformance clauses as well as making recommendations (note that
word) about the use of particular features. Perhaps, in
retrospect, we should have separated non-technical (e.g., IETF
procedural) BCPs from ones about technical practices and TS
documents from AS ones and then specified different terminology
or definitions for each. We didn't, and that has led to other
types of (IMO, time-wasting) arguments about whether the use of
2119 terms in BCPs, especially IETF process BCPs, is legitimate.
Similarly, if the focus is really as narrowly on
interoperability as 2119 seems to imply, a "MUST" in an
Experimental specification to express "this may be an
experiment, but we already know that, if you fail to do
so-and-so, things won't interoperate" makes perfectly good
sense, but we've had seemingly-endless arguments about that too.
Scott may remember how much those distinctions and
considerations figured into 2119 and how much, or if, they were
discussed at the time. I don't remember. But it seems to me
that those distinctions suggest that, unless there is consensus
that 2119 is broken enough for us to open up all of these issues
and completely revise how we do things, we should confine
ourselves to find-tuning (Section 2 of
draft-leiba-rfc2119-update, plus or minus further tuning seems
consistent with that) and editorial advice --to authors and to
the RFC Editor about what we consider a likely source of
problems that should be given attention-- and avoid trying to
mess with principles piecemeal.
best,
john