+1 to Brian and others saying upper case should be used sparingly, and
only where it really matters. If even then.
That's the entire point: The terms provide additional information as to
what the authors consider the important points of compliance to be.
The notion (that some have) that MUST means you have to do something
to be compliant and that a "must" (lower case) is optional is just
nuts.
In some ways I find the use of SHOULD and SHOULD NOT be to be more useful
than MUST and MUST NOT. MUST and MUST NOT are usually obvious. SHOULD and
SHOULD NOT are things on the boundary, and how boundary cases are handled
is often what separated a good implementation from a mediocre or even poor
one.
If the ARP spec were to say, "upon receipt of an ARP request, the
recipient sends back an ARP response," does the lack of a MUST there
mean the response is optional? Surely not. And if we make it only a
SHOULD (e.g., to allow rate limiting of responses - a very reasonable
thing to do), does lack of MUST now make the feature optional from a
compliance/interoperability perspective?
The idea that upper case language can be used to identify all the
required parts of a specificition from a
compliance/conformance/interoperability perspective is just
wrong. This has never been the case (and would be exceeding painful to
do), though (again) some people seem to think this would be useful and
thus like lots of upper case language.
At most it provides the basis for a compliance checklist. But such checklists
never cover all the points involved in compliance. Heck, most specifications in
toto don't do that. Some amount of common sense is always required.
Where you want to use MUST is where an implementation might be tempted
to take a short cut -- to the detriment of the Internet -- but could
do so without actually breaking interoperability. A good example is
with retransmissions and exponential backoff. You can implement those
incorrectly (or not at all), and still get "interoperability". I.e.,
two machines can talk to each other. Maybe you don't get "good"
intereoperability and maybe not great performance under some
conditions, but you can still build an interoperabile implementation.
IMO, too many specs seriously overuse/misuse 2119 language, to the
detriment of readability, common sense, and reserving the terms to
bring attention to those cases where it really is important to
highlight an important point that may not be obvious to a casual
reader/implementor.
Sadly true.
Ned