it states "that there may exist valid reasons in particular
circumstances to ignore a particular item ...", e.g. while the
recommendation is made for good cause, there may be particular
protocol states, network conditions, backward compatibility issues,
etc. which may apply -- and a careful specification writer will make
clear why a recommendation is made and under what sorts of
circumstances the recommendation might be ignored.
Uh, no. SHOULD and SHOULD NOT exist precisely because specification
writers too often get into the business of trying to specify exactly
when it is permissible for an implementor to make an exception to a
I'm not sure I understand your statement... Should/SHOULD NOT
specifically provide for exceptions in particular circumstances;
yes, but it's not up to the author of the specification to "make
clear...under what sorts of circumstances the recommendation might
[reasonably ] be ignored".
So, convince me that MAY is an imperative as you earlier implied, then
we can move on to SHOULD.
it's hard to interpret MAY as an imperative. then again, nobody ever
cited 2119 just so that he could reference its definition for MAY.
I can see why you reached that conclusion. But there are subtle and
important differences between the definition given in 2119 and the
normal meaning of "recommended" (just as there are subtle and important
differences between 2119's SHOULD and "should"). If we want to
encourage a practice without imposing the requirement that "the full
implications _must_ be understood and carefully weighed before choosing
a different course" (emphasis mine) then we need another word besides
Such as "encouraged" perhaps?
or perhaps ENCOURAGED to make it clear that the word is being used as an
alternative to MUST, SHOULD, RECOMMENDED, etc.