跳到主要内容

RFC 2119 - RFC 中用于表示需求级别的关键词 (Key words for use in RFCs to Indicate Requirement Levels)

  • 状态: Best Current Practice
  • 发布日期: March 1997
  • Stream: IETF
  • 勘误: 无勘误

本备忘录的状态​

本文档为互联网社区规定了互联网最佳当前实践, 并请求讨论和改进建议。本备忘录的发行不受限制。

摘要​

在许多标准跟踪文档中, 有几个词用于表示规范中的要求。这些词通常大写。本文档定义了这些词在 IETF 文档中应如何解释。遵循这些指南的作者应在其文档开头附近加入以下短语:

本文档中的关键词 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD 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", 意味着该项目是真正可选的。一个供应商可能选择包含该项目, 因为特定市场需要它或因为供应商认为它增强了产品, 而另一个供应商可能省略同一项目。不包含特定选项的实现必须 (MUST) 准备好与包含该选项的另一个实现互操作, 尽管可能功能有所减少。同样, 包含特定选项的实现必须 (MUST) 准备好与不包含该选项的另一个实现互操作 (当然, 除了该选项提供的功能之外)。

6. 使用这些命令词的指导 (Guidance in the use of these Imperatives)​

本备忘录中定义的命令词必须谨慎且节制地使用。特别是, 它们必须 (MUST) 只在实际需要互操作或限制可能造成危害的行为时使用 (例如, 限制重传)。例如, 它们不得用于试图在互操作不需要该方法的情况下向实现者强加特定方法。

7. 安全考量 (Security Considerations)​

这些术语经常用于指定具有安全含义的行为。不实现 MUST 或 SHOULD, 或做规范说 MUST NOT 或 SHOULD NOT 做的事情对安全的影响可能非常微妙。文档作者应花时间阐述不遵循建议或要求的安全含义, 因为大多数实现者不会从产生规范的经验和讨论中受益。

8. 致谢 (Acknowledgments)​

这些术语的定义是从许多 RFC 中提取的定义的综合。此外, 还吸收了包括 Robert Ullmann、Thomas Narten、Neal McBurnett 和 Robert Elz 在内的许多人的建议。

9. 作者地址 (Author's Address)​

Scott Bradner
Harvard University
1350 Mass. Ave.
Cambridge, MA 02138

phone - +1 617 495 3864
email - [email protected]

参考文献​

  • 官方 RFC: https://www.rfc-editor.org/rfc/rfc2119.txt
  • Datatracker: https://datatracker.ietf.org/doc/html/rfc2119
  • 被更新: RFC 8174 - https://www.rfc-editor.org/rfc/rfc8174.html
最后于 更新