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 <rbar...@bbn.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 <stpe...@stpeter.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-----
> 

Reply via email to