I generally take (what I infer to be) Richard's view on the matter. If not
doing something will break interoperability or security, then make it
normative. (I realize that's a gross oversimplification).
But that still doesn't mean you have to have a MUST for every step an
implementation has to take. To take Dean's original example, I think it makes
sense to say the implementation "... MUST send a response according to the
following procedures..." then describe the procedure without peppering it with
2119 language, except for special cases when needed for emphasis or clarity.
This seems to cover the risk of people not implementing stuff, but still avoids
an explosion of MUSTs (and the resulting requirements matrix).
Sticking with Dean's example, the use of TLS might qualify as one of the
special cases needing additional normative emphasis, but you can always say
something like "... MUST send all message over TLS" once, rather than restate
it for every message.
On Jan 4, 2013, at 1:04 PM, Richard Barnes <rbarnes(_at_)bbn(_dot_)com> wrote:
Anecdotal data point number N+1...
As an occasional implementor of IETF specs, I have to say it's much easier to
check my conformance if I can just grep for "MUST" and "SHOULD". It's also
easy for developers to get in the bad habit of ONLY doing those things that
are clearly marked in that way. So ISTM that if you're not tagging things
you want done with RFC 2119 language, then you're risking people not
implementing them.
On Jan 4, 2013, at 1:15 PM, Peter Saint-Andre <stpeter(_at_)stpeter(_dot_)im>
wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Wonderful perennial topic. :)
As I always say when this comes up, when writing drafts I've settled
on using the 2119 keywords only in their uppercase form, and otherwise
using "need to", "ought to", "might" (etc.) to avoid all possible
confusion. Sure, it's a bit stilted, but we're not writing gorgeous
prose here, we're writing technical specifications that need to be
completely clear.
Peter
- --
Peter Saint-Andre
https://stpeter.im/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlDnHCQACgkQNL8k5A2w/vxKmwCfXKjDtMqQiPp4a0udOB8Q9IbA
q9QAoNiXj2r/q4yRLp0B/13m6Xxg5YN4
=3PER
-----END PGP SIGNATURE-----