On Sun July 3 2005 17:13, Keith Moore wrote:
who said anything about making an implementor (or whomever) feel good?
An implementer may think he has a "good" reason to ignore the
recommended minimum timeouts in SMTP (for example), and it may make
him feel "good" to see that lots of messages are being rejected. That
is not necessarily a *valid* reason...
[re SHOULD]
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
specification.
I'm not sure I understand your statement... Should/SHOULD NOT
specifically provide for exceptions in particular circumstances;
MUST/MUST NOT do not (they are "absolute"). Since SHOULD/SHOULD NOT
apply in *particular* circumstances, are you suggesting that lack of
clarity is a good thing in a specification?
That language was intended to apply to all of the keywords in the
document. e.g. SHOULD is also an imperative.
It is unwise to assume that the author of 2119 consulted dictionary.com
before using that word.
No such assumption is being made. The only assumption is that as RFCs
are written in English, words in them have their English meaning unless
otherwise stated.
So, convince me that MAY is an imperative as you earlier implied, then
we can move on to SHOULD.
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
RECOMMENDED,
Such as "encouraged" perhaps?