哪些 RFC 应该被引用为互联网标准？

Question

引用 RFC 来支持意见（包括 Serverfault Q&A）是非常常见的，但是普通 IT 员工对于哪些 RFC 定义标准以及哪些纯粹是提供信息的理解很差。这应该不足为奇：所有经验水平的系统管理员通常都会避免对 RFC 睁一只眼闭一只眼，除非他们别无选择。

在像我们这样的网站上，非常重要的是我们不要在我们赞成的答案中延续常见的误解。来自搜索引擎的随机用户将假设没有争议评论的赞成票是审查的充分指标。最近，我偶然发现了 2011 年的一个答案，这表明这在某些情况下绝对不会在我们投票时被抓住，并且可能需要做出一些努力来通知我们的社区和整个互联网。

因此，事不宜迟，如何区分可作为互联网标准引用的 RFC 和纯粹提供信息的 RFC？

Answer 1

只有标准轨道上的 RFC才能被引用为定义标准。对于读者来说，这些是要理解的要点：

• 一些较旧的 RFC 没有明确标记。如有疑问，请将其插入http://www.rfc-editor.org/的搜索框中，并注意“状态”列。对任何标记为Unknown 的内容要非常谨慎，因为它们实际上已被放弃并且不相关。
• 任何带有历史名称的 RFC都已过时，无论它最初是如何分类的。
• 任何状态为Proposed Standard或Internet Standard 的 RFC都可以用作适用 Internet 标准的技术参考。这有点违反直觉，将在下面讨论。

• 在所有其他情况下，不能将RFC视为与 Internet 标准相关的具有约束力的权威信息来源。

  • 也就是说，具有最佳当前实践(BCP)称号的 RFC应被视为具有重要的咨询权重。它们不像标准那样具有约束力，但它们经过了严格的审查，并接受了与标准跟踪中的 RFC 相同的一些审查。忽略它们并不违反标准，但通常这是一个坏主意。
  • 缺少 BCP 标识符的信息RFC 最好比作您在 IT 杂志中看到的一篇文章。你不会从办公桌上拿出一篇社论文章告诉导演它定义了一个标准，对吧？
  • 实验性RFC 只能用作它们所描述的实验性功能的参考，而不能用作与其相关联的标准的参考。它们存在于真空中，直到被提升到标准轨道。
  • 有时，在作为 Internet 标准合并之前，技术参考可能会作为信息 RFC 发布。DMARC ( RFC 7489 ) 是最广为人知的现代示例之一。出于所有意图和目的，请像对待实验性 RFC 一样对待它们。它们存在于真空中并描述了一个可选功能。
• 即使您已经在这个迷宫中导航，请注意，较新的 RFC 可能已经过时了您引用的 RFC 的重要部分！强烈建议使用提供 RFC 超链接的工具来更新您正在查看的 RFC，例如http://tools.ietf.org/和http://www.rfc-editor.org/提供的工具。

这些是要点。现在我们将进入细节。

对于不想花一天时间盯着 RFC 的大多数人来说，RFC 1796是一本很好的入门读物。它清楚而简洁地解释了人们普遍认为 RFC 总是在定义某种互联网标准的误解。特别注意供应商在推销他们的产品时偶尔会滥用这种无知的部分。

BCP 9定义了互联网标准轨道，最显着的是从提议标准到互联网标准的进展。应该注意的是，这是几个 RFC 的串联，从RFC 2026开始。

在真空中单独阅读 RFC 2026 很常见，但也是一个糟糕的想法：

• RFC 6410完全消除了标准草案的概念。
• RFC 7127是 BCP 9 的更新（2014 年）更新，明确指出尽管广泛实施且稳定性高，但许多提议的标准从未提升为互联网标准。这在很大程度上是由于现代拟议标准在被归类之前要接受更高的审查标准。该 RFC 有效地收回了 RFC 2026 的先前声明，即“实施者应将提议的标准视为不成熟的规范”。永远不要向任何人引用那句话。

简而言之，如果一个 RFC 文档完全在互联网标准轨道上，它就有足够的成熟度可以用作技术参考，直到未来的 RFC 对其进行更新。

免责声明

如上所述，BCP 9 定义的互联网标准轨道是一个移动目标。这个答案是一个及时的快照，将来可能需要更新。鉴于其社区 wiki 状态，请随意这样做或以任何方式对其进行改进。

Answer 2

上一个答案很好地列出了 IETF 文档的类别。此处列出了所有标准跟踪 RFC：

https://www.rfc-editor.org/standards

将 RFC 从提议或草案推进到完整标准的过程非常乏味，以至于很少有作者费心去做。这意味着在实践中，即使像 RFC 5322 这样的修订文档只是一个标准草案，其前身 822 仍然是名义上的互联网标准，但 5322 是人们遵循的标准。