翻译 RFC 2119: 在 RFC 文档中, 用于指出规范的要求级别的关键词

最近读 RFC 文档的过程中，发现在过去十几年里，每年都有尝试翻译 RFC 的小伙伴，但是大家没有统一的规范，译文的组织也非常松散，翻译的水平参差不齐。

为了能够使大家的工作成果得到维护，并提供对译文不断迭代的可能，我最近建了一个 Github 仓库和一个网站；另外，我还翻译了几篇比较基础的 RFC，对于 RFC 文档的准确理解和翻译都很重要。希望通过做一点微小的贡献，达到“前人栽树，后人乘凉”的目的。

网站的视觉效果应该会好些，使用了等宽字体，并且有中英对照；但毕竟是第一次进行网站开发，且使用的是最低配的服务器，响应时间、页面布局会有很多问题。

https://github.com/dianbo-rfc/dianbo-rfc

https://dianbo-rfc.cn/progress

下面是译文：

Network Working Group                                         S. Bradner
Request for Comments: 2119                            Harvard University
BCP: 14                                                       March 1997
Category: Best Current Practice


             在 RFC 文档中, 用于指出规范的要求级别的关键词

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.

摘要

   在许多标准跟踪文档中 (standards track documents), 有一些词被用来表示
   规范的要求。这些词通常以大写字母的形式出现。此文给出了这些词的定义,
   即当这些词被用于 IETF 文档中时, 应当被解释为何种含义。遵循这些指南的
   作者, 应当在他们的文档开头的附近, 加入以下短语:

      在此文档中, 关于关键词 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、
      "SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 与
      "OPTIONAL" 的解释, 见 RFC 2119 中的描述。

      在此文档中, 关于关键词【必须】、【禁止】、【必要的】、【应当】、
      【不应】、【推荐的】、【可能】与【可选的】的解释, 见 RFC 2119 中的
      描述。

   注意: 这些词的效力, 可以根据具体文档的要求级别, 而进行修改。

1. 【必须】MUST   该词, 或者术语【必要的】"REQUIRED" 或【必须】"SHALL",
   意味着: 其所修饰的定义是规范的绝对必要条件。

2. 【禁止】MUST NOT   该短语, 或者短语【禁止】"SHALL NOT", 意味着: 其所
   修饰的定义是规范的绝对禁止条件。

3. 【应当】SHOULD   该词, 或者形容词【推荐的】"RECOMMENDED", 意味着: 在
   特定的情况下, 可能存在着正当的理由, 来忽略某一具体的条目; 但是, 在选
   择不同的方案前, 必须理解并仔细权衡该行为背后的完整含义。

4. 【不应】SHOULD NOT   该短语, 或者短语【不推荐的】"NOT RECOMMENDED",
   意味着: 在特定的情况下, 可能存在着正当的理由, 使得某一具体行为变得可
   接受, 甚至是有用的; 但是, 在实现此标签所描述的任何行为前, 应当理解其
   背后的完整含义, 并仔细权衡各个情况。






Bradner                  Best Current Practice                  [Page 1]

RFC 2119                     RFC Key Words                    March 1997


5. 【可能】MAY   该词, 或者形容词【可选的】"OPTIONAL", 意味着: 一个条目
   是真正可选的。某一供应商可能会出于: 特殊的市场需求的原因、或认为某一
   条目可以提高产品的原因, 而选择实现该条目; 但是, 另一些供应商也可以选
   择省略该条目。一个没有包含某一可选条目的实现【必须】做好准备, 来跟另
   一个包含了该可选条目的实现进行交互操作, 尽管前者具有较少功能。同理,
   一个包含了某一可选条目的实现【必须】做好准备, 来跟另一个没有包含该可
   选条目的实现进行交互操作 (当然, 除非该可选条目提供了与此相关的其他特
   性)。




6. 这些祈使词的使用指南

   在此备忘录中定义的这些祈使词, 必须被小心地、保守地使用。特别的, 这些
   祈使词的使用【必须】是出于互操作性的实际需要、或是为了限制可能导致潜
   在危害的行为 (例如, 限制重传)。例如, 它们不得被用于: 将特定方法强加给
   实现者, 而该方法是互操作性所不需要的。




7. 安全注意事项

   这些术语经常被用于说明具有安全含义的行为。如果没有实现某个【必须】或
   【应当】的条目, 或者做了规范中提到【禁止】或【不应】做的事情, 将会对
   安全产生非常微妙的影响。文档的作者应当花时间详细说明不遵循建议或要求
   所带来的问题, 因为在大多数实现者不会从产生该规范的经验和讨论中收益。





8. 致谢

   这些术语定义综合了许多 RFC 文档中的相关定义。此外, 还采纳了许多其他人
   的建议, 包括 Robert Ullmann、Thomas Narten、Neal McBurnett 与 Robert
   Elz。













Bradner                  Best Current Practice                  [Page 2]

RFC 2119                     RFC Key Words                    March 1997


9. 作者地址

      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]