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

引用RFC来支持观点（包括Serverfault问答）是非常普遍的，但是对于那些RFC定义标准以及哪些纯粹是信息性的，普通的IT员工了解得很少。这并不奇怪：所有经验水平的系统管理员通常都会避免对RFC视而不见，除非他们别无选择。

在像我们这样的网站上，至关重要的是，我们不要在常见的误解中永久保留误解。来自搜索引擎的随机用户会认为没有争议的评论是足够的审核指标。最近，我偶然发现了2011年的一个答案，很明显，在某些情况下我们肯定会对此予以保留，并可能需要做出一些努力来告知我们的社区和整个互联网。

因此，事不宜迟，如何区分可引用为互联网标准的RFC和纯粹可参考的RFC？

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

• 一些较旧的RFC没有明确标记。如有疑问，请将其插入http://www.rfc-editor.org/的搜索框中，并注意“ 状态”列。小心标记为Unknown的任何内容，因为它们实际上已被放弃并且不相关。
• 不论最初是如何分类的，任何带有历史标记的RFC 都已被淘汰。
• 任何状态为提议标准或Internet标准的 RFC 都可以用作适用Internet标准的技术参考。这有点违反直觉，将在下面进行介绍。

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

  • 就是说，指定为Best Current Practice（BCP）的RFC 应该被认为具有重要的咨询意义。它们不像标准那样具有约束力，但是经过严格的审查，并接受与标准RFC相同的审查。忽略它们并没有违反标准，但是通常这是一个坏主意。
  • 缺少BCP标识符的信息 RFC最好比作您在IT杂志上看到的文章。您不会从办公桌上拿出社论来告诉导演它定义了标准，对吗？
  • 实验性 RFC仅可用作它们描述的实验性功能的参考，而不能作为与其相关的标准的参考。它们一直处于真空状态，直到被提升到标准轨道。
  • 有时，技术参考可能在作为Internet标准合并之前以Informational 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 2026开始的几个RFC的串联。

在真空中独自阅读RFC 2026的情况很普遍，但这也是一个糟糕的主意：

• RFC 6410完全消除了标准草案的概念。
• RFC 7127是BCP 9的最新版本（2014年），它清楚地表明，尽管广泛实施并具有很高的稳定性，但许多提议的标准都从未升级为Internet标准。这在很大程度上是由于现代提案标准在归类之前要接受更高的审查标准。该RFC有效地撤回了RFC 2026先前的声明，即“实施者应将拟议标准视为不成熟的规范”。永远不要把那行引给任何人。

简而言之，如果RFC文档完全在互联网标准轨道上，则它具有足够的成熟度，可以用作技术参考，直到将来的RFC更新它为止。

免责声明

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

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

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

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