Project:RFC 2119
RFC中用于指示需求级别的关键词
本备忘录的状态[编辑源代码]
本文档规定了互联网社区的互联网最佳当前实践，并请求进行讨论和提出改进建议。本备忘录之分发无限制。
摘要[编辑源代码]
在许多标准跟踪文档中，有数个词用于表示规范中的要求。这些词通常大写。本文档定义了些单词，这些词应该在IETF文档中解释。遵循这些指南的作者应在文档开头附近加入以下语句：
本文档中的关键词“MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“NOT RECOMMENDED”、“MAY”和“OPTIONAL”在RFC 2119中解释和描述。
注意这些词的效力根据使用这个词的文档的需求级别修改。
1. 必须（MUST）[编辑源代码]
此词，或术语“必需（REQUIRED）”或“得（SHALL）”，指此定义是规范之绝对要求。
2. 禁止（MUST NOT）[编辑源代码]
此短语，或短语“不得（SHALL NOT）”，指此定义是规范之绝对禁止。
3. 应该（SHOULD）[编辑源代码]
此词，或形容词“推荐（RECOMMENDED）”，指特定情况下或有正当理由可忽视特定项目，但选择不同做法前，必须理解并仔细权衡其全部含义。
4. 不应（SHOULD NOT）[编辑源代码]
此短语，或短语“不推荐（NOT RECOMMENDED）”，指特定情况下，当特定行为可接受甚至有用时，或有正常理由，但在实施本标签所述之任何行为前，应该理解其全部含义，并仔细权衡情况。
5. 可以（MAY）[编辑源代码]
此词，或形容词“可选（OPTIONAL）”，指项目真正可选。供应商或选择包括此项目，因特定的市场需要，或者因供应商以其增强产品，而另一供应商则可忽略同一项目。不包括特定选项之实现必须准备与另一包括该选项之实现进行互操作，尽管可能减少功能。同样，一个包含特定选项的实现必须准备与另一不包含该选项之实现进行互操作（当然，此选项提供的功能除外）。
6. 使用这些祈使词的指导[编辑源代码]
本备忘录中定义的祈使词类型必须仔细谨慎使用。特别是，这些词必须仅在实际需要互操作或限制可能造成伤害的行为（例如：限制重传）的情况下使用。例如，在互操作不需要特定方法的情况下，不得用于试图将特定方法强加给实现者。
7. 安全考虑[编辑源代码]
这些术语常用于指定具有安全含义的行为。不实现“必须”或“应该”，或者做规范中规定的“不准”或“不应”的事情，对安全性的影响可能非常微妙。文档作者应该花时间详细说明不遵循建议或要求的安全影响，因为大多数实现者都没有受益于规范产生的经验和讨论。
8. 确认[编辑源代码]
这些术语的定义是取自许多RFC的定义的混合。此外，包括Robert Ullmann、Thomas Narten、Neal McBurnett和Robert Elz在内的许多人也提出了建议。
9. 作者的地址[编辑源代码]
Scott Bradner
MA 02138，剑桥
Mass. Ave. 1350号
哈佛大学
电话 - +1 617 495 3864
电邮 - sob@harvard.edu
