摘要

  • RFC 825 看到，同一个 RFC 编号序列承载了五种不同的行为：规范、讨论、信息、状态和报告。因此，文件必须在开头说明意图；编号只负责定位，不能单独证明权威。
  • 公共文件、邮件列表通知和保守的 ASCII 页面限制，让记录能在不同终端和打印设备上流通。可访问性扩大了证据面，却不会自动制造共识、采用或符合性。
  • RFC 1796 与 RFC 2026 后来进一步区分 RFC 文件编号、STD 标准编号、流程状态和实现证据。负责任的引用必须保留这些差异，而不是只留下看似精确的数字。

空白状态栏改变了整句话

目录中的编号仍然准确，所以错误容易被忽视。若一份 Informational 文件被简称为“RFC 标准”，引用者并没有伪造来源；他删掉了限制来源权力的字段。文件身份被保留，文件能支持的结论却被扩大了。

RFC 825 的出发点正是这种结构性歧义。RFC 可以用来公开信息，可以开始或继续一场讨论，也可以规定协议。统一的编号和外观方便保存，却让不同意图看起来像同一种制度行为。

它没有要求所有作者使用完全相同的套话。它要求在标题页、第一段或第二段把一般意图说清楚。共同层只规定最低限度的可解释性，未来的具体表达仍留给作者。这种设计既减少歧义，又没有把写作本身变成僵硬模板。

五种意图给证据划出了边界

RFC 825 给出的 Specification 示例，明确表示文件为 ARPA Internet 社群规定标准，并期待主机采用和实现。Discussion 则把问题和可能的解决办法摆到公共视野中，同时声明这些方案当时不是标准；共识或许会在以后形成。

Information 面向社群征求反应，内容即使不直接属于互联网研究的核心问题，也可能对研究者和实现者有价值。Status 是带日期的快照：发布时准确，但可能变化，后续 RFC 会记录新的情况。Report 记录会议结果，可以包括影响协议实现的重要决定、可选功能的限制或扩展、政策议题、技术讨论和未完成工作。

这些不是装饰性标签。讨论文件可以证明某个想法曾被公开提出，却不能证明它已被接受。状态文件可以证明某一时点的认识，却不能永远替代后来记录。会议报告可以证明会议记录了什么，但是否能约束某个行动者，还要看会议本身的权限和程序。

即使是规范，也不能单独证明产品已经实现、不同实现已经互通或网络已经采用。意图是判断的起点，不是所有事实的终点。

58 行和 72 字符解决的是可达性

当时的 RFC 存放在公共访问文件中，再由一封短消息通知邮件列表。读者把文件复制到自己的站点，在各自设备上打印或显示。若文件依赖作者本地的字体、排版程序或终端特性，公共访问只是名义上的。

RFC 825 因此规定 ASCII；每页最多 58 行，随后是换页符；每行最多 72 个字符，随后是回车和换行；禁止叠印或下划线。页眉、页脚、页码和缩进也必须计算在限制内。

这些规则今天看起来像旧打印机留下的痕迹，但当时它们构成了表示层的最小公约。文件在不同机器之间复制后仍能保持可辨认的结构，档案不必依赖某一种编辑工具继续存在。

然而，显示兼容不等于协议兼容。邮件列表的通知不是表决，下载不是实现，公开可读不是社群推荐。格式让一份主张能够移动，也让它的意图有机会一起移动；它不负责判断主张是否正确。

RFC 编号和 STD 编号回答不同问题

到 1995 年，RFC 1796 直接用标题提醒读者：并非所有 RFC 都是标准。RFC 系列既是互联网标准文件的发布渠道，也收录 IESG、IAB 和互联网社群的其他出版物。进入这一渠道本身并不会赋予标准地位。

它指出一个现实弱点：状态会出现在文件首页，却常常从转述和引用中消失。编号留下来，严谨的外观也留下来，但读者收到的是一份被抬高了权威的来源。

RFC 1796 还区分了两套编号。RFC 编号识别文件；STD 编号识别标准协议。两者不是一一对应。一个标准可能由多份文件共同规定，文件获得 STD 身份后仍保留原来的 RFC 编号。

这种分工保护了档案地址的稳定性。文件的状态、替代关系、实现经验和部署范围都可能变化，不应被塞进一个永远不变的序号里。编号维持唯一性和检索，其他记录分别说明各自的事实。

一个档案可以广收，却不能把收录当批准

RFC 1796 也回应了“为什么不把标准和其他文件分开”的疑问。单一系列让文件容易寻找，让服务器容易组织；范围狭窄的子系列则容易随着时间从网络上消失。

公开保存未成为标准的规范也有价值。一个实验可能失败，却解释了后来设计为何转向。一个私人开发的协议可能已经进入产品，公开文件至少让操作者看得见其行为。未获得共识的方案仍能提供可审计的历史。记录比无知更好，前提是记录不会冒充背书。

因此，档案不应只保存胜者。Historic 文件没有因失去现行地位而失去历史价值；Experimental 文件没有因保留不确定性就失去技术意义。删除弱主张会破坏记忆，把弱主张描述成强命令则会破坏信任。

单一档案的代价是更严格的元数据纪律。搜索结果、采购条款或政策说明若只展示 RFC 编号，就把多层档案误画成单层权力结构。正确修复是恢复状态、日期与替代关系，而不是降低文件的公共可达性。

标准地位来自另一条证据链

RFC 2026 后来把互联网标准过程写得更完整。技术能力、公开审查、多次修订、多个独立且可互操作的实现、运行经验、公共支持、可用性和正式采用，构成了比“已经发布”更强的证据。

它把 Experimental、Informational 和 Historic 列为非标准轨道类别，并明确说明 Informational 不代表互联网社群的共识或推荐。这不表示内容低劣，只表示读者不能从该标签推出标准授权。

RFC 8729 在较后的框架中继续保留一个 RFC 系列，同时承认不同文档流有各自的批准过程。在该框架下，只有 IETF 文档流能批准 Standards Track 或 Best Current Practice RFC。共同出版者负责保存和呈现，不会替代作出批准决定的过程。

于是，至少有五列证据需要分别保存：文件身份、意图或状态、批准过程、实现与互通、实际部署。编号只能填第一列。引用它不能让后四列自动出现。

完整引用要保留正确的不确定性

对重大决定，引用应保留编号、标题、日期、与主张有关的状态或类别、具体章节以及更新或废止关系。若声称标准权威，还应指出 STD 或 BCP 身份和相应过程；若声称运行行为，则要补上测试、实现或运营观察。

边界也防止反向误读。Informational 不等于错误，Experimental 不等于无人使用，Historic 不等于机制全部消失，Standards Track 也不等于某个产品已经符合。标签不会包办判断，却能阻止判断越过证据。

RFC 825 的持久价值并不只在旧页面格式。它让统一档案承担记忆，而不是承担一切权力。编号告诉读者文件在哪里，意图告诉读者文件声称做了什么。更强的权威，必须由更强的记录来证明。

来源