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

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

• 一些较旧的RFC没有清楚标记。 如有疑问，请将其插入search框http://www.rfc-editor.org/，并注意状态栏。 对于标记为“ 未知”的标签要非常小心，因为它们被有效地放弃，并且不被认为是相关的。
• 任何指定为“ 历史”的 RFC都已经过时，无论它是如何被分类的。
• 任何具有“ build议标准 ”或“ 互联网标准”状态的RFC均可用作适用互联网标准的技术参考。 这有点反直觉，下面将会提到。

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

  • 也就是说，指定最佳实践 （BCP）的RFC应被视为具有重要的咨询权重。 它们不像标准那样具有约束力，但是它们经过了严格的审查，并且经历了一些与标准跟踪中的RFC相同的审查。 忽略它们并不违反标准，但通常这是一个坏主意 。
  • 缺乏BCP标识符的信息 RFC最能与您在IT杂志中遇到的文章相比拟。 你不会从你的桌子上拿出一篇社论，告诉一个导演它定义了一个标准，对不对？
  • 实验 RFC只能作为他们所描述的实验特征的参考，而不能作为他们所关联的标准的参考。 他们在真空中存在，直到晋升到标准轨道。
  • 在作为互联网标准被合并之前， 有时技术参考可以作为信息RFC发布。 DMARC（ RFC 7489 ）是其中最广为人知的现代例子之一。 对于所有的意图和目的，请按照您的实验性RFC来对待它们。 它们存在于真空中并描述可选特征。
• 即使您已经浏览了这个迷宫，请注意，较新的RFC可能已经过时了您引用的RFC的重要部分！ 强烈build议您使用提供超链接的工具来更新您正在查看的工具，例如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）更新，清楚地表明，尽pipe广泛实施和高度稳定，许多提议标准从未被提升为Internet标准 。 这在很大程度上是由于现代build议标准在被分类之前经过了更高的审查标准。 该RFC有效地收回了RFC 2026的“先前的陈述”，即“实施者应该将提议的标准视为不成熟的规范” 。 切勿将该行引用给任何人。

简而言之，如果一个RFC文档是在互联网标准轨道上的话，它就有足够的成熟度来作为技术参考，直到未来的RFC更新它为止。

放弃

如上所示，由BCP 9定义的互联网标准轨道是移动目标。 这个答案是及时的快照，可能需要在未来更新。 鉴于其社区维基地位，请随时以任何方式进行修改。

前面的答案很好地列出了IETF文档的类别。 所有标准跟踪RFC都列在这里：

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

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