引用 RFC 来支持观点（包括 Serverfault 问答）的情况极为常见，但一般 IT 员工对于哪些 RFC 定义了标准以及哪些 RFC 仅供参考的理解非常有限。这应该不足为奇：所有经验水平的系统管理员通常都会避免对 RFC 感到眼花缭乱，除非他们别无选择。
在我们这样的网站上，避免在点赞答案中延续常见的误解非常重要。从搜索引擎浏览的随机用户会认为，没有争议评论的点赞足以表明审核通过。最近，我偶然发现了 2011 年的一个答案，其中明确指出这绝对不会被抓住在某些情况下，当我们投票时，可能需要付出一些努力来告知我们的社区和整个互联网。
那么，事不宜迟，我们该如何区分可以作为互联网标准引用的 RFC 和纯粹供参考的 RFC 呢？
答案1
仅限 RFC标准轨道可以引用为定义标准。对于读者来说，以下是需要理解的要点：
一些较旧的 RFC 未明确标记。如有疑问，请将其输入搜索框中http://www.rfc-editor.org/并注意地位列。对任何标记为未知因为它们实际上已被废弃且不被认为是相关的。
任何带有以下标识的 RFC历史性已经过时了，无论它最初是如何分类的。
在所有其他情况下，RFC不能被视为与互联网标准相关的具有约束力的权威信息来源。
尽管如此，带有以下标识的 RFC最佳实践（BCP）应被视为具有重要的咨询意义。它们不像标准那样具有约束力，但它们经过严格审查，并接受与标准轨道中的 RFC 相同的审查。忽略它们并不违反标准，但通常是一种馊主意。
信息缺少 BCP 标识符的 RFC 最好比作您在 IT 杂志上看到的一篇文章。您不会从办公桌上拿出一篇社论并告诉主管它定义了一项标准，对吧？
实验RFC 只能作为其描述的实验性功能的参考，而不能作为其相关标准的参考。它们在进入标准轨道之前处于真空状态。
偶尔技术参考可以在纳入互联网标准之前以信息 RFC 的形式发布。DMARC（RFC 7489) 是这方面最广为人知的现代例子之一。无论出于何种目的，都应将其视为实验性 RFC。它们存在于真空中并描述可选功能。
即使你已经走出了这个迷宫，也要注意，较新的 RFC 可能已经淘汰了你引用的 RFC 的重要部分！强烈建议使用提供超链接的工具来更新你正在查看的 RFC，例如由http://tools.ietf.org/和http://www.rfc-editor.org/。
以上就是要点。现在我们要讲具体内容了。
RFC 1796对于不想花一整天时间研究 RFC 的大多数人来说，这是一本很好的入门书。它清晰而简洁地解释了人们普遍存在的误解，即认为 RFC 总是定义某种互联网标准。特别要注意供应商在推销产品时偶尔会滥用这种无知。
战斗计划9定义互联网标准轨道，最值得注意的是从拟议标准到互联网标准。需要注意的是，这是多个 RFC 的串联， 以。。。开始RFC 2026。
单独阅读 RFC 2026 是很常见的事，但也是一个糟糕的想法：
- RFC 6410消除了草案标准完全。
- RFC 7127是 BCP 9 的最新（2014 年）更新，明确指出许多拟议标准永远不会晋升为互联网标准尽管实施广泛且稳定性高。这在很大程度上是由于现代拟议标准在被归类为此类之前，必须遵守这些规则。本 RFC 有效地撤回了 RFC 2026 先前的声明，即“实施者应该将拟议标准视为不成熟的规范”. 永远不要向任何人引用这句话。
简而言之，如果一份 RFC 文档完全符合互联网标准，那么它就具有足够的成熟度，可以用作技术参考，直到未来的 RFC 对其进行更新。
免责声明
如上所述，BCP 9 定义的互联网标准轨道是一个不断变化的目标。此答案是时间快照，将来可能需要更新。鉴于其社区 wiki 状态，请随意更新或以任何方式对其进行改进。
答案2
前面的答案很好地列出了 IETF 文档的类别。所有标准跟踪 RFC 都列在这里：
https://www.rfc-editor.org/standards
将 RFC 从提议或草案推进到完整标准的过程非常繁琐，很少有作者愿意这样做。这意味着在实践中，即使像 RFC 5322 这样的修订文档只是一个草案标准，而其前身 822 仍然是名义上的互联网标准，但 5322 才是人们遵循的标准。