摘要

  • 1994 年 3 月的 RFC 1590把早期面向邮件的“MIME 类型”扩展为适用于多种应用的“媒体类型”。提案先贴到 ietf-types 邮件列表，满两周后可交 IANA 登记并获得其分支下的 OID。
  • 共用登记簿可以容纳更多名称；邮件阅读器仍可依据本环境的适用性建议，只支持较常见的一小组格式。共同叫法与实际读取能力分属不同决定。

柜台管名字，电脑管开不开得了

假设同一张照片同时来到邮箱和资料库。如果两边各取一个名字，交换时便要带上别名表。更糟的是，两种不同格式可能撞上同一个名称：程序以为收到熟人，打开才发现是陌生字节。给所有人准备一本共同的登记簿，听起来像文书工作；等名称已经写进软件，修改它的代价就远比填表高。

此前的 RFC 1521为 MIME 邮件正文规定了描述内容的办法。异步邮件有一个现实限制：发送方通常不知道收件人的程序懂哪些格式。使用普遍实现的少量类型，邮件更容易被读懂。但媒体名称开始跨出邮件，进入别的应用。Jon Postel 在 RFC 1590中调整了框架：名称可以广泛登记，某一类软件的推荐清单则由它自己的使用场景决定。

改名是第一步。文档把“MIME 类型”称为“媒体类型”，让类型与子类型成为跨应用共用的标识。登记簿回答“这串字节按什么格式命名”；接收端软件回答“我有没有实现读取它的程序”。邮件客户端不必因登记簿新增一种视频格式就突然学会播放视频，而视频服务也不用迁就旧邮件客户端的有限菜单。

新名称先去 ietf-types 邮件列表。提案阶段，子类型使用 x- 形式。公开讨论可以指出名称是否含糊、版本或配置文件的参照是否准确、OID 如何选、已知风险有哪些。专门用于有限场景的格式可以如实写明。这样做把命名冲突暴露在编码实现之前，而不是让用户多年后从错误文件里倒查。

两周后，提案人可把申请和资料送往 IANA。RFC 描述了合理审阅后的登记、IANA 分支下的 OID 分配，以及公开提供登记结果。附录表格要求填写类型、子类型、必要与可选参数、编码事项、风险、规格和联系人。格子不多，却为谁维护这个名字、它具体指向什么留下了可追踪的记录。

有些流行对象当时没有完整公开的字节规格。RFC 1590 允许申请人用具体软件包及版本来标明这种数据流。这个折中很务实：至少能区分“某程序某版本的文档”与一个空泛名称。接收端程序若想打开该数据流，仍得具备理解这些字节的代码。登记簿指出所指对象，解码器负责实际工作。

文件也为不同规模的决定安排了不同门槛。要新设一个顶层类型，需要 RFC 或足以成为 RFC 的文稿，并进入标准程序；在既有顶层类型下新增子类型，则走较轻的行政程序。若邮件生态希望推荐少数常见格式，可另发针对邮件的适用性说明。共用词典保持宽阔，各应用只把自己真正会用的工具放上桌。

这套设计的要害不是给登记机构添威风，而是缩小它必须做的事。公开审查名称、登记一次，避免各家软件各造一套冲突的标签。格式能否显示、播放或解析，最终仍由运行中的程序给出答案。两周的等候，是让一个可能流传很久的名字先接受一次公开问话。