一、四道关

成熟度等级与典型时长：

第一行那个「6 个月过期」是 IETF 的硬规矩：草稿半年没进展就自动作废， 所以它不是「存档」，是「工作稿」。 这一点很多人误解——以为 draft-ietf-xxx-00 之类的文档可以长期引用，其实它随时会消失。 第三行那个「多个独立实现」是关键的晋升条件： 要从 Proposed 升到 Draft，必须有两份以上「能互操作」的实现。 这个要求很实在：它逼着标准去解决「两个人都照文档做，结果对不上」的问题。

二、为什么这么慢

慢是设计出来的，原因有三：

第一行那个「粗共识」（rough consensus）是 IETF 的特色： 它不是投票，是「没人坚持强烈反对」。 所以少数派的声音必须被听见、被回应，但不能靠人数碾压。 这套规则让标准推进慢，但一旦定下来就很难被推翻。 第三行的代价是文档越来越厚：每加一个特性都要考虑「老实现怎么办」， 于是形成大量「允许但不要求」的条款。 这就是为什么读 RFC 时会看到那么多「MAY」——它们都是兼容性的缓冲带。

三、五十三年的量级

用编号和年份算一下，就有尺度感了：

RFC 1    → 1969 年
RFC 9293 → 2022 年
跨度 53 年，编号到 9293
平均每年约 175 份，每月约 14 份

「每月 14 份」这个速度不算快：因为大部分是修订、勘误、实验稿，真正成为正式标准的极少。 这也解释了为什么「查 RFC 要看清状态」——绝大多数编号都不是你以为的那个东西。 对比一下其他标准化组织：ITU-T 的一份建议书往往要好几年，而且改版要开大会； IEEE 的 802 系列也是几年一版。 IETF 的「快」是靠「松」换来的——它不要求完美，只要求「能跑、有两个实现、没人强烈反对」。

四、动手 Demo：五十三年、九千多份 RFC

用编号与年份算出平均速度，再看五个等级的典型时长。 「能走到正式标准的极少」这句话，看表比看文字清楚。

years = 2022 - 1969
n = 9293
print('跨度 %d 年，编号到 %d' % (years, n))
print('平均每年 %d 份，每月 %d 份' % (n // years, n // years // 12))

lv = [('Internet Draft', '6 个月', '过期就没了'),
      ('Proposed Standard', '数年', '可以先用'),
      ('Draft Standard', '数年', '需多个独立实现'),
      ('Internet Standard', '十几年', '极少数走到这'),
      ('Historic', '—', '被废弃但仍可查')]
for a, b, c in lv:
    print('%-20s %-8s %s' % (a, b, c))

实跑输出：

--------------------------------------------------------------------
五十三年、九千多份 RFC
--------------------------------------------------------------------
**标准化流程听着抽象，用编号和年份一算就具体了。**

**RFC 1 发布于 1969 年，RFC 9293 发布于 2022 年**：**跨度 53 年、编号到 9293。**
**平均每年约 175 份，每月约 14 份。**

  等级                  中文         典型时长       含义
  ---------------------------------------------------------------------
  Internet Draft        草稿         **6 个月**     过期就没了
  Proposed Standard     提议标准     数年           **可以先用**
  Draft Standard        草案标准     数年           需多个独立实现
  Internet Standard     正式标准     十几年         **极少数走到这**
  Historic              历史         —              **被废弃但仍可查**

**第一行那个「6 个月过期」是 IETF 的硬规矩**：**草稿半年没进展就自动作废**，
**所以它不是「存档」，是「工作稿」。**
**最后一行解释了为什么「查 RFC 要看清状态」**：
**很多看起来权威的编号，状态是 Historic 或 Experimental**，**照着它实现就是错的。**

53 年、9293 份，平均每年 175 份、每月 14 份：这个数字说明「RFC 不是稀缺资源」， 平均两天就出一份。 所以「引用 RFC」本身不构成权威，关键是引用的是哪一份、什么状态。 第一行那个「6 个月过期」最值得记住：草稿是工作稿，随时会变、随时会消失。 所以生产系统里不应该依赖草稿——除非你做好了「它下个月就改」的准备。 这张表里没有「多久能从草稿升到正式标准」的平均值： 因为分布极其不均——有的协议几个月就走完，有的二十几年还在 Proposed。 给一个平均值反而会误导。

30 秒实验

1. 算一下：如果每两天出一份 RFC，一年多少份？和 175 对得上吗？
2. 查一下 HTTP/2（RFC 7540）从草稿到正式标准用了多久。
3. 想一下：为什么「多个独立实现」这个要求能提高标准质量？

常见误区

1. 以为 RFC 编号就是「标准编号」。 绝大多数 RFC 不是正式标准，要看 Category 与 STD 号。
2. 以为草稿可以长期引用。 六个月不推进就作废，生产系统不该依赖草稿。
3. 以为标准化越慢越差。 慢是「要粗共识、要多个实现」的代价，换来的是「定下来就难推翻」。

下一节讲最实用的一件事：去哪儿拿 RFC。

• ☐ （本节完，下一节 2.2.5 RFC的获取方法）

相关笔记

• TCP／IP规范——RFC
• RFC的获取方法
• 📚 图解TCP／IP · 索引