1. 引言

近年来的 Internet 协议经过精心设计, 使其在某些方面易于扩展.特别是, 包括但不限于 HTTP [RFC2616] 和 MIME [RFC2045] 在内的许多协议, 都能够承载带有任意标签的内容.

用于标记此类内容的机制是媒体类型 (media type), 它由顶层类型和子类型组成, 并进一步组织为不同的树.媒体类型还可以选择性地定义伴随数据, 称为参数.

这些标签需要注册流程, 以便以相对有序,定义明确且公开的方式定义这类值的集合.

本文档规定媒体类型注册的准则, 并定义在 Internet Assigned Numbers Authority (IANA) 中央注册表中注册媒体类型 (第 5 节) 以及媒体类型结构化后缀 (第 6 节) 所使用的程序.

由这些程序管理的媒体类型注册表位置为:

http://www.iana.org/assignments/media-types/

1.1 历史说明

媒体类型注册流程最初是为注册异步 Internet 邮件环境中使用的媒体类型而定义的.在这种邮件环境中, 需要限制可能媒体类型的数量, 以便在未知远端邮件系统能力时提高互操作可能性.随着媒体类型被用于新的环境, 在这些环境中媒体类型激增并不会妨碍互操作性, 原始程序被证明过于受限, 因而必须泛化.这最初在 [RFC2048] 中完成, 但其中定义的程序仍是 MIME 文档集的一部分.媒体类型规范和注册程序现在成为单独文档, 以明确它独立于 MIME.

可能需要将媒体类型的使用限制在特定环境中, 或禁止在其他环境中使用.本规范以系统化方式将此类限制纳入媒体类型注册.更多讨论见第 4.9 节.

1.2 本文档使用的约定

本文档中的关键字 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" 和 "OPTIONAL" 在以全大写形式出现时, 应按 [RFC2119] 中的说明解释.它们也可能以小写或大小写混合形式作为普通英文词出现, 此时不具有任何规范性含义.

本规范使用增强巴科斯-诺尔范式 (Augmented Backus-Naur Form, ABNF) [RFC5234] 表示法, 包括该文档附录 B 中定义的核心规则.

---