Re: I'm struggling with 2219 language again

[Ben Campbell <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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-----
>