Paul E. Jones
paulej at packetizer.com
Tue Apr 10 19:47:54 PDT 2012
> > Does this suggest a different meaning:
> > "The client MUST select..."
> > "The client must select..."
> You can argue this from both sides. I would say yes: the need to do
> something can exist because this specification says so, or for other
> reasons. ("What goes up must come down" vs "the server MUST close the
> connection after sending a fatal error message".)
To me, these are still stating requirements that must be observed. OK,
granted the first example is bit quite the same, but then I would not expect
that to be in the normative sections of a standards document.
> But whenever people find
> lower case musts or shoulds in your draft they think you made a mistake,
> and then either you waste time explaining that this isn't the case or
> (usually) it turns out they were right. That being said, there are two
> lower case musts (and one in the boilerplate) plus a should in RFC 6384,
> for which I am solely to blame.
And using that as an example,
"Code Components extracted from this document must include Simplified BSD
tells me something. Had you made it all uppercase, the effect would be the
same for me.
Perhaps this is a learned behavior. There are other SDOs that do not use
case or any markup to differentiate normative words, but the normative words
are nonetheless defined (the same must/shall/should/etc.) I've not seen
"ought to" used, yet, but that's probably a good thing.
More information about the rfc-interest