"how numbers are stored and used in computers"
This RFC was authored by S. Bradner from Harvard University and published in March 1997 as RFC 2119, specifies Internet Best Current Practices for the Internet Community. It invites discussion and suggestions for improvements, with unlimited distribution. The document defines specific words used in standards track documents to signify requirements, often capitalized, and provides guidance on their interpretation in IETF documents. Authors are encouraged to include the following phrase in their documents: "The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in RFC 2119." The force of these words is modified by the requirement level of the document in which they are used.
The term "MUST," along with "REQUIRED" or "SHALL," indicates an absolute requirement of the specification. It signifies that the definition is mandatory and must be adhered to without exception.
The phrase "MUST NOT," or "SHALL NOT," represents an absolute prohibition within the specification. It indicates that the defined action or condition is strictly forbidden.
The word "SHOULD," or the adjective "RECOMMENDED," suggests that there may be valid reasons in specific circumstances to ignore a particular item. However, the full implications must be understood and carefully considered before opting for a different course of action.
The phrase "SHOULD NOT," or "NOT RECOMMENDED," implies that there may be valid reasons in certain situations where the behavior is acceptable or even useful. Nonetheless, the full implications should be understood, and the case carefully evaluated before implementing any behavior described with this label.
The term "MAY," or the adjective "OPTIONAL," indicates that an item is truly optional. Vendors may choose to include or omit the item based on marketplace requirements or perceived product enhancement. Implementations that do not include a particular option must be prepared to interoperate with those that do, albeit with potentially reduced functionality. Conversely, implementations that include an option must be prepared to interoperate with those that do not, except for the feature the option provides.
Imperatives defined in this memo must be used with care and sparingly. They should only be employed where necessary for interoperation or to limit behavior that could cause harm, such as limiting retransmissions. They must not be used to impose a particular method on implementors where it is not required for interoperability.
These terms are often used to specify behavior with security implications. The effects on security of not implementing a MUST or SHOULD, or doing something the specification says MUST NOT or SHOULD NOT be done, may be subtle. Document authors should elaborate on the security implications of not following recommendations or requirements, as most implementors may not have the benefit of the experience and discussion that produced the specification.