摘要

  • 8 月 29 日，一名参与者发现 IETF 84 的两个无扩展名链接无法取得 AVTCORE 与 MMUSIC 会议纪要；另一名参与者却在 rsync 同步副本里找到了相关文件。
  • IETF 工作人员随后扩大服务器尝试的历史文件扩展名集合，纳入 PDF、HTM 等实际存在的格式；9 月 6 日的低频检查显示两个原链接均已返回 HTTP 200。
  • 这次修复区分了四种经常被混为一谈的状态：档案是否存在、公众是否能访问、返回对象是否正确，以及返回字节是否与声明版本一致。
  • 应为每件会议材料发布机器可读的完整性清单，把稳定身份绑定到具体路径、媒体类型、字节数、哈希、版本、修订状态、替代关系与最近检查时间。
  • 清单不取代会议纪要，也不判断内容正确与否；它只让服务器的解析选择、修订历史和当前可验证状态变得可观察。

同一份档案，网页与镜像给出不同答案

8 月 29 日，Jörg Ott 从 IETF 84 会议档案页面点击链接时，无法取得 AVTCORE 和 MMUSIC 的会议纪要，随机查看的其他工作组则可以打开。他在最初报告中建议自动检查链接，还记录了自己通过较差的远程移动网络调查时遇到的一次 Cloudflare 1015 限流响应。

这能证明读者入口当时失败，却不能证明文件遭到删除或损坏。Carsten Bormann 转而查看 rsync 表面。他在一份约 68 GB 的本地会议档案中找到了两个会话的文件。这只是某个同步快照，不足以证明所有历史文件完整，也不能证明每个副本的字节始终相同。不过对眼前两个案例，它已经说明“链接打不开”与“文件不存在”不是同一件事。

Ott 后来把现象进一步指向 PDF 与 HTM 扩展名差异。9 月 2 日，IETF 工作人员给出了运行层面的解释：旧会议网页链接的是没有扩展名的纪要名称，服务器只会依次尝试一组有限的扩展名。工作人员随后扩大了候选集合，加入数据中实际出现的 .pdf、.htm 及其他变体，并表示报告中的两个案例和另外若干案例现在应能工作。

同一封回复还说，限流门槛设置得较高，普通浏览应该不容易触发；若再次发生，Cloudflare Ray ID 有助于诊断。这不能抹去 Ott 看到的 1015，也不能把一次观察扩大为整个会议档案的普遍故障。链接解析错误与访问控制需要分别记录。

HTTP 200 只回答“现在拿到了东西”

9 月 6 日的一次克制检查中，AVTCORE 无扩展名地址返回了一个 242,140 字节的 PDF，Last-Modified 指向 2012 年，观测到的 SHA-256 为 937e224285a7eae6bf1cbeb9106e5eb0bf4df7b34bf02a10587f6da9ef4e49e1。MMUSIC 地址返回 HTML，同样带有 2012 年的修改时间，观测到的 SHA-256 为 88a6f5fd2d5459bfa1c66dc7d24b54e441a4e05507e009adf99409486c19a214。

这些哈希只描述特定日期取得的响应，不能自行成为永恒的权威版本声明。直接访问以 avtcore.html 或 mmusic.html 结尾的地址也会成功，但它们返回的是工作组概览页，字节和修改时间都不同，并非会议纪要。可见，凭习惯补上 .html，可能得到一份真实但错误的对象。

IETF 84 会议档案首页首先服务于人类读者。扩展名回退让旧链接在历史命名不统一的情况下继续可用，是合理的兼容措施。问题在于，一个“打开成功”的结果压缩了四个不同问题：

  1. 存在性：某个存储或镜像中是否保存了与该会话相关的材料？
  2. 可达性：公众现在是否能通过请求取回某个响应？
  3. 身份：响应是否就是声明的会议纪要，而不是工作组页面或误选格式？
  4. 完整性：返回字节是否与某个明确版本在明确时间的声明一致？

服务器修改直接改善的是第二项。同步副本为第一项提供了局部证据。媒体类型、大小和哈希使第三、第四项有了可检查的抓手。四项全部为真，也不会自动证明纪要完整准确，更不会替代 IETF 程序赋予它的地位。

会议纪要有提交、修订与公开的生命周期

RFC 2418要求每次工作组会议都有报告，由主席负责确保纪要形成，并把公开邮件列表档案视为工作记录的一部分。重要决定及其历史也应得到概括和保存。因而，会议纪要不是网页装饰，而是后来理解技术选择与程序过程的一块制度记忆。

现行主席会议材料指南明确纪要必须提交，列出允许的格式，并区分提交期限与更正窗口。8 月 13 日，一封关于 IETF 126 的秘书处提醒列出了在 8 月 14 日截止前仍缺纪要的会话，并给出 9 月 8 日的更正期限。那是一张过程中的快照，不能用来断言最终仍有缺失。它真正说明的是：尚未提交、已经接收、已经发布、经过更正、已被替代、当前可访问，是六种不同状态。

给每件材料一条可核验的绑定

一份最小完整性清单应逐项列出会议编号、工作组或会话、材料类型和稳定的逻辑标识；再把这个标识绑定到具体对象路径、MIME 类型、字节数和密码学哈希。它还应记录接收与发布时间、版本、当前或已更正/已替代状态、替代对象链接、最后一次成功公开检查，以及改变访问方式的修复或迁移事件。

更正应生成新版本，并追加明确的替代关系，而不是让旧哈希在沉默中指向新字节。面向读者的老链接可以继续跳到当前版本；需要复核引用的研究者，则能准确取得当时那一版。

清单也必须克制。可安全公开时，可以记录提交者角色，但不应暴露私人通信、个人网络信息、凭据或防护规则。它不是第二份纪要，不裁定会议记录是否忠实，也不给文件增加制度权威。它只让有限的运行事实能够被证伪。

在此基础上，公开检查可用低频、分批方式运行，并把失败分为：材料缺失、对象存在但链接未解析、解析候选错误、格式不符、访问控制或限流、校验和不符、版本已替代，以及原因未知。绿色结果也只表示：在记录的时间，声明对象被成功取回，格式、长度与哈希相符。这样的边界，恰恰让结果可信。

来源

  1. Jörg Ott 关于 IETF 84 纪要无法访问的报告
  2. Carsten Bormann 关于 rsync 副本中文件的回复
  3. 关于 PDF 与 HTM 后缀的后续说明
  4. IETF 工作人员的解析机制说明与修复
  5. IETF 126 会议纪要提交提醒
  6. IETF 会议材料指南
  7. RFC 2418
  8. IETF 84 会议档案
  9. AVTCORE 会议纪要地址
  10. MMUSIC 会议纪要地址
  11. Lu Heng 关于运行代码优先的论述