摘要

  • 9 月 19 日的 draft-ietf-opsawg-pcap-09 申请以 Historic 类别记录 PCAP v2，并申请 IANA 登记 application/pcap；它仍是草案，新类型尚非已完成的登记。
  • 9 月 23 日，负责审阅的区域主管表示未见对其审阅意见的答复，将状态退回“Revised I-D Needed”。意见包括：新类型究竟取代还是并存于 application/vnd.tcpdump.pcap，以及为何由 The Tcpdump Group 担任变更控制人。
  • 文件格式的历史定位、媒体类型的维护权和 LinkType 编号的分配，是三本不能混成一本的账。

IANA 已有一份 2011 年的 vendor-tree 登记，名称为 application/vnd.tcpdump.pcap，作者及变更控制人是 Guy Harris。新的工作组草案则拟把 application/pcap 放入标准树，并把 The Tcpdump Group 写在控制人一栏。草案确实提到了旧登记，但只是把链接放在安全章节；读者无法由此判断两者会并存、替换，还是承担不同用途。这不是文字洁癖：软件以哪个名称标记输出，档案馆认哪个名称，都会受结果影响。

审阅意见还指出旧版本纳秒时间戳魔数的字节排列写错。9 月修订稿列出了更正后的序列。因此，不能把 23 日状态倒退写成“更正被拒”。公开记录只显示主管没有看到对整份审阅的答复，要求继续修订；既没有 RFC 发布，也没有新的 IANA 登记完成。

Historic 所描述的是格式演进路线。PCAP v2 每个文件只能承载一种 LINKTYPE，文件头的结构也不便于直接拼接；另一个仍在起草的 pcapng 文档设计了可扩展的块结构。但 PCAP 草案同时明说，旧格式文件仍可加入新登记的链路层类型。第三份独立的 LinkType 草案还拟将编号列表纳入 IANA，并以专家审查分配部分编号。三个草案互相关联，出版状态与控制边界却不相同。

因此需要一份简短、可追溯的对照：输出与接收各用什么媒体类型、依据哪版登记、由谁变更、以哪版 LinkType 列表解读文件。Historic 不是“弃用全部旧文件”的命令；新媒体类型的申请也不自动夺走旧登记的地位。把交接讲清楚，才不会让标准名义替代实际兼容性和责任记录。

来源