172 lines
4.6 KiB
Plaintext
172 lines
4.6 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group S. Bradner
|
||
Request for Comments: 2119 Harvard University
|
||
BCP: 14 March 1997
|
||
Category: Best Current Practice
|
||
|
||
|
||
Key words for use in RFCs to Indicate Requirement Levels
|
||
|
||
Status of this Memo
|
||
|
||
This document specifies an Internet Best Current Practices for the
|
||
Internet Community, and requests discussion and suggestions for
|
||
improvements. Distribution of this memo is unlimited.
|
||
|
||
Abstract
|
||
|
||
In many standards track documents several words are used to signify
|
||
the requirements in the specification. These words are often
|
||
capitalized. This document defines these words as they should be
|
||
interpreted in IETF documents. Authors who follow these guidelines
|
||
should incorporate this phrase near the beginning of their document:
|
||
|
||
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.
|
||
|
||
Note that the force of these words is modified by the requirement
|
||
level of the document in which they are used.
|
||
|
||
1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
|
||
definition is an absolute requirement of the specification.
|
||
|
||
2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
|
||
definition is an absolute prohibition of the specification.
|
||
|
||
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
|
||
may exist valid reasons in particular circumstances to ignore a
|
||
particular item, but the full implications must be understood and
|
||
carefully weighed before choosing a different course.
|
||
|
||
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
|
||
there may exist valid reasons in particular circumstances when the
|
||
particular behavior is acceptable or even useful, but the full
|
||
implications should be understood and the case carefully weighed
|
||
before implementing any behavior described with this label.
|
||
|
||
|
||
|
||
|
||
|
||
Bradner Best Current Practice [Page 1]
|
||
|
||
RFC 2119 RFC Key Words March 1997
|
||
|
||
|
||
5. MAY This word, or the adjective "OPTIONAL", mean that an item is
|
||
truly optional. One vendor may choose to include the item because a
|
||
particular marketplace requires it or because the vendor feels that
|
||
it enhances the product while another vendor may omit the same item.
|
||
An implementation which does not include a particular option MUST be
|
||
prepared to interoperate with another implementation which does
|
||
include the option, though perhaps with reduced functionality. In the
|
||
same vein an implementation which does include a particular option
|
||
MUST be prepared to interoperate with another implementation which
|
||
does not include the option (except, of course, for the feature the
|
||
option provides.)
|
||
|
||
6. Guidance in the use of these Imperatives
|
||
|
||
Imperatives of the type defined in this memo must be used with care
|
||
and sparingly. In particular, they MUST only be used where it is
|
||
actually required for interoperation or to limit behavior which has
|
||
potential for causing harm (e.g., limiting retransmisssions) For
|
||
example, they must not be used to try to impose a particular method
|
||
on implementors where the method is not required for
|
||
interoperability.
|
||
|
||
7. Security Considerations
|
||
|
||
These terms are frequently 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 very subtle. Document authors should take the time
|
||
to elaborate the security implications of not following
|
||
recommendations or requirements as most implementors will not have
|
||
had the benefit of the experience and discussion that produced the
|
||
specification.
|
||
|
||
8. Acknowledgments
|
||
|
||
The definitions of these terms are an amalgam of definitions taken
|
||
from a number of RFCs. In addition, suggestions have been
|
||
incorporated from a number of people including Robert Ullmann, Thomas
|
||
Narten, Neal McBurnett, and Robert Elz.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Bradner Best Current Practice [Page 2]
|
||
|
||
RFC 2119 RFC Key Words March 1997
|
||
|
||
|
||
9. Author's Address
|
||
|
||
Scott Bradner
|
||
Harvard University
|
||
1350 Mass. Ave.
|
||
Cambridge, MA 02138
|
||
|
||
phone - +1 617 495 3864
|
||
|
||
email - sob@harvard.edu
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Bradner Best Current Practice [Page 3]
|
||
|