摘要

  • RFC 2361 允许互联网应用用 audio/vnd.wave;codec=... 和 video/vnd.avi;codec=... 指向微软 WAVE、AVI 登记库中的既有值；IANA 所做的是重刊，而不是分配这些值。
  • 一个名称查得到，只能证明它在所查版本的登记库里有含义；它不能证明文件正文相符、解码器已安装、旧联系人仍有效，或执行与播放安全成功。

一段媒体到达系统，头部写着 video/vnd.avi;codec=CVID。目录里确实存在 CVID，机器上也恰好有一个自称支持 Cinepak 的组件。界面于是亮起“可播放”的图标。可点击之后，画面仍然没有出现。

这并不说明登记库错了。发送方可能写错参数，AVI 容器里可能装着另一种轨道，组件可能只支持不同变体，也可能在损坏的头部、异常尺寸或资源耗尽面前失败。它甚至可能已经解出帧，却没有把帧按正确时序交给显示层。名称完全正确，后续操作仍可全部失败。

RFC 2361 正是在这种断层中诞生。1998 年，大量音视频资产来自桌面与厂商生态，而不是为 RTP、RTSP 或 Web 设计的原生格式。WAVE 和 AVI 已有自己的编号与登记传统。互联网应用若要检索、描述或传输这些内容，首先必须用一个双方都能复现的方式说出“这声称是哪一种编解码器”。

这份 1998 年 6 月发布的 Informational RFC 没有重新规定任何比特流。它选择在 MIME 的 vendor tree 中引用外部登记库。audio/vnd.wave 指明 WAVE 名称空间，必填的 codec 参数选择一个 WAVE Format ID；video/vnd.avi 指明 AVI 名称空间，同一参数选择一个 AVI Codec ID。

这是一种有意克制的权力安排。微软维护原始登记库，用于避免编号冲突并公布已登记信息；MIME 提供可在互联网消息和协议中携带的语法；RFC 公布两者之间的映射。今天的 IANA 页面仍明确写着：IANA does not assign. Republication of values. IANA 页面承载了条目，不等于 IANA 创设、审查或推荐了每一种编解码器。

音频编号还藏着一个容易误判的细节。WAVE Format ID 是十六进制登记号；放入 MIME 参数时，保留十六进制数字，但去掉 0x。所以 MP3 的 0x0055 写作 audio/vnd.wave;codec=55。这里的 55 不是十进制五十五。若软件先按十进制解析再转换，便可能以十分整洁的代码解析到错误条目。

AVI 的身份规则不同。其 Codec ID 是 FourCC：四个区分大小写的 ASCII 字符，共 32 位。CVID、cvid 或被文字处理器“修正”过的形式，不能只因肉眼相近就视为相同。大小写、长度和原始字节都属于标识符本身，不是展示层装饰。

RFC 还给出 WAVE ID、FourCC 到 GUID 的确定性映射。WAVE 数字补入固定 GUID 模板的首个 32 位字段；FourCC 也放入同一位置。示例 H260 变成十六进制 30363248，看似倒序，是 DWORD 字节序造成的视觉结果。这个规则使两种软件表示能够指向同一登记身份。

但映射不会创造新证据。由 FourCC 算出的 GUID 不是一份新的比特流规范，也不证明本机组件实现了该格式。它更不能证明组件来源可靠、有权运行，或适合处理刚从网络收到的不可信文件。后来的 RFC 4122 规范了 UUID 的格式与术语，并没有让源标识符获得超出原登记值的语义。

登记库的历史属性同样关键。RFC 2361 坦率说明，这些是历史数据库。除非原登记人主动报告公司收购、地址、电话或联系人变化，旧信息通常不会更新。附录对截至 1998 年 1 月已登记的值提供权威快照，却不是一份面向未来的厂商存续证明。

稳定标识符本来就应当比公司与产品寿命更长。即使厂商消失，旧文件仍可被识别，这正是登记制度的价值。但不能反向推理：一个条目仍在，并不证明仍有维护中的解码器、可联络的安全团队、有效许可证或官方支持渠道。身份、治理、维护与责任是四份不同的记录。

头部也不是正文证据。MIME 参数由发送方提供；接收方仍须解析容器，读取实际轨道和内部标识符。头部可能缺失、错误或带有恶意诱导，文件也可能截断、混合，甚至专为触发解析器缺陷而构造。查表成功只说明输入字符串能解析到一个登记含义。

多年后的 RFC 6381 为其他“桶式”媒体类型定义复数 codecs 参数，并把类似边界说得更直接：参数若与媒体元素冲突，以正文为准；某些声明的轨道也未必是获得部分可用结果所必需的。RFC 6381 不取代 RFC 2361 的单数 vendor-tree 语法。它只是证明，声明与被检查内容之间的差距并没有随年代消失。

能力判断还需要另一套证据。本机可能安装了软件包，却未必选择它；选择了组件，未必能初始化；能初始化，未必支持具体配置、位深或封装；解出了样本，也未必正确呈现给目标用户。解码器版本、来源、支持矩阵、沙箱、内存与时间上限都不能从 FourCC 中读出。

传输协议也不会替这些缺口签字。RTSP 可以控制会话，HTTP 可以交付对象，RTP 可以承载实时数据。WAVE/AVI 标签帮助它们谈论传统媒体，却不是 RTP payload format、会话成功、完整下载、视听同步或用户接收的回执。

RFC 2361 的安全章节虽短，边界却极清楚：本文只是登记格式，没有处理这些格式的安全问题；每种格式都必须另行调查。由此可见，“目录命中”不能成为自动下载安装解码器、以高权限加载插件或取消资源限制的理由。

一条可审计链应分别保存原始 Content-Type、所查登记库版本、十六进制或 FourCC 解析规则、GUID 字节序、正文检查结果、冲突状态、实际解码器及其来源、安全策略、解码尝试、输出轨道和最终呈现。每一环都可能为真，而下一环仍未得到证明。

RFC 2361 真正完成的不是“一写标签就兼容”，而是有限的名称空间联邦。互联网可以准确引用一个不由自己治理的既有体系，同时不假装拥有其分配权、实现代码与运行结果。