引用 RFC 以支持意见（包括 Serverfault Q&A）是非常常见的，但普通 IT 员工对于哪些 RFC 定义标准以及哪些是纯粹提供信息的理解非常差。这应该不足为奇：所有经验水平的系统管理员通常会避免对 RFC 视而不见，除非他们别无选择。
在像我们这样的网站上，非常重要的是，我们不会在我们赞成的答案中延续常见的误解。从搜索引擎中游来的随机用户会假设没有争议评论的赞成票是审查的充分指标。最近，我偶然发现了 2011 年的一个答案，这表明这在某些情况下肯定不会被抓住，因为我们支持并且可能需要做出一些努力来告知我们的社区和整个互联网。
因此，事不宜迟，如何区分可作为互联网标准引用的 RFC 和纯粹提供信息的 RFC？
只有标准轨道上的 RFC才能被引用为定义标准。对于路过的读者，以下是要理解的要点：
一些较旧的 RFC 没有明确标记。如有疑问，请将其插入http://www.rfc-editor.org/的搜索框中，并注意“状态”列。对任何标记为Unknown的内容要非常谨慎，因为它们实际上已被废弃并且不被认为是相关的。
任何标有Historic的 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 的超链接的工具，例如http://tools.ietf.org/和http://www.rfc-editor.org/提供的工具。
这些是要点。现在我们将进入细节。
对于大多数不想花一天时间盯着 RFC 的人来说，RFC 1796是一本很好的入门书。它清楚而简洁地解释了人们假设 RFC 总是定义某种互联网标准的常见误解。特别注意供应商在推销产品时偶尔会滥用这种无知的部分。
BCP 9定义了互联网标准轨道，最值得注意的是从提议标准到互联网标准的进展。应该注意的是，这是几个 RFC 的串联，从RFC 2026开始。
在真空中单独阅读 RFC 2026 很常见，但也是一个糟糕的想法：
简而言之，如果 RFC 文档完全符合 Internet 标准，那么它已经足够成熟，可以用作技术参考，直到未来的 RFC 对其进行更新。
免责声明
如上所示，BCP 9 定义的互联网标准轨道是一个移动的目标。这个答案是及时的快照，将来可能需要更新。鉴于其社区 wiki 状态，请随意这样做或以任何方式对其进行改进。
前面的答案很好地列出了 IETF 文档的类别。此处列出了所有标准跟踪 RFC：
https://www.rfc-editor.org/standards
将 RFC 从提议或草案推进到完整标准的过程非常乏味，以至于很少有作者会费心去做。这意味着在实践中，即使像 RFC 5322 这样的修订文档只是一个标准草案，其前身 822 仍然是名义上的互联网标准，5322 是人们遵循的标准。