1. Introduction (简介)
近年来的互联网协议已被精心设计为在特定领域易于扩展.特别是,许多协议(包括但不限于 HTTP [RFC2616] 和 MIME [RFC2045])能够承载任意标记的内容.
用于标记此类内容的机制是媒体类型 (media type),由顶级类型 (top-level type) 和子类型 (subtype) 组成,子类型进一步结构化为树 (trees).可选地,媒体类型可以定义伴随数据,称为参数 (parameters).
需要对这些标签进行注册过程,以便以合理有序,规范良好且公开的方式定义此类值的集合.
本文档指定了媒体类型注册的标准,并定义了在 Internet Assigned Numbers Authority (IANA) 中央注册表中注册媒体类型 (第 5 节) 以及媒体类型结构化后缀 (第 6 节) 的程序.
由这些程序管理的媒体类型注册表的位置为:
http://www.iana.org/assignments/media-types/
1.1 Historical Note (历史注记)
媒体类型注册过程最初被定义用于在异步互联网邮件环境中使用的媒体类型注册.在这种邮件环境中,需要限制可能的媒体类型数量,以在远程邮件系统的能力未知时增加互操作性的可能性.随着媒体类型在新环境中使用(在这些环境中媒体类型的激增不会妨碍互操作性),原始程序被证明过于限制性并必须进行泛化.这最初在 [RFC2048] 中完成,但那里定义的程序仍然是 MIME 文档集的一部分.媒体类型规范和注册程序现在是一个独立的文档,以明确它独立于 MIME.
可能需要将媒体类型的使用限制在特定环境中,或禁止在其他环境中使用.本规范以系统化的方式将此类限制纳入媒体类型注册中.有关更多讨论,请参见第 4.9 节.
1.2 Conventions Used in This Document (本文档使用的约定)
本文档中的关键词 "MUST","MUST NOT","REQUIRED","SHALL","SHALL NOT","SHOULD","SHOULD NOT","RECOMMENDED","MAY" 和 "OPTIONAL" 在全部大写时应按照 [RFC2119] 中的描述进行解释.它们也可能以小写或混合大小写形式出现,作为普通英语单词,没有任何规范性含义.
本规范使用 Augmented Backus-Naur Form (ABNF) [RFC5234] 表示法,包括该文档附录 B 中定义的核心规则.