On Sun July 3 2005 11:13, Keith Moore wrote:
Keith said SHOULD means MUST ..., which is clearly not the case,
otherwise the separate terms wouldn't be defined in separate sections
with separate meanings and given separate conditions for use (in
section 6).
No, I didn't say "SHOULD means MUST", I said "MUST do this unless you
have a good reason to make an exception."
Yes, hence the ellipsis.
Which is a paraphrase of the
more carefully worded language in 2119.
Actually not. Note that the 2119 text for SHOULD does not give
implementers, end users, etc. leave to "make an exception" because
doing so makes them feel good, 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.
In particular, MUST is an imperative and MUST only be used where
there is potential for harm or where required for interoperation.
That language was intended to apply to all of the keywords in the
document. e.g. SHOULD is also an imperative.
http://www.dictionary.com/search?q=imperative gives definitions of
imperative which include such terms as "command", "obligation", and
"rule [...] that compels a certain behavior".
[re. MUST]
It expresses an absolute requirement. SHOULD is a recommendation. A
recommendation which should not be made lightly or ignored without a
valid reason, but certainly not an absolute requirement.
Now I think you are the one interpreting 2119 liberally. It doesn't say
that SHOULD is a recommendation.
Considering that SHOULD has the same BCP 14 meaning as the adjective
RECOMMENDED, and that a recommendation is something which is
recommended, it's pretty hard not to reach that conclusion. You're
welcome to try to rationalize not doing so...
http://www.dictionary.com/search?q=recommendation gives definitions
of recommendation which include none of the terms mentioned above
for imperative, instead using terms such as "advisable", "desirable",
and "favorable". Clearly "imperative" and "recommendation"
(SHOULD/SHOULD NOT) are very different, and a recommendation, i.e.
something which is RECOMMENDED, is clearly not an imperative.
2119 says MUST means an absolute requirement, and MUST NOT means an
absolute prohibition. http://www.dictionary.com/search?q=requirement
defines requirement in terms of "necessity" and "obligatory". N.B.
"obligation" and "obligatory"; MUST is an imperative.
http://www.dictionary.com/search?q=prohibition defines prohibition
using the terms "forbids" and "commanding"; N.B. "command" and
"commanding"; MUST NOT is an imperative. Ditto for SHALL/SHALL NOT.
RFC 2119 gives the meaning of the keyword MAY as truly optional.
http://www.dictionary.com/search/q=optional gives definitions of
optional in terms such as "not compulsory" and "not necessary".
N.B. "compels" vs. "not compulsory; clearly MAY is not an imperative;
it is clearly the opposite of an imperative. MAY is a BCP 14
keyword; you are free to try to convince me that something which is
explicity "not compulsory" somehow "compels a certain behavior"...
It also turns out that there are occasionally other good reasons to use
MUST, SHOULD, etc. which has resulted in a couple of RFCs either
defining these keywords internally or referencing another set of
definitions of these keywords.
True, but irrelevant; that doesn't bear on the BCP 14 meanings.