摘要

  • RFC 3023 引入 +xml 命名约定，让不同媒体类型在保留自身身份的同时，向接收端声明共同的 XML 表示层。
  • 后缀不是语义、信任或操作许可；完整类型、实际字节、解析、词汇验证、授权和最终效果仍需分别证明。

2001 年初，XML 的价值正在于它不是一个单一业务格式。电子商务消息、矢量图、配置语言都可以共享标签与树形结构，却要求完全不同的软件行为。若全部标为 application/xml，接收端知道语法，却失去应用契约；若每种格式都使用不透明名称，契约仍在，通用编辑器、搜索器和解析器却看不出它们共享 XML。

RFC 3023 选择在名称末尾加一个很小的接口。具体子类型保留，并以 +xml 结尾。加号左边继续标识格式；右边四个字符公开其底层表示。

一个名字保存两层知识

理解 application/foo+xml 的程序可以执行 foo 专属规则。不了解 foo、但了解 XML 的工具，则能检查末尾四个字符，决定是否进行受限的通用处理，例如解析、格式化、搜索或转换。

这种办法避免每个工具维护不断增长的 XML 词汇名单。RFC 也解释了为何不把“使用 XML”放进参数：参数通常只是修饰子类型，既有 MIME 分发器也很少按参数选择处理程序。另造顶层类型则会改变过多架构。后缀只携带最小的共同事实。

但完整媒体类型仍然不可替代。对不懂 XML 的处理器，+xml 完全不透明。RFC 3023 的附录因此强调，不能仅凭后缀赋予额外语义。application/foo 与 application/foo+xml 是两个独立类型；XML 版本可能同时改变语法和意义，支持前者不证明支持后者。

解析成功只产生结构收据

收到 +xml 类型，首先得到的是发送方标签。调用 XML 解析器后，接收方才能检验字节是否确实满足 XML 与编码规则。即使成功得到节点树，也没有证明命名空间受支持、文档符合业务 profile、签名可信、签名者有权，或操作最终完成。

名为 delete 的元素不会因为解析成功就获得删除权限。应用需要定义它的含义，策略需要验证主体权限，执行层需要尝试操作，结果层还要记录变化是否发生。同理，通用 XML 处理也不自动授权解析外部实体、访问网络资源、运行样式转换或无限分配内存。这些都是本地安全控制。

后缀最有价值之处，正是它没有承诺超出语法共享的东西。

临时约定后来成为正式注册结构

RFC 6838 把结构化语法后缀纳入媒体类型注册框架：子类型最后一个加号之后的字符标识已注册的共同语法。RFC 6839 正式登记 +xml，并说明两条处理路径：完整类型提供专门语义；当不需要这些语义、底层表示也无需额外知识即可解析时，后缀允许通用处理。

RFC 7303 后来取代 RFC 3023，但保留了原则。新的 XML 格式通常应使用 +xml，除非通用 XML 处理本身不合适。接收端可以发现后缀，调用解析器验证声明，再根据具体类型决定下一步。显示、编辑、安全、运行时和片段规则仍由具体类型控制。

今天的 IANA 注册表同时呈现这两层：+xml 有独立的结构化后缀条目，媒体类型表则包含大量彼此不同的 +xml 类型。共同结尾证明它们属于同一表示家族，不证明它们可以互换。

来源

Lu Heng 并非 RFC 3023 的作者，也没有为其背书；本文只公开使用其分析框架。