摘要

  • RFC 5385 描述的 Word 模板可以让预览、直接打印与合规 ASCII 文本在行和页上高度一致，但真正的文本还要经过受控样式、纯文本打印文件和 Perl 后处理程序。
  • 因而，视觉相同只能证明一个呈现层。现代 RFC 政策把 RFCXML 定为 definitive format，并把 HTML、纯文本、PDF 视为 publication versions，正是为了把语义权威与多种呈现分开。

四个“文档”同时出现在会议室里

桌面上有一份 Word 文件。投影幕上有它的打印预览。共享目录里有经过处理的文本。网站上又有公开版本。参会者往往把它们统称为“那份文档”，仿佛只是同一个东西换了容器。

RFC 5385 迫使我们把它们拆开。它在 2010 年以 Independent Submission、Informational 的身份发布，介绍第二版 Microsoft Word 模板。作者可以使用熟悉的可视化编辑界面，以大纲方式调整章节，并预览接近 RFC ASCII 版面的结果。对于不愿直接书写 nroff 或 XML 的作者，这是一项切实的降低门槛设计。

但屏幕内容并不会自动成为合规文本。规范记载的生成过程是：使用 Generic/Text Only 打印机形成 .prn 文件，再运行 Perl 后处理程序。程序删除回车，替换智能引号与连字符，清理页脚与下一页页眉之间的空行，插入换页控制符，并检查非法字符。

所以，Word 源、预览画面、打印中间物和最终文本分别拥有不同字节、不同失效方式与不同证明能力。页面逐行相似是一项有价值的验收结果，却无法替其余三层发言。

样式定义了结构，字号只定义了外观

第二版模板重新定义 Word 内建的 Normal、Heading1 到 Heading9、Header、Footer、Caption，并增加图、列表、参考文献与附录样式。RFC 5385 强调，不应使用模板之外的样式。

这不是审美偏好。内建标题样式使大纲模式能够提升、降低章节并自动重编号。一个手工加粗、放大的段落可以和真正的标题长得一样，却不会进入同一结构体系。

这种差别在今天更常见。颜色和下划线可以伪装链接，空格可以伪装表格，短横线可以伪装列表，视觉框可以伪装分区。对肉眼而言，它们可能毫无区别；对屏幕阅读器、索引器、转换器和档案系统而言，它们是不同对象。

因此，审核不应只截取页面。还要导出标题树、阅读顺序、链接目标、图像说明、引用关系与机器可读标识。视觉检查回答“读者此刻看到了什么”，结构检查回答“系统实际保存了什么”。两份收据缺一不可。

转换程序没有署名，却参与了编辑

把弯引号改成 ASCII 引号，听上去像无害清理。可一旦字符代表姓名、公式、协议标记或法律区别，替换就是决策。删除页眉页脚之间的空行同样依赖对页面边界的正确判断。检查非法字符则决定哪些内容可以进入最终文件。

RFC 5385 把 Perl 程序放入附录，使规则至少可以被阅读。这比一个完全封闭的导出按钮更好。不过，附录中的代码并不自动证明实际执行的是同一份代码，也不记录运行环境、输入与退出状态。

一条完整生成收据至少包括：获批源文件哈希、模板版本、转换程序哈希、操作系统与字体环境、参数、诊断输出、生成时间和产物哈希。若某些字段必须动态变化，就要明确哪些变化允许出现，并另做语义对比。

“使用官方工具”不够精确。官方工具也有版本，版本也有配置，配置也可能在没有页面差异的情况下改变元数据或结构。工具可信度不能替代本次运行的可验证记录。

稳定 RFC 指向了会变化的模板

RFC 5385 的安全章节记录了一个看似微小的问题。模板按当时的开发与发布方式不含宏。作者考虑把 .dot 模板和 .pl 程序的 MD5 值写进 RFC，但模板会随着 IETF boilerplate 要求变化，无法在固定文本中永久绑定；当时的校验值转而与外部工具一起发布。

这里不能把 MD5 当作今天的建议。真正重要的是生命周期错位：解释文档固定，运行资产可变。只说“RFC 5385 模板”并不能唯一定位某次使用的模板内容。

