RFC 3 带读：Documentation Conventions——互联网最早的协作规则，为什么反而鼓励“不成熟”
前言
RFC 1 和 RFC 2 讨论的是一个很具体的技术问题：ARPANET 的 Host 软件应该怎样工作。
到了 RFC 3，Steve Crocker 突然没有继续设计 Link、Message、Host-to-Host checksum 或远程终端，而是停下来写了一篇只有很短篇幅的文档：
Documentation Conventions（文档约定）。
如果只看标题，它似乎不像一篇“技术 RFC”。但从整个 RFC 系列的历史来看，RFC 3 反而非常关键，因为它开始回答另一个更基础的问题：
一群来自不同机构、没有完整正式组织架构、正在共同设计一套从未存在过的计算机网络的人，究竟应该怎样记录、分享和讨论他们的想法？
RFC 3 给出的答案非常反直觉。
它没有要求文档必须成熟、正式、完整，也没有要求作者先证明自己正确。相反，它明确鼓励：
- 及时（timely）比精雕细琢（polished）更重要；
- 没有例子的哲学观点可以写；
- 没有背景说明的具体实现建议可以写；
- 只有问题、没有答案也可以写；
- 一篇 NWG Note 最短甚至只需要 一句话；
- 任何站点、任何人都可以产生这样的 Note；
- Network Working Group 的成员资格 不是封闭的（Membership is not closed）。
更重要的是，RFC 3 解释了为什么要这么做：
因为人们容易把“写下来的东西”误认为权威结论，而他们恰恰希望促进那些还远远谈不上权威的想法被交换和讨论；同时，人们天然不愿意发表不够完善的内容，他们希望主动降低这种心理门槛。
这其实解释了 Request for Comments 这个名字背后的工程文化。
今天的 RFC 已经拥有 Internet-Draft、Working Group、IETF Review、IESG、RFC Stream、Standards Track、BCP、RFC Editor 等完整体系，正式程度远高于 1969 年。但如果想理解 RFC 为什么不是叫“Internet Final Specification”，而是一直沿用 Request for Comments 这个名字，RFC 3 是最应该读的一篇早期文档。
它讨论的不是某个协议。
它讨论的是：
互联网协议应该以什么方式被共同创造出来。
RFC 基本信息
| 项目 | 内容 |
|---|---|
| RFC | RFC 3 |
| 官方英文标题 | Documentation conventions |
| 作者 | Steve Crocker（S. D. Crocker） |
| 所属机构 | UCLA |
| 工作组 | Network Working Group（NWG） |
| RFC Editor 当前状态 | Unknown |
| Stream | Legacy |
| 当前关系 | Obsoleted by RFC 10 |
| RFC Editor 信息页 | RFC 3: Documentation conventions |
| RFC 原文 | RFC 3 原文 |
关于 RFC 3 的发布日期
RFC Editor 当前元数据显示：
1 | |
但早期 RFC 自身的归档记录并不完全一致。
1971 年的 **RFC 100《Categorization and Guide to NWG/RFCs》**在回顾 RFC 1～102 时，将 RFC 3 记录为：
1 | |
因此，对于这种最早期 RFC，具体日期存在历史档案差异。
比较稳妥的表述是：
RFC 3 发布于 1969 年 4 月，属于 RFC 系列诞生最初几天内的文档。
Unknown 不代表“状态不明所以可能仍有效”
RFC 3 的 Status 是：
1 | |
但这不是说它现在仍然是一份“待判断是否有效”的规范。
RFC Editor 对现代 RFC 状态体系的说明中明确指出：很多在正式 Status 制度出现之前发布的 RFC，后来统一被标记为 Unknown。
RFC 3 还属于：
1 | |
意味着它产生于现代 RFC Stream 和 IETF 标准流程建立之前。
更关键的是，RFC Editor 已明确记录：
1 | |
所以 RFC 3 今天应该作为历史文档阅读，而不是当前有效的 RFC 作者规范。
为什么会有这篇 RFC
要理解 RFC 3，必须先理解 1969 年初的 Network Working Group 到底是什么状态。
一、当时甚至没有今天意义上的正式工作组体系
RFC 3 开头写得非常直接：
Network Working Group 看起来由以下几个人组成：
| 人员 | 机构 |
|---|---|
| Steve Carr | University of Utah |
| Jeff Rulifson | SRI |
| Bill Duvall | SRI |
| Steve Crocker | UCLA |
| Gerard Deloche | UCLA |
紧接着就是一句非常重要的话：
1 | |
即：
成员资格并不封闭。
这不是今天已经制度化的 IETF Working Group。
当时甚至连 ARPANET 的许多底层接口都还在形成过程中。
Steve Crocker 在后来的 **RFC 8700《Fifty Years of RFCs》**中回忆，最早这批人的处境大致是：
1 | |
所以他们只能继续开会、讨论、设计，并逐渐意识到：
光开会不够，必须把讨论写下来。
二、RFC 一开始就是“工作笔记”，不是“标准终稿”
RFC 3 对 Network Working Group 的关注范围定义得很宽：
1 | |
也就是说，这些 Notes 不只是“协议标准”。
还可以包括：
- Host Software 的设计；
- 网络应该如何使用；
- 实验设计；
- 实现技巧；
- 哲学讨论；
- 尚未解决的问题。
它更像今天一个大型开源/标准项目中的：
1 | |
的混合体。
三、真正的问题是：大家不敢写“不成熟”的东西
这是 RFC 3 最重要的背景。
如果一篇正式流转的技术文档天然会被别人理解为：
1 | |
那么作者就会产生一个非常自然的行为：
1 | |
问题是：
互联网协议当时根本没有时间等每个人先写成论文。
协议设计需要快速得到别人的反馈。
所以 RFC 3 做了一件非常重要的事情：
它不是提高文档准入门槛，而是主动降低准入门槛。
四、“Request for Comments”这个名字本身就是为了降低权威感
RFC 3 原文规定，每一份 NWG Note 都应该带有：
1 | |
后来的 RFC 8700 中，Steve Crocker 对这个名字的来历有更明确的回忆。
他担心这些文档看起来像是在宣称一种实际上并不存在的权威，于是希望建立一种规则：
1 | |
为了强化这种意味，他采用了 Bill Duvall 的建议，把这些 Notes 称为：
1 | |
不是：
1 | |
而是：
1 | |
翻成最直白的话就是：
这是一个拿出来让大家评论的东西。
RFC 这个名字后来保留了几十年，但它最初携带的心理暗示非常明确：
1 | |
核心内容
RFC 3 本身很短，核心可以分成四部分：
1 | |
整体关系可以画成：
flowchart TD
A[Network Working Group<br/>开放参与]
B[Content<br/>允许任何相关想法]
C[Form<br/>统一最小文档元数据]
D[Distribution<br/>固定分发 + 本地复制]
E[Comments / New Notes<br/>继续讨论]
A --> B
B --> C
C --> D
D --> E
E -.持续演化.-> B
RFC 3 并没有给出今天意义上的审批状态机。
它真正建立的是一个：
低门槛产生文档 + 最小格式约束 + 可追踪编号 + 固定分发
的协作框架。
一、谁可以写：任何站点的任何人
RFC 3 明确说：
1 | |
这句话非常重要。
这里没有：
1 | |
而是：
1 | |
当然，1969 年这里的“anybody”仍然处在一个很小的 ARPANET 研究共同体语境里，不能直接等同于今天互联网全球公众的完全开放投稿。
但作为组织设计原则，它已经非常鲜明：
技术讨论的产生权，不应该只掌握在一个中心机构手里。
二、可以写什么：几乎任何和网络相关的想法
RFC 3 对内容的要求异常宽松。
NWG Note 可以是：
1 | |
只要和：
1 | |
相关即可。
随后原文甚至专门列出几类“看起来不够完整但仍然完全可以接受”的内容。
只有哲学观点，没有例子
允许。
1 | |
也就是说，你可以先讨论：
1 | |
哪怕暂时还没有完整实现方案。
只有具体实现建议，没有背景铺垫
也允许。
1 | |
换成今天开发团队里常见的表达：
1 | |
即使没有先写两页“问题背景”，也可以发布。
只有问题，没有尝试给答案
仍然允许。
1 | |
这点非常值得软件开发者注意。
很多技术组织容易形成一种隐形要求：
“你提问题可以，但最好同时给解决方案。”
RFC 3 则明确说：
1 | |
因为一个尚未得到答案、但被准确表达出来的问题，本身就能推进协议设计。
三、质量要求：及时比精致更重要
RFC 3 最著名的原则之一是：
1 | |
它并不是说：
1 | |
而是在早期协议探索阶段做了一个明确的优先级选择：
1 | |
因为如果讨论对象本身还在高速变化：
1 | |
可能一个星期以后团队已经发现：
1 | |
这种环境下，“及时”本身就是技术效率的一部分。
四、最小长度：一句话
RFC 3 明确规定：
1 | |
一份 NWG Note：
最少只需要一句话。
今天看到这条规则可能有点好笑。
一篇只有一句话的 RFC？
但它其实是在传递一个极其明确的信号：
1 | |
RFC 在那个阶段首先是一种：
1 | |
的技术记录。
不一定是长篇规范。
五、为什么要故意制定这么低的标准
RFC 3 紧接着解释，这些“标准——或者说缺少标准”被明确写出来，有两个原因。
可以概括为：
flowchart LR
A[技术人员不愿发表不成熟内容]
B[写出来的东西容易被视为权威]
C[降低发布门槛]
D[弱化文档天然权威性]
E[更多早期想法进入公共讨论]
A --> C
B --> D
C --> E
D --> E
原因 1：文字天然会制造权威感
原文指出，人们容易把：
1 | |
视为：
1 | |
也就是：
一旦写成正式文字，就仿佛天然获得了权威性。
RFC 3 希望反过来强调：
1 | |
文档只是讨论媒介。
原因 2：人们会因为不够完善而不愿发表
第二个原因是：
1 | |
作者担心：
1 | |
最终导致真正需要讨论的东西迟迟没有进入公共空间。
RFC 3 希望：
1 | |
也就是主动降低这种心理阻力。
这是一套很成熟的协作机制设计：
不是假设参与者天然会开放讨论，而是修改制度，让开放讨论变得更容易。
六、文档格式只要求四类基本信息
RFC 3 对每一份 NWG Note 的格式要求非常简单。
必须包含：
1 | |
其中 X 是：
1 | |
即连续编号。
RFC 3 当时规定：
1 | |
换成结构化形式：
| 元数据 | RFC 3 的要求 |
|---|---|
| Series | Network Working Group |
| Identifier | Request for Comments: X |
| X | 连续编号 |
| 编号分配 | Bill Duvall / SRI |
| Author | 作者 |
| Affiliation | 所属机构 |
| Date | 日期 |
| Title | 标题 |
| 标题唯一性 | 不要求唯一 |
最后一条也很有意思：
1 | |
RFC 1 和 RFC 2 就是一个现实例子。
两篇都叫：
1 | |
真正稳定标识文档的不是标题，而是：
1 | |
也就是：
1 | |
七、RFC 编号比标题更像真正的主键
软件开发者可以把这套设计类比成：
1 | |
类似于：
1 | |
所以：
1 | |
这些数字最终成为互联网工程中极其稳定的引用方式。
RFC 3 当时未必能预见这种编号会使用超过半个世纪，但这个最初的“serial number”设计确实成为整个系列最稳定的身份机制之一。
八、编号不是作者自己随便填的
虽然人人都可以产生 Note，但编号仍然需要集中分配。
RFC 3 中是：
1 | |
Steve Crocker 后来在 RFC 8700 回忆，他最早还给编号增加过一个很简单的规则：
文档完成以后才分配编号，从而尽量减少编号序列中的空洞。
这说明早期 RFC 从一开始就同时追求两个目标：
1 | |
这是一个很合理的组合。
如果每个人都随便声明：
1 | |
很快就会产生冲突。
所以：
开放投稿不等于放弃全局命名空间管理。
九、分发机制：每个作者站点只发送一份副本
RFC 3 的 Distribution 部分非常有时代感。
作者所在站点只需要向指定人员：
1 | |
原文列出的接收者包括：
- Bob Kahn
- Larry Roberts
- Steve Carr
- Jeff Rulifson
- Ron Stoughton
- Steve Crocker
随后写道：
1 | |
也就是说：
每个站点如果需要更多副本，就自己复制。
流程大致是：
flowchart LR
A[Author / Site]
B1[BBN]
B2[ARPA]
B3[UCLA / Utah / SRI / UCSB 等联系人]
C1[Local Reproduction]
C2[Local Reproduction]
C3[Local Reproduction]
D[更多研究人员阅读与讨论]
A -->|one copy| B1
A -->|one copy| B2
A -->|one copy| B3
B1 --> C1
B2 --> C2
B3 --> C3
C1 --> D
C2 --> D
C3 --> D
今天我们点击一个 URL 就能打开 RFC。
但 RFC 3 诞生时：
1 | |
所以“每个站点发送一个副本、站点自己复制”不是形式主义，而是真正的文档分发基础设施。
这也提醒我们：
RFC 系列早于通过互联网在线分发 RFC 本身。
某种意义上，这是互联网技术史里一个很好玩的递归：
1 | |
关键机制与工作流程
RFC 3 没有网络报文状态机，但它实际上定义了一套非常早期的技术协作工作流。
一、NWG Note 的产生流程
按照 RFC 3，可以整理成：
flowchart TD
A[产生一个和网络有关的想法 / 问题]
B{成熟了吗?}
C[继续写]
D[没关系，也可以发布]
E[形成 NWG Note]
F[获得 RFC Serial Number]
G[添加 Author / Affiliation / Date / Title]
H[发送给规定的分发联系人]
I[各站点按需本地复制]
J[其他成员阅读与评论]
K[后续 Note 继续讨论或修订]
A --> B
B -->|成熟| C
B -->|不成熟| D
C --> E
D --> E
E --> F
F --> G
G --> H
H --> I
I --> J
J --> K
这里最特别的是：
1 | |
不是失败条件。
它是被明确允许的状态。
二、RFC 1、RFC 2、RFC 3 本身就是这套机制的演示
RFC 1：
1 | |
RFC 2：
1 | |
RFC 3：
1 | |
这三篇放在一起看，比单独看 RFC 3 更容易理解 RFC 的意义：
flowchart LR
A[RFC 1<br/>Proposal]
B[RFC 2<br/>Response / Refinement]
C[RFC 3<br/>Define Documentation Convention]
D[更多 RFC<br/>继续评论、实验、替代]
A --> B
A --> C
B --> C
C --> D
RFC 系列从一开始就不是：
1 | |
而是：
1 | |
三、RFC 的真正状态不是由“文档存在”决定
RFC 3 特别担心：
1 | |
所以从它的设计哲学看，必须主动拆开：
1 | |
和：
1 | |
这两个概念。
用今天更熟悉的软件工程语言表达：
1 | |
这一点直到今天仍然很重要。
现代 RFC Editor 也明确提醒：
不是每一篇 RFC 都是 Internet Standard。
RFC 具有不同 Stream 和 Status，阅读 RFC 时必须同时检查：
- Status；
- Stream；
- Updates；
- Updated By；
- Obsoletes；
- Obsoleted By；
- Errata。
四、早期 RFC 的版本管理方式：写新文档，而不是偷偷改旧文档
RFC 3 本身很快就被修订。
RFC Editor 当前记录：
1 | |
RFC 10 开头直接写：
1 | |
后续 Documentation Conventions 又继续出现在：
1 | |
等文档中。
所以早期 RFC 很快形成了一种极其重要的演化方式：
1 | |
而不是：
1 | |
现代 RFC Series 已经把这个原则制度化：
RFC 一旦正式发布，其内容不再修改；如果规范需要改变，通过新的 RFC 进行 Update 或 Obsolete。
对软件开发者而言，这非常像：
1 | |
五、RFC 3 → RFC 10：规则本身也必须接受评论和修订
RFC 10 在 1969 年 7 月明确成为 RFC 3 的修订版。
核心思想依然保留：
- Membership is not closed；
- anyone at any site can produce a note；
- timely rather than polished；
- 一句话也可以；
- 降低“文字就是权威”的误解。
但组织细节已经变化。
例如 RFC 3 规定：
1 | |
RFC 10 中则改成：
1 | |
分发名单也扩大。
这件事本身非常符合 RFC 3 的精神：
连“我们应该怎样写 RFC”这套规则，都不是一次写死的。
六、文档制度自身成为可演化协议
如果把 RFC 3 看成一种“协作协议”，它实际上包含：
1 | |
和网络协议一样，这些规则也会随着系统规模增长而变化。
最初：
1 | |
后来逐步变成：
1 | |
底层工具完全变了，但“公开记录技术讨论”的主线一直延续下来。
重点概念与术语
RFC
RFC（Request for Comments，请求评论）。
在 RFC 3 的时代，它首先是一类 Network Working Group Note 的编号系列。
不要用今天的“RFC = 正式互联网标准”印象反向理解 1969 年。
更准确的是：
1 | |
Network Working Group
Network Working Group（NWG，网络工作组）。
RFC 3 所描述的早期协作群体，主要围绕：
- Host Software；
- 网络使用策略；
- 初始网络实验；
开展讨论。
它不是今天制度化的 IETF Working Group。
NWG Note
Network Working Group 产生的技术笔记。
RFC 3 规定其内容可以非常自由：
1 | |
最短一句话。
Timely Rather Than Polished
RFC 3 的关键原则：
1 | |
它针对的是设计探索阶段，并不意味着现代正式标准可以忽略准确性和编辑质量。
Authoritative
Authoritative（权威性的）。
RFC 3 明确担心：
1 | |
因此刻意把 RFC 定义为鼓励讨论的载体，而不是天然正确的最终答案。
Serial Number
连续编号：
1 | |
标题可以重复，但编号负责稳定标识文档。
RFC 3 当时由：
1 | |
负责分配编号。
Affiliation
作者所属机构。
RFC 3 要求作者信息同时携带：
1 | |
反映出当时 ARPANET 项目高度依赖各研究站点协作。
Distribution
文档分发规则。
早期 RFC 还没有在线全球分发，因此需要明确：
1 | |
Obsoletes / Obsoleted By
现代 RFC 元数据中的文档演化关系。
RFC 3 当前明确：
1 | |
表示 RFC 10 替代了 RFC 3 的规则。
Legacy Stream
现代 RFC Editor 给早于正式 RFC Stream 体系的文档使用的标签。
RFC 3 属于：
1 | |
这提醒读者不要把现代 IETF 流程强行套在它身上。
NIL
RFC 3 最后的 Planned Notes 中出现：
1 | |
RFC 3 本身并没有展开 NIL 的含义。
后来的 RFC 历史回顾 RFC 8700 说明：
1 | |
它是早期 DEL（Decode-Encode Language） 思路进一步发展出来的一种 Network Interchange Language 设想。
这里需要特别注意：
这个解释来自后来的官方 RFC 历史回顾，而不是 RFC 3 正文自己给出的定义。
需要特别注意的点
1. RFC 3 不是今天的 RFC Style Guide
虽然标题叫：
1 | |
但它不是今天那种详细规定：
- XML 格式；
- section layout；
- references；
- boilerplate；
- normative language；
- artwork；
- IANA Considerations；
- Security Considerations；
的正式 Style Guide。
RFC 3 只是在定义：
最早期 Network Working Group Notes 的最低协作规则。
2. “任何人都可以写”不能简单等同于现代 RFC 可以直接发布
1969 年的：
1 | |
是在一个规模很小的 NWG 环境里说的。
今天 RFC 的生产过程已经完全不同。
根据当前 RFC Editor 流程，准备成为 RFC 的文档通常先是：
1 | |
随后根据所属 Stream 经过不同形式的：
- discussion；
- review；
- revision；
- approval；
- editorial processing；
最后才正式分配 RFC number 并发布。
所以今天不能：
1 | |
3. “Timely rather than polished”也不能拿来给低质量规范找借口
RFC 3 鼓励的是：
尽早让讨论开始。
不是：
最终规范可以不严谨。
今天应该把它类比成：
1 | |
而不是：
1 | |
事实上，现代 RFC 发布前有比 1969 年严格得多的审阅与编辑流程。
4. “RFC”从来不自动等于“Internet Standard”
这是现代开发者最常见的误区之一。
今天 RFC 可以属于不同 Stream 和 Status。
所以：
1 | |
只能说明：
1 | |
不能单独证明：
1 | |
RFC 3 自己反对“写下来就自动权威”的思想，在这件事上依然非常有现实意义。
5. RFC 3 已经被 RFC 10 明确替代
当前 RFC Editor 元数据：
1 | |
RFC 10 又明确自称：
1 | |
所以如果研究 1969 年稍后时期的 NWG 文档约定，应该继续阅读 RFC 10、RFC 24、RFC 27、RFC 30 等后续文档，而不是停留在 RFC 3。
6. RFC 100 到 1971 年已经把 Documentation Conventions 当作“行政类”主题
RFC 100 对前 100 多篇 RFC 进行整理时，将 RFC 3 放入：
1 | |
到那时，分发名单已经经过多轮更新，RFC 95 成为更晚的分发记录。
这说明 RFC 3 的具体分发名单很快就失效。
它真正长期有价值的是：
1 | |
这些原则，而不是 1969 年那六个收件人。
7. 原文分发名单中的机构标注与开头成员列表存在不一致
RFC 3 开头把：
1 | |
但现存文本的 Distribution 部分却出现了不同的站点标注。
对于这种 1969 年的历史档案，比较安全的处理方式是：
保留原文记录，并承认其内部存在不一致，而不是为了让文章“看起来整齐”自行静默修正历史文本。
这也是阅读老 RFC 时很实用的原则：
1 | |
8. RFC 3 最后的 Planned Notes 不代表这些标题最终原样成为 RFC
原文计划继续写：
1 | |
这些内容反映了当时的工作计划。
但 RFC 系列从一开始就是动态的，后续文档标题、作者和技术路线都会变化。
不要把：
1 | |
误读成：
1 | |
9. RFC 3 没有定义现代“共识”机制
RFC 3 强调：
1 | |
这和后来 IETF 的开放协作文化很容易产生联想。
但 RFC 3 并没有定义今天 IETF 所说的：
1 | |
也没有：
- Working Group Last Call；
- IETF Last Call；
- IESG Review；
- Standards Track maturity；
等机制。
这些都是后来逐渐发展出来的。
10. RFC 3 的真正创新不是 Markdown 格式，而是降低表达成本
如果把注意力全放在：
1 | |
就会错过 RFC 3 最重要的东西。
它真正解决的是一个组织问题：
1 | |
这比具体格式本身重要得多。
从今天的视角重新看这篇 RFC
一、RFC 3 很像一个大型技术组织的“协作协议”
软件开发者通常把协议理解成：
1 | |
但组织本身也需要协议。
例如：
1 | |
RFC 3 正是在给一个技术共同体定义这套“人之间的协议”。
可以表示成：
1 | |
没有这层社会协作协议，再好的网络协议也很难被多个独立机构共同完成。
二、它提前解决了“完美主义阻塞协作”的问题
现代开发团队非常熟悉这种情况：
1 | |
RFC 3 的回答非常明确：
1 | |
这和现代很多高效工程实践非常接近：
1 | |
核心不是“允许烂文档”，而是：
尽早让反馈进入设计闭环。
三、把“提问题”视为一种正式技术贡献
RFC 3 允许：
1 | |
这是一个很成熟的知识生产观。
因为技术进步经常不是从：
1 | |
开始，而是从：
1 | |
开始。
在大型系统里，一个准确的问题可能比一个未经验证的解决方案更有价值。
例如：
1 | |
早期 RFC 中很多真正推动架构演化的内容，恰恰首先以这种问题形式出现。
四、稳定 ID 比漂亮标题更重要
RFC 3 明确：
1 | |
却要求：
1 | |
这是一种很经典的信息系统设计：
1 | |
必须存在：
1 | |
今天的软件工程里也是一样：
1 | |
名字会重复，也会变化。
稳定标识才是知识图谱和引用关系的基础。
五、“已发布内容不可静默改写”对技术知识非常重要
现代 RFC Series 明确：
1 | |
后续变化通过：
1 | |
表达。
这让任何一句：
1 | |
都可以被稳定回答。
对于软件工程知识管理，这一点非常值得借鉴。
设计文档如果总是原地覆盖：
1 | |
半年以后你可能只看到当前结论，却不知道：
1 | |
更成熟的方法往往是：
1 | |
六、RFC 3 和现代 GitHub 协作有惊人的结构相似性
不能说 GitHub 的设计来源于 RFC 3。
但从协作结构看，两者非常容易形成类比：
| RFC 3 思路 | 现代软件协作中的类似形式 |
|---|---|
| anybody may produce a note | 任意贡献者可以提交 Issue / Draft PR |
| timely rather than polished | Draft PR / Early Design RFC |
| explicit question is acceptable | Issue / Discussion |
| serial number | Issue ID / PR ID |
| author + affiliation | author / organization |
| distribution | repository watchers / mailing list |
| later note revises earlier idea | follow-up PR / new ADR / superseding proposal |
| written ≠ authoritative | PR open ≠ merged |
真正相同的不是工具，而是：
把讨论从人的记忆和会议里，转移到一个可追踪的公共记录系统中。
七、今天的 RFC 已经比 RFC 3 正式得多
如果只读 RFC 3，可能会产生一个错误印象：
1 | |
今天当然不是这样。
当前 RFC Editor 描述的现代流程中，RFC 通常经历：
flowchart LR
A[Idea]
B[Internet-Draft]
C[Discussion / Revision]
D[WG / Stream Review]
E[Approval]
F[RFC Production Center]
G[RFC Number Assigned]
H[Published RFC]
A --> B
B --> C
C --> D
D --> E
E --> F
F --> G
G --> H
对于 IETF Stream，还可能经历更广泛的技术审查和 IESG 流程。
所以 RFC 3 的精神和现代流程之间存在一种有意思的张力：
1 | |
两者并不矛盾。
合理的分层是：
1 | |
八、开放参与和严格审查可以同时存在
RFC 3 写：
1 | |
现代 IETF 仍然强调参与开放。
但“开放”不等于：
1 | |
更合理的结构是：
1 | |
这可能是 RFC 3 最值得现代技术团队借鉴的一点：
降低参与门槛，不代表降低最终工程标准。
九、文档不是项目结束后的副产品，而是研发过程本身
很多团队把文档理解成：
1 | |
RFC 3 所代表的是完全不同的模型：
1 | |
文档不是“记录已经发生的研发”。
文档本身就在驱动研发。
这也是为什么 RFC 能够成为互联网技术史最重要的档案之一。
这篇 RFC 带来的影响
一、它定义了 RFC 系列最早的协作文化
RFC 3 最核心的几句话后来成为 RFC 文化非常有代表性的历史起点：
1 | |
这些规则共同指向一种文化：
1 | |
后来的制度越来越正式，但 RFC 系列从一开始就不是为了塑造“不可质疑的权威文本”。
二、它让“Request for Comments”这个名字有了制度含义
在 RFC 3 之前已经有 RFC 1 和 RFC 2。
但 RFC 3 首次明确规定每份 NWG Note 都应带有：
1 | |
从这里开始，RFC 不只是前两篇文档偶然使用的叫法，而是成为一个明确的文档系列标识。
这个名字后来一直保留。
于是出现了一个互联网史上很有特色的现象：
1 | |
这个看起来有点谦逊甚至临时的名字，最后变成了全球最有影响力的技术文档系列之一。
三、连续编号成为互联网技术史的一条时间轴
RFC 3 要求的 serial number 最终形成：
1 | |
这些编号今天不仅是文档 ID。
它们还是互联网演化史的索引。
通过：
1 | |
可以从一篇 RFC 一路追踪：
1 | |
四、RFC 3 自己很快被 RFC 10 替代，证明了这套机制真的在运转
RFC 3 不是“规则制定完以后永远有效”。
几个月后的 RFC 10 就明确说：
1 | |
随后 Documentation Conventions 又在 RFC 24、RFC 27、RFC 30 等文档中继续修订。
这恰好证明：
文档规范本身也接受 Comments。
RFC 系列不是只允许技术协议演化。
连 RFC 系列怎么运作，也可以通过 RFC 自己演化。
五、RFC 从工作笔记逐渐演化成永久技术档案
RFC 8700 对早期 RFC 的总结很明确：
最初的 RFC 真的是：
1 | |
目标主要是：
1 | |
而不是：
1 | |
但随着网络扩大、参与者增加和标准化流程成熟，RFC Series 的角色逐渐变化。
今天 RFC Editor 把 RFC Series 定义为：
Internet technical specifications and related documents 的长期归档出版系列。
也就是说：
1 | |
这是 RFC 3 之后几十年最重要的演化之一。
六、它影响的不只是互联网标准，也是一种软件工程协作范式
RFC 这个词后来甚至进入了大量与 IETF 完全无关的软件组织。
很多公司和开源项目把：
1 | |
作为设计协作机制。
这些内部 RFC 往往并不是 Internet RFC。
但为什么大家喜欢这个词？
因为它已经隐含了一套工程文化：
1 | |
这正是 RFC 3 最早试图建立的协作习惯。
七、它建立了“技术权威来自讨论过程，而不是排版正式程度”的方向
RFC 3 最有深度的一点，是主动对抗：
1 | |
这种认知偏差。
对于软件工程团队而言，这一点今天仍然极其重要。
一份设计文档写得：
1 | |
并不能证明设计正确。
真正决定质量的是：
1 | |
换句话说：
技术权威应该来自可检验的工程事实和公开讨论，而不是来自文档看起来有多正式。
这可能是 RFC 3 留给今天最重要的遗产。
总结
RFC 3 没有定义一个网络报文，也没有规定一个协议字段。
它做的是另一件更基础的事情：
定义一群协议设计者应该怎样交流。
它给出的原始规则非常简单：
1 | |
这些规则看起来松散，甚至不像“标准化组织”会制定的规范。
但它们其实解决了协议设计最容易被忽略的问题：
1 | |
RFC 1 讨论 Host Software。
RFC 2 回应 RFC 1。
RFC 3 则站出来说：
既然我们要这样持续讨论，那最好先约定一下这些讨论应该怎样被记录。
这就是 RFC Series 真正开始成为“系列”的时刻之一。
后来 RFC 的生产过程越来越成熟：
1 | |
RFC 3 自己也早已被 RFC 10 替代，具体的人员名单、纸质分发方式和编号负责人都成为历史。
但它最重要的原则没有过时：
1 | |
站在今天的软件工程视角看，RFC 3 最像一份极早期的：
1 | |
而互联网后来证明了一件事：
伟大的协议不仅需要优秀的技术设计，也需要一套允许不同人持续提出、批评、修订和淘汰这些设计的协作机制。
RFC 3 写的，就是这套机制最早的雏形。