+1 to Brian and others saying upper case should be used sparingly, and only where it really matters. If even then. 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. 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. 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. Thomas