摘要

  • RFC 9694 要求新的顶层媒体类型经过 Standards Action：边界必须清楚，跨子类型安全问题必须说明，并且至少要有一个真实子类型。
  • 斜杠左侧的名字会影响通用 type/* 分派、默认图标和应用选择，因此登记并不是只给 IANA 表格增加一行。
  • 管理层需要分别取得标准定义、注册状态、子类型、生产端发送、中间环节保留、精确解析、通用回退、内容校验、本地授权和实际结果的证据。

一个图标不是一次互操作成功

设想文件管理器不认识 haptics/hjif，却认识 haptics/*。它可能显示触觉媒体图标，或者调用一个能处理若干触觉格式的通用程序。此时，精确子类型还没有被理解，负载没有校验，设备也没有获得制造物理效果的授权。但顶层名字已经改变了分派和用户预期。

这正是 RFC 9694 把斜杠左侧新名字视为罕见事件的原因。它在 2025 年 3 月以 BCP 13 发布，并更新了媒体类型注册总规范 RFC 6838。绝大多数新格式应进入既有顶层类型；无处可归的离散数据仍可使用 application。新增顶层类别不是美化分类，而是要求生产者、中间件、操作系统、库、网关与用户代理共同认识一条新的格式家族边界。

因此，RFC 9694 要求的不只是一个听起来合理的名词。新类型必须由 Standards Track RFC 定义；IANA Considerations 必须请求写入顶层注册表；规范必须说明哪些格式属于该类别、哪些不属于；还必须解释全部或大量子类型共享的安全问题，并描述至少一个子类型。没有成员的类别没有运营意义。

IANA 顶层媒体类型注册表 让这种稀缺性变得可见。它采用 Standards Action，既列出 RFC 2046 延续下来的早期 MIME 家族，也列出 model、example、font 与 haptics 等后续类别。该表能证明名字、定义文件与子类型注册表存在，不能证明某个系统真的发送、保留或正确消费它。

类别边界必须经得起真实格式检验

顶层类别只有在能对多个子类型给出稳定预测时才有价值。清楚的成员资格标准帮助评审者判断一个新格式是否应放在该类别下，也帮助检查子类型登记是否提供了合适的信息。若边界无法说清，RFC 9694 把这种含混本身视为不适合成为顶层类型的强烈信号。

规范同时排除了若干捷径：顶层类型不能只是另一个注册空间的镜像，不能为文件扩展名或 URI scheme 做反向映射，也不能把编程语言或本体的类型系统整体搬进媒体类型。它不应为已广泛使用的格式制造别名，X- 前缀也不能让局部实验获得正式地位。这些限制保护共享命名空间，避免其变成依赖单一产品语境的便利标签集合。

广泛存在的非正式用法可以说明需求，却不能跳过标准路径。反过来，只有抽象类别而没有实际子类型压力，也无法证明生态确实需要它。RFC 9694 因而建议定义文件同时带入最初的一组真实子类型，让评审者用具体格式检验边界。

与之并行的 haptics 工作展示了这种方法。RFC 9695 定义顶层家族，而当前 IANA Media Types 注册表 列出 haptics/ivs、haptics/hjif 和 haptics/hmpg。这些是标准与注册事实，并不证明邮件客户端、浏览器、协作平台、内容网关或物理设备已经支持它们；RFC 9993 对 haptics/hmpg 的 RTP 处理也不是普遍部署证明。

通用分派有用，也会放大错误

RFC 9694 指出，媒体类型的主要任务是把数据格式分派给应用代码。通常应由完整 type、subtype 以及必要参数选定处理器；顶层类型偶尔可作为宽泛程序的试探性回退。图像、音频与视频软件早已使用这种方式，网页生成器也可能据此选择元素，桌面软件则选择不同图标。

便利性带来证据陷阱。一个正确图标只证明某条呈现规则触发了；某个应用被拉起，只证明分派找到了候选处理器。两者都不能证明精确子类型得到支持、参数被遵守、字节与声明一致、主动内容被隔离，或用户同意后续动作。RFC 9694 明确提醒：媒体类型声明可能受攻击者控制。

安全顺序必须带条件：保留完整类型与参数；核对精确子类型的登记与规范；应用协议约束和内容校验；决定当前场景是否允许顶层回退；把渲染、执行或物理输出留在本地策略之后；最后记录用户或下游系统实际观察到什么。内容探测可能发现声明不一致，但静默用探测结果替换原声明，也会制造新的权威混乱。

部署至少需要十张收据

可辩护的部署应区分十个状态：Standards Track 定义、IANA 顶层登记、子类型登记、生产端发送、中间环节保留、解析器精确认识、通用回退选择、内容校验、本地渲染或执行授权，以及实际结果。每一项都可能为真，而下一项为假。

这条证据链也解释成本如何扩散。类别发起者得到一致性与可见性；生产者承担迁移与测试；中间件可能重写或丢弃值；客户端厂商决定是否维护通用处理器；安全团队继承新的分类边缘；支持团队则处理“图标看起来正确但内容打不开”的工单。定义名字的机构并不运营所有消费它的实现，因此标准成功与部署失败完全可以同时发生。

RFC 8126 解释了用于高审查注册变更的 Standards Action。IETF Datatracker 与 RFC Editor 信息页 能证明文件状态和历史，却不是采用调查。部署证据必须来自生产端配置、协议记录、中间件测试、处理器清单、校验结果与实际行为。

Lu Heng 的最小初始规范论述在这里只是一种公开披露的编辑视角：共同层只保留互操作确实需要的最小部分，其余决定靠近运营者与实现。它不是 IETF 要求，也不能证明 RFC 9694 已部署；它只是帮助我们把共享类别与登记之后的本地判断分开。

来源