企业中的“标准合同”“最新报表模板”“统一披露格式”经常存在同样问题。名称从不变化，里面的条款、字段或默认行为却被覆盖更新。几个月后，两份文件都声称来自同一模板，组织却无法证明各自用了哪个版本。

可变模板需要独立的发布编号、哈希、生效时间、负责人和变更说明。生成文档要保留这项引用。模板自动插入的法律或政策文本仍应在展开后审核，不能因为模板名字获得了授权，就假设每次输出都正确。

参考文献暴露了“看起来一样”的脆弱性

旧版方案使用尾注。RFC 5385 说明，第一处引用可能定义尾注，删除这处引用会连带删除参考文献，即使后面还有交叉引用。新版把编号参考文献放在正文段落中，并支持以书签实现作者—年份标签。

编辑前，两种页面可以十分相像。删除一次引用之后，它们的行为却不同。静态外观无法说明对象在下一步修改中会发生什么。

测试模板时，应主动移动标题、删除首个引用、加入附录、替换图注、重新生成目录并导出所有承诺格式。真正的质量不是某个样本漂亮，而是重要结构在正常变化与边界条件下仍保持。

自动报告同样如此。十行数据成功，不代表一百行仍保持阅读顺序。英文名字成功，不代表其他文字不会消失。一个文档系统必须通过变化中的不变量证明自己，而不是靠一张理想截图。

后来的 RFC 政策把权威层写进制度

随着 ASCII 单一格式无法满足可访问性、元数据、图形、国际字符与不同设备的需要，RFC 6949 提出新要求，RFC 7990 给出格式框架。2025 年的 RFC 9720 取代 RFC 7990，并清晰区分四个概念。

RFCXML 是 definitive format；以它发布的 RFC 是 definitive version。HTML、纯文本和 PDF 是 publication formats；具体文件是 publication versions。definitive version 要包含发布时已知的全部语义信息，并足以生成各类公开呈现。关于发布意图的争议回到这一层解决。

不能把 2025 年术语倒推成 2010 年 Word 文件的历史身份。两者的联系在于治理结构：RFC 5385 的实践已经说明编辑视图、转换与输出不是一个对象；RFC 9720 后来明确规定哪一层拥有语义权威，哪些层负责服务不同读者。

组织也应作出同样选择。数据库、结构化源、PDF、网页与签名副本可以各自承担任务，却不能不经说明地同时宣称“最终”。必须预先写明冲突时以谁为准，以及其他副本如何证明来自它。

可以重新生成，但不能悄悄覆盖历史

RFC 9720 允许在限定理由下重新发布 definitive version 或 publication versions，例如修正 XML 错误或更新生成工具。要求是尽最大可能保留语义，公开记录原因，并保存可访问的旧版本。

这比“永远不改”更接近长期档案现实。格式会老化，工具会发现缺陷，可访问性也会进步。但更新行为本身会带来风险：再生成可能引入无意变化，甚至破坏标准或关键协议信息。

所以，一次重新发布必须同时保留新旧源与新旧呈现、哈希、工具版本、变更理由、语义差异和审核人。只保留最新 PDF 不是维护历史，而是替换历史。

现行 RFC 9920 又把组织责任拆开：政策形成、批准与 RFC Production Center 的实施各有主体，发布工具的设计维护也有明确责任。运行工具的人必须保证生产可靠，却不会因为掌握生成入口就获得修改意义的权力。

一张截图无法提供的四类收据

第一类是意图收据：谁撰写、哪份语义源获批、范围是什么。第二类是转换收据：具体输入、工具、配置、告警与输出。第三类是发布收据：谁赋予编号、状态、公开位置和时间。第四类是档案收据：旧版本、重发原因与恢复路径。

截图属于转换收据中的视觉验证。它对表格、分页和图形十分重要，但无法代替其他收据。哈希也有边界：它证明两组字节相同，不证明这些字节完整、获批或具有公共权威。

验收时，应让未参与生成的人在干净环境中重建产物，解释任何差异，再模拟一次重发并找回旧版。如果最后只能说“它们看上去一样”，那么页面已经验收，文档仍然没有。

来源