RFC2119：Key words for use in RFCs to Indicate Requirement Levels，March 1997
本备忘录的状态
本文档为 Internet 社区指定了 Internet 最佳当前实践，并请求讨论和改进建议。本备忘录的分发不受限制。
梗概
在许多标准跟踪文件中，使用几个词来表示规范中的要求。这些词通常大写。本文档定义了这些词，因为它们应该在 IETF 文档中被解释。遵循这些准则的作者应在其文档的开头附近加入此短语：
本文档中的关键词“必须”、“不得”、“需要”、“应当”、“不应当”、“可以”、“不可以”、“推荐”、“可能”和“可选”是按照 RFC 2119 中的描述进行解释。
请注意，这些词的强度会根据使用它们的文档的要求级别进行修改。
1、 MUST
“MUST/必须”这个词，或术语“REQUIRED/需要”或“SHALL/应当”，表示该定义是规范的绝对要求。
2、 MUST NOT
“MUST NOT/不得”这个短语，或短语“SHALL NOT/不应当”，意味着该定义是对规范的绝对禁止。
3、 SHOULD
“SHOULD/可以”这个词，或形容词“RECOMMENDED/推荐”，表示在特定情况下可能存在合理的理由忽略特定项目，但在选择不同的课程之前必须理解并仔细权衡全部含义。
4、 SHOULD NOT
“SHOULD NOT/不可以”该短语或短语“NOT RECOMMENDED/不推荐”表示在特定情况下，当特定行为可接受甚至有用时可能存在正当理由，但在实施任何行为之前应理解其全部含义并仔细权衡案例用这个标签描述。
5、 MAY
“MAY/可能”这个词，或形容词“OPTIONAL/可选”，表示一个项目是真正可选的。一个供应商可能选择包含该项目，因为特定市场需要它或因为该供应商认为它增强了产品，而另一个供应商可能会省略相同的项目。不包含特定选项的实现必须准备好与包含该选项的另一个实现互操作，尽管功能可能会减少。同样，包含特定选项的实现必须准备好与不包含该选项的另一个实现互操作（当然，对于该选项提供的功能除外）。
6、 使用这些命令的指南
必须小心谨慎地使用本备忘录中定义的类型的命令。特别是，它们必须仅用于互操作实际需要的地方或限制可能造成伤害的行为（例如，限制重传）例如，它们不得用于试图将特定方法强加给实现者，其中互操作性不需要方法。
7、 安全考虑
这些术语经常用于指定具有安全含义的行为。不实施“必须”或“可以”，或不执行规范规定不得或不可以做的事情对安全性的影响可能非常微妙。文档作者应该花时间详细说明不遵循建议或要求的安全影响，因为大多数实现者不会从产生规范的经验和讨论中受益。
8、 致谢
这些术语的定义是取自许多 RFC 的定义的混合。此外，还采纳了许多人的建议，包括 Robert Ullmann、Thomas Narten、Neal McBurnett 和 Robert Elz。
