互联网工程任务组 (IETF) N. Freed
征求意见稿：6838 Oracle
BCP：13 J. Klensin
废止：4288
类别：当前最佳实践 T. Hansen
ISSN：2070-1721 AT&T Laboratories
2013 年 1 月
媒体类型规范和注册程序
摘要
本文档定义了媒体类型的规范制定和注册程序，这些媒体类型
可用于 HTTP、MIME 以及其他 Internet 协议。
本备忘录状态
本备忘录记录了一项 Internet 当前最佳实践。
本文档是互联网工程任务组（IETF）的成果。它代表了 IETF
社区的共识。本文档已经过公开审查，并已由互联网工程指导组
（IESG）批准发布。有关 BCP 的更多信息可见
RFC 5741 第 2 节。
有关本文档当前状态、任何勘误，以及如何提供反馈的信息，
可从以下地址获得：
http://www.rfc-editor.org/info/rfc6838。
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Freed, et al. 当前最佳实践 [第 1 页]
RFC 6838 媒体类型注册 2013 年 1 月
目录
1. 引言 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. 历史说明 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. 本文档中使用的约定 . . . . . . . . . . . . . . . . . . . 4
2. 媒体类型注册前置事项 . . . . . . . . . . . . . . . . . . . 4
3. 注册树和子类型名称 . . . . . . . . . . . . . . . . . . . . 4
3.1. 标准树 . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. 厂商树 . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. 个人或自用树 . . . . . . . . . . . . . . . . . . . . . 6
3.4. 未注册的 x. 树 . . . . . . . . . . . . . . . . . . . . 7
3.5. 额外注册树 . . . . . . . . . . . . . . . . . . . . . . 7
4. 注册要求 . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. 功能性要求 . . . . . . . . . . . . . . . . . . . . . . 8
4.2. 命名要求 . . . . . . . . . . . . . . . . . . . . . . . 8
4.2.1. 文本媒体类型 . . . . . . . . . . . . . . . . . . . . 9
4.2.2. 图像媒体类型 . . . . . . . . . . . . . . . . . . . 10
4.2.3. 音频媒体类型 . . . . . . . . . . . . . . . . . . . 10
4.2.4. 视频媒体类型 . . . . . . . . . . . . . . . . . . . 10
4.2.5. 应用媒体类型 . . . . . . . . . . . . . . . . . . . 11
4.2.6. Multipart 和 Message 媒体类型 . . . . . . . . . . . 11
4.2.7. 额外顶级类型 . . . . . . . . . . . . . . . . . . . . 12
4.2.8. 结构化语法名称后缀 . . . . . . . . . . . . . . . . 12
4.2.9. 已弃用别名 . . . . . . . . . . . . . . . . . . . . . 13
4.3. 参数要求 . . . . . . . . . . . . . . . . . . . . . . . 13
4.4. 规范化和格式要求 . . . . . . . . . . . . . . . . . . . 14
4.5. 交换建议 . . . . . . . . . . . . . . . . . . . . . . . 15
4.6. 安全要求 . . . . . . . . . . . . . . . . . . . . . . . 15
4.7. XML 媒体类型特有的要求 . . . . . . . . . . . . . . . . 16
4.8. 编码要求 . . . . . . . . . . . . . . . . . . . . . . . 16
4.9. 使用和实现方面的非要求 . . . . . . . . . . . . . . . 17
4.10. 发布要求 . . . . . . . . . . . . . . . . . . . . . . . 18
4.11. 片段标识符要求 . . . . . . . . . . . . . . . . . . . . 18
4.12. 额外信息 . . . . . . . . . . . . . . . . . . . . . . . 19
5. 媒体类型注册程序 . . . . . . . . . . . . . . . . . . . . . 19
5.1. 初步社区审查 . . . . . . . . . . . . . . . . . . . . . 19
5.2. 向 IANA 提交请求 . . . . . . . . . . . . . . . . . . . 20
5.2.1. 临时注册 . . . . . . . . . . . . . . . . . . . . . 20
5.3. 审查和批准 . . . . . . . . . . . . . . . . . . . . . 21
5.4. 媒体类型注册的评论 . . . . . . . . . . . . . . . . . 21
5.5. 变更程序 . . . . . . . . . . . . . . . . . . . . . . 21
5.6. 注册模板 . . . . . . . . . . . . . . . . . . . . . . 22
6. 结构化语法后缀注册程序 . . . . . . . . . . . . . . . . . 23
6.1. 变更程序 . . . . . . . . . . . . . . . . . . . . . . 24
6.2. 结构化语法后缀注册模板 . . . . . . . . . . . . . . . 24
7. 安全考虑事项 . . . . . . . . . . . . . . . . . . . . . 25
8. IANA 考虑事项 . . . . . . . . . . . . . . . . . . . . . 26
9. 致谢 . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Freed, et al. 当前最佳实践 [第 2 页]
RFC 6838 媒体类型注册 2013 年 1 月
10. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. 规范性引用 . . . . . . . . . . . . . . . . . . . . . . 27
10.2. 资料性引用 . . . . . . . . . . . . . . . . . . . . . . 28
附录 A. 祖父化媒体类型 . . . . . . . . . . . . . . . . . . . 30
附录 B. 自 RFC 4288 以来的变更 . . . . . . . . . . . . . 30
1. 引言
近来的 Internet 协议在设计时已经仔细考虑，使其在某些
方面易于扩展。特别是，包括但不限于 HTTP [RFC2616] 和
MIME [RFC2045] 在内的许多协议，都能够承载任意带标签的内容。
用于给这类内容加标签的机制是媒体类型，它由顶级类型和
子类型组成，并进一步组织成树。媒体类型还可以选择性地
定义称为参数的配套数据。
这些标签需要一个注册过程，以便以相当有序、明确规定且
公开的方式定义这类取值的集合。
本文档规定了媒体类型注册的准则，并定义了在 Internet
Assigned Numbers Authority（IANA）中央注册表中注册媒体类型
（第 5 节）以及媒体类型结构化后缀（第 6 节）所使用的程序。
由这些程序管理的媒体类型注册表的位置为：
http://www.iana.org/assignments/media-types/
1.1. 历史说明
媒体类型注册过程最初是为在异步 Internet 邮件环境中使用的
媒体类型注册而定义的。在这种邮件环境中，需要限制可能的
媒体类型数量，以便在远端邮件系统能力未知时提高互操作的
可能性。随着媒体类型被用于新的环境，在这些环境中媒体
类型的激增并不会阻碍互操作，原有程序被证明过于严格，
因而必须加以泛化。这最初是在 [RFC2048] 中完成的，
但那里定义的程序仍然是 MIME 文档集的一部分。媒体类型
规范和注册程序现在是一份独立文档，以明确其独立于 MIME。
Freed, et al. 当前最佳实践 [第 3 页]
RFC 6838 媒体类型注册 2013 年 1 月
可能希望将媒体类型的使用限制于特定环境，或禁止其在其他
环境中使用。本规范以系统化方式把这些限制纳入媒体类型
注册。更多讨论见第 4.9 节。
1.2. 本文档中使用的约定
本文档中的关键词 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、
"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和
"OPTIONAL"，当以全大写形式出现时，均应按 [RFC2119] 中的说明
进行解释。它们也可能以小写或大小写混合形式作为普通英语
词汇出现，此时不具有任何规范性含义。
本规范使用扩充巴科斯-瑙尔范式（ABNF）[RFC5234] 记法，
包括该文档附录 B 中定义的核心规则。
2. 媒体类型注册前置事项
注册一个或多个新的媒体类型从构造注册提案开始。注册可以
发生在若干不同的注册树中，这些注册树具有不同的要求，
如下所述。一般而言，新的注册提案会以适合相关注册树的
方式被分发和审查。如果提案可接受，则注册该媒体类型。
以下各节说明用于不同注册树的要求和程序。
3. 注册树和子类型名称
为了提高注册过程的效率和灵活性，可以注册不同结构的子类型
名称，以适应不同的自然要求，例如，被推荐给 Internet 社区
广泛支持和实现的子类型，或用于传送与专有软件相关文件的
子类型。以下各小节定义了若干注册“树”，它们通过使用带
方面的名称来区分，例如，以 "tree." 前缀开头的子类型名称。
注意，在本文档之前定义的某些媒体类型并不符合下文所述的
命名约定。相关讨论见附录
A。
3.1. 标准树
标准树用于 Internet 社区普遍感兴趣的类型。标准树中的注册
必须符合以下两种情况之一：
Freed, et al. 当前最佳实践 [第 4 页]
RFC 6838 媒体类型注册 2013 年 1 月
1. 对于与 IETF 规范相关联的注册，由 IESG 直接批准；或
2. 由公认的标准相关组织使用“需要规范”的 IANA 注册策略
[RFC5226] 进行注册
（这意味着专家审查）。
第一种程序用于来自 IETF 共识文档的注册，或在少数情况下，
当注册祖父化（见附录 A）和/或其他不完整注册符合
Internet 社区利益时使用。注册提案必须作为 RFC 发布。当注册
RFC 属于 IETF 流时，它必须具有 IETF 共识；这种共识可以通过
标准轨道、BCP、资料性或实验性状态来获得。发布在非 IETF RFC
流中的注册也被允许，但需要 IESG 批准。注册既可以是一份
独立的“仅注册”RFC，也可以并入某种更一般的规范中。
在第二种情况下，IESG 会就注册提交者是否代表公认的标准相关
组织作出一次性决定；之后，媒体类型审查员（指定专家或一组
指定专家）会按本文档中的规定执行专家审查。来自同一来源的
后续提交不再涉及 IESG。该格式必须由提交该注册的标准相关
组织所产生的正式标准规范加以描述。
标准树中的媒体类型不得具有带方面的名称，除非它们使用
附录 A 中描述的过程被祖父化。
注册在标准树中的媒体类型的“所有者”被假定为标准相关组织
本身。规范的修改或变更使用与初始注册所需相同级别的处理
（例如，作为标准轨道提交的注册可以在另一个标准轨道 RFC 中
修订，但不能在资料性 RFC 中修订）。
来自公认标准相关组织的标准树注册会直接提交给 IANA，在批准
之前它们将接受专家审查 [RFC5226]。在这种情况下，
专家审查员将尤其确保所需规范提供了充分的文档。
Freed, et al. 当前最佳实践 [第 5 页]
RFC 6838 媒体类型注册 2013 年 1 月
3.2. 厂商树
厂商树用于与公开可获得的产品相关联的媒体类型。在此语境中，
“厂商”和“生产者”被作非常宽泛的解释，并被视为等价。
注意，行业联盟以及不符合公认标准相关组织资格的非商业实体，
也完全可以在厂商树中注册媒体类型。
任何需要交换与某个产品或一组产品相关文件的人，都可以将
注册放入厂商树。然而，该注册恰当地说属于生产采用所注册
类型的软件的厂商或组织，并且该厂商或组织可以随时选择主张
对由第三方完成的注册的所有权，以便修正或更新它。更多信息
见第 5.5 节。
当第三方代表他人注册一种类型时，在注册的 Change Controller
字段中应该注明这两个实体。对此的一种可能格式是
"Foo, on behalf of Bar"。
厂商树注册将通过前导方面 "vnd." 来区分。随后可以由注册人
自行决定，接一个来自知名生产者的媒体子类型名称（例如
"vnd.mudpie"），或者接一个经 IANA 批准的生产者名称标识，
后面再跟媒体类型或产品标识（例如 vnd.bigcompany.funnypictures）。
虽然对要在厂商树中注册的媒体类型进行公开展示和审查不是
必需的，但鼓励使用 media-types@iana.org 邮件列表进行审查，
以提高这些规范的质量。厂商树中的注册可以直接提交给 IANA，
在批准之前它们将接受专家审查 [RFC5226]。
3.3. 个人或自用树
对于以实验方式创建的媒体类型，或作为未商业发行产品一部分
的媒体类型，可以在个人或自用树中注册。这些注册通过前导
方面 "prs." 加以区分。
“个人”注册及相关规范的所有者，是进行该注册的人或实体，
或是按下文所述已被转移责任的人或实体。
Freed, et al. 当前最佳实践 [第 6 页]
RFC 6838 媒体类型注册 2013 年 1 月
虽然对要在个人树中注册的媒体类型进行公开展示和审查不是
必需的，但鼓励使用 media-types@iana.org 邮件列表（见
第 5.1 节）进行审查，以提高这些规范的质量。个人树中的
注册可以直接提交给 IANA，在批准之前它们将接受专家审查
[RFC5226]。
3.4. 未注册的 x. 树
以 "x." 作为第一个方面的子类型名称，可以用于专门供私有、
本地环境使用的类型。此树中的类型不能注册，并且仅意在由
交换双方主动同意后使用。
然而，鉴于上文描述的厂商树和个人树的简化注册程序，几乎
很少（如果有的话）需要使用未注册类型。因此，强烈不鼓励
使用 "x." 树中的类型。
注意，以 "x-" 开头的类型名称不再被视为此树的成员（见
[RFC6648]）。还要注意，如果某个普遍有用且广泛部署的类型
错误地以 "x-" 名称前缀出现，则可以按照附录 A 中
定义的程序，使用其当前名称在替代树中注册。
3.5. 额外注册树
根据社区不时产生的需要，可以通过 IETF 标准行动创建新的
顶级注册树。这里明确假定，这些树可被创建出来，以便由知名
永久组织进行外部注册和管理；例如，科学学会可以注册特定于
其所涵盖科学领域的媒体类型。一般而言，对这些额外注册树之
一中的规范进行审查，其质量应当等同于由公认标准相关组织在
标准树中进行的注册。当 IETF 执行这种审查时，需要考虑请求
组织在相关媒体类型主题方面更高的专业性。
4. 注册要求
所有媒体类型注册都预期符合以下各节列出的各种要求。注意，
具体要求有时会随注册树而变化，详情同样见以下各节。
Freed, et al. 当前最佳实践 [第 7 页]
RFC 6838 媒体类型注册 2013 年 1 月
4.1. 功能性要求
媒体类型必须作为实际的媒体格式发挥作用。不允许注册那些更
适合被看作传输编码、字符集，或另一种类型的若干独立实体
集合的事物。例如，尽管存在用于解码 base64 传输编码
[RFC2045] 的应用，base64 不能注册为媒体类型。
此要求适用于任何相关注册树。
4.2. 命名要求
所有已注册的媒体类型都必须被分配顶级类型和子类型名称。
这些名称的组合用于唯一标识媒体类型，而子类型名称方面
（或其不存在）用于标识注册树。顶级类型和子类型名称均不
区分大小写。
类型和子类型名称必须符合以下 ABNF：
type-name = restricted-name
subtype-name = restricted-name
restricted-name = restricted-name-first *126restricted-name-chars
restricted-name-first = ALPHA / DIGIT
restricted-name-chars = ALPHA / DIGIT / "!" / "#" /
"$" / "&" / "-" / "^" / "_"
restricted-name-chars =/ "." ; 第一个点之前的字符始终
; 指定方面名称
restricted-name-chars =/ "+" ; 最后一个加号之后的字符始终
; 指定结构化语法后缀
注意，此语法比 [RFC2045] 第 5.1 节 或 [RFC4288]
第 4.2 节 的 ABNF 所允许的语法稍更严格。还要注意，虽然此
语法允许最长 127 个字符的名称，但实现限制可能会使这样的
长名称产生问题。因此，<type-name> 和 <subtype-name> 应该
限制为 64 个字符。
虽然名称语法把 "." 视为等同于任何其他字符，但任何初始
"." 之前的字符始终指定注册方面。注意，这意味着无方面的
标准树注册不能在子类型名称中使用句点。
Freed, et al. 当前最佳实践 [第 8 页]
RFC 6838 媒体类型注册 2013 年 1 月
类似地，子类型名称中的最后一个 "+" 引入结构化语法说明符
后缀。结构化语法后缀要求见第 4.2.8 节。
虽然可以给某个媒体类型分配额外名称，但不鼓励使用不同名称
来标识同一媒体类型。
这些要求适用于任何相关注册树。
顶级类型的选择必须考虑相关媒体类型的性质。顶级类型的新
子类型必须符合该顶级类型的限制（如有）。以下各节说明初始
顶级类型集合中的每一项及其相关限制。此外，各种协议，包括
但不限于 HTTP 和 MIME，可以对其能够传输的媒体类型施加额外
限制。（MIME 所施加限制的更多信息见 [RFC2046]。）
4.2.1. 文本媒体类型
"text" 顶级类型用于发送主要在形式上为文本的材料。
许多文本子类型，特别包括 [RFC2046] 中定义的纯文本通用
子类型 "text/plain"，都定义了 "charset" 参数。如果为某个
特定文本子类型定义了 "charset" 参数，则必须使用它来指定
按 [RFC2978] 中所列程序定义的 charset 名称。
按 [RFC6657] 的规定，当字符集信息在载荷内部传输时
（例如 "text/xml" 中的情况），不应该指定 "charset" 参数。
如果指定了 "charset" 参数，它应该是必需参数，从而消除指定
默认值的选择。如果尽管有此建议，仍有充分理由让该参数成为
可选参数，则每个子类型可以指定自己的默认值；或者，也可以
指定没有默认值。最后，应该选择 "UTF-8" charset [RFC3629]
作为默认值。有关 "charset" 参数与文本子类型结合使用的更多
信息，见 [RFC6657]。
无论选择哪种方法，所有新的 text/* 注册都必须清楚说明
charset 如何确定；不再允许依赖 [RFC2046] 第 4.1.2 节
定义的 US-ASCII 默认值。
Freed, et al. 当前最佳实践 [第 9 页]
RFC 6838 媒体类型注册 2013 年 1 月
permitted. 如果需要说明性文本，则应该将其放在注册的额外
信息部分中。
纯文本不提供也不允许格式化命令、字体属性规范、处理指令、
解释指令或内容标记。纯文本只是被视为字符的线性序列，可能
被换行符或分页符中断。纯文本可以允许多个字符堆叠在文本中
的同一位置。阿拉伯文和希伯来文等书写系统中的纯文本，也可
以包含允许任意混合不同书写方向文本片段的机制。
除纯文本以外，还有许多格式可用于表示可称为“富文本”的内容。
许多这类表示的一个有趣特征是，即使没有解释它们的软件，也
在某种程度上可读。把它们在最高层次上与图像、音频或以不可
读形式表示的文本等不可读数据区分开来，是有用的。在没有
合适解释软件的情况下，向用户呈现 "text" 的子类型是合理的，
而对大多数非文本数据这样做并不合理。此类格式化文本数据可
以使用 "text" 的子类型来表示。
4.2.2. 图像媒体类型
"image" 顶级类型表示内容指定一个或多个单独图像。子类型命名
具体的图像格式。
4.2.3. 音频媒体类型
"audio" 顶级类型表示内容包含音频数据。子类型命名具体的音频
格式。
4.2.4. 视频媒体类型
"video" 顶级类型表示内容指定随时间变化的图片图像，可能带有
颜色和协调的声音。术语“video”在其最一般意义上使用，而不是
指任何特定技术或格式，并且无意排除诸如以紧凑方式编码的
动画绘图等子类型。
注意，虽然通常不鼓励在单个正文中混合多种媒体 [RFC2046]，
但公认许多视频格式包含同步音频和/或文本的表示，而这对于
"video" 的子类型是明确允许的。
Freed, et al. 当前最佳实践 [第 10 页]
RFC 6838 媒体类型注册 2013 年 1 月
4.2.5. 应用媒体类型
"application" 顶级类型用于不适合任何其他类型名称的离散数据，
尤其用于由某类应用程序处理的数据。这类信息必须先由应用
处理，用户才能查看或使用。"application" 类型名称的预期用途
包括但不限于文件传输、电子表格、演示文稿、日程数据，以及
用于“活动”（计算性）材料的语言。（最后一种尤其可能造成
安全问题，实现者必须理解这些问题。[RFC2046] 中的
"application/postscript" 媒体类型注册提供了如何处理这些问题
的良好示例。）
例如，会议日程安排程序可以为拟议会议日期的信息定义一种
标准表示。智能用户代理会使用这些信息与用户进行对话，然后
可能基于该对话发送额外材料。更一般地说，已经开发出几种
“活动”语言，在这些语言中，以适当专门化语言编写的程序会被
传送到远程位置，并在接收者环境中自动运行。这类应用可以被
定义为 "application" 顶级类型的子类型。
"application" 的子类型通常是数据所面向应用的名称，或包含该
应用名称的一部分。然而，这并不意味着任何应用程序名称都可
以随意用作 "application" 的子类型；该子类型需要注册。
4.2.6. Multipart 和 Message 媒体类型
Multipart 和 message 是复合类型；也就是说，它们提供了一种
封装零个或多个对象的方法，每个对象都是独立的媒体类型。
multipart 和 message 的所有子类型都必须符合 [RFC2046]
中规定并由 [RFC6532] 第 3.5 节 修订的语法规则和其他要求。
Freed, et al. 当前最佳实践 [第 11 页]
RFC 6838 媒体类型注册 2013 年 1 月
4.2.7. 额外顶级类型
在某些情况下，新的媒体类型可能“不适合”任何当前定义的顶级
类型名称。这类情况预计相当罕见。然而，如果确实出现这种
情况，可以定义新的类型名称以适应它。新的顶级类型名称必须
通过标准轨道 RFC 定义；不能使用任何其他机制来定义额外类型
名称。
4.2.8. 结构化语法名称后缀
MIME 中的 XML [RFC3023] 定义了对媒体类型定义的第一种这种
增补，以额外指定该媒体类型的底层结构。引用如下：
本文档还标准化了一种约定（使用后缀
'+xml'）用于命名媒体类型……当这些媒体类型
表示 XML MIME（多用途 Internet 邮件扩展）
实体时。
也就是说，它规定了一个后缀（在该例中为 "+xml"），追加到
基础子类型名称之后。
自该文档发布以来，事实上的实践已经形成，即对其他知名的
结构化语法使用这种后缀约定。尤其是，已经注册了带有
"+der"、"+fastinfoset" 和 "+json" 等后缀的媒体类型。本规范
将这种实践正式化，并建立结构化类型名称后缀注册表。
关于某个结构化类型名称后缀是否可注册，主要准则是：它应由
易于获得的描述加以说明，最好是在由既有标准相关组织发布的
文档中说明，并且具有可在 RFC 的规范性引用部分使用的引用。
使用某个具名结构化语法的媒体类型，在注册时应该使用该结构
化语法对应的已注册 "+suffix"。同样地，不得给媒体类型赋予
包含其并未实际采用的结构化语法后缀的名称。鉴于可能与未来
的后缀定义发生冲突，不应该使用尚未注册的结构化语法的
"+suffix" 构造。
Freed, et al. 当前最佳实践 [第 12 页]
RFC 6838 媒体类型注册 2013 年 1 月
4.2.9. 已弃用别名
在某些情况下，单个媒体类型可能在注册之前已以多个名称得到
广泛部署。在这种情况下，必须为该媒体类型选择一个首选名称，
并且应用必须使用该名称以符合该类型的注册。不过，可以提供
一份该类型已知的已弃用别名列表作为额外信息，以帮助应用
正确处理该媒体类型。
4.3. 参数要求
媒体类型可以选择使用一个或多个媒体类型参数；或者，由于其
是某个内容类型的子类型，而该内容类型定义了一组适用于其任
何子类型的参数，某些参数可以自动对该媒体类型可用。在任一
情况下，当媒体类型注册在标准树中时，任何参数的名称、取值
和含义都必须完整规定；当媒体类型注册在厂商树或个人树中时，
则应该尽可能完整地规定。
参数名称具有与媒体类型名称和值相同的语法：
parameter-name = restricted-name
注意，此语法比 [RFC2045] 中的 ABNF 以及由 [RFC2231] 修订后的
ABNF 所允许的语法稍更严格。
参数名称不区分大小写，并且其出现顺序不附带任何含义。特定
参数被指定多次是一种错误。
参数值没有定义的语法。因此，注册必须指定参数值语法。此外，
某些传输会对参数值语法施加限制，因此需要注意限制可能有
问题的语法的使用；例如，纯二进制值参数虽然在某些协议中
允许，但最好避免。
注意，协议可以根据其选择表示参数的方式，对参数值语法施加
进一步限制。MIME [RFC2045] [RFC2231] 和 HTTP [RFC2045] [RFC5987]
都允许二进制参数以及以特定 charset 表示的参数值，但其他
协议可能没有这么灵活。
不应该把新参数定义为向标准树中注册的类型引入新功能的方式，
尽管可以添加新参数来传达不以其他方式改变现有功能的额外
信息。
Freed, et al. 当前最佳实践 [第 13 页]
RFC 6838 媒体类型注册 2013 年 1 月
这方面的一个示例是 "revision" 参数，用于指示诸如 JPEG 之类
外部规范的修订级别。对厂商树或个人树中注册的媒体类型，也
鼓励类似行为，但不是必需的。
对参数的变更（包括引入新参数）按与媒体类型其他变更相同的
方式管理；见第 5.5 节。
4.4. 规范化和格式要求
所有已注册的媒体类型都必须采用单一的规范数据格式，而不论
注册树为何。
对于所有注册在标准树中的类型，必须存在该媒体类型格式的
永久且易于获得的公开规范。该规范必须提供足够细节，使使用
该媒体类型的独立实现之间能够互操作。该规范至少必须被媒体
类型注册提案本身引用，如果没有实际包含在其中的话。
对于注册在厂商树和个人树中的媒体类型，其格式和处理细节的
规范可以公开，也可以不公开。这类注册被明确允许将注册中的
信息限制为说明哪些软件及版本产生或处理这类媒体类型。因此，
鼓励在注册中引用或包含格式规范，但不是必需的。不过要注意，
一个有意义规范的公开可得性，往往会造成这样的差别：只是
预留一个名称以免与其他用途冲突，还是具备由其他实现支持该
媒体类型并与之进行有用互操作的潜力。
某些媒体类型涉及专利技术的使用。涉及专利技术的媒体类型
注册是明确允许的。但是，当某个媒体类型的规范是标准轨道
协议的一部分时，必须遵守 BCP
79 [RFC3979] 和 BCP 78 [RFC5378] 中关于在
IETF 标准轨道协议中使用专利技术的限制。此外，使用标准树的
其他标准相关组织，可能有自己的知识产权规则，必须在其注册
中遵守。
鼓励对厂商树和个人树中的注册进行知识产权（IPR）披露，但
不是必需的。
Freed, et al. 当前最佳实践 [第 14 页]
RFC 6838 媒体类型注册 2013 年 1 月
4.5. 交换建议
理想情况下，媒体类型应被定义为尽可能在众多系统和应用之间
互操作。然而，某些媒体类型不可避免地会在不同平台之间的
互操作方面出现问题。不同版本、字节顺序以及网关处理细节
都可能并且将会产生问题。
不要求媒体类型具有普遍互操作性，但只要可能，就应该识别
已知的互操作问题。发布一种媒体类型并不要求对互操作性进行
穷尽审查，并且互操作性考虑事项部分会持续接受评估。
本小节中的建议适用于任何相关注册树。
4.6. 安全要求
对于所有注册在标准树中的类型，都必须进行安全问题分析。
鼓励但不要求对注册在厂商树或个人树中的媒体类型进行类似
分析。然而，无论是否已经进行了安全分析，所有安全问题描述
都必须尽可能准确，而不论注册树为何。特别是，安全考虑事项
不得声明“没有与此类型相关联的安全问题”。厂商树或个人树中
类型的安全考虑事项可以说明“与此类型相关联的安全问题尚未
评估”。
完全没有要求任何树中注册的媒体类型必须安全或完全无风险。
尽管如此，媒体类型注册中必须识别所有已知的安全风险，同样
不论注册树为何。
所有注册的安全考虑事项部分都会持续接受评估和修改，尤其是
可以通过下文第 5.4 节中描述的“媒体类型评论”机制进行扩展。
在媒体类型安全分析中需要检查和描述的一些问题包括：
o 复杂媒体类型可能包含用于发起对接收者文件或其他资源执行
操作的指令。在许多情况下，会允许发起者以不受限制的方式
指定任意操作，而这些操作随后可能产生毁灭性影响。有关这
类指令以及如何在媒体类型注册中描述它们的示例，见
[RFC2046] 中 application/postscript 媒体类型的注册。
Freed, et al. 当前最佳实践 [第 15 页]
RFC 6838 媒体类型注册 2013 年 1 月
o 任何安全分析都必须说明它们是否采用这类“活动内容”；如果
采用，则必须说明已经采取哪些步骤，或该媒体类型的应用
必须采取哪些步骤，以保护媒体类型的用户免受损害。
o 复杂媒体类型可能包含用于发起某些操作的指令，这些操作
虽然不会直接伤害接收者，但可能导致信息泄露，从而促进
后续攻击，或者以某种方式侵犯接收者的隐私。同样，
application/postscript 媒体类型的注册说明了如何处理这类
指令。
o 使用压缩的媒体类型可能提供这样一种机会：发送少量数据，
但当接收并求值后，会巨大膨胀并消耗接收者的全部资源。
所有媒体类型都应该说明它们是否采用压缩；如果采用，则
应该讨论需要采取哪些步骤来避免此类攻击。
o 某种媒体类型可能面向需要某种安全保证但其自身并未提供
必要安全机制的应用。例如，可以为敏感医疗信息的存储定义
一种媒体类型，而这种信息反过来需要外部的机密性和完整性
保护服务；或者该类型被设计为仅在安全环境中使用。类型
应始终在其安全考虑事项中记录它们是否需要这类服务。
4.7. XML 媒体类型特有的要求
XML 媒体类型的注册还有许多特有的额外要求。这些要求在
[RFC3023] 中规定。
4.8. 编码要求
某些传输会限制其能够承载的数据类型。例如，Internet 邮件
传统上限于 7bit US-ASCII 文本。编码方案常被用于绕过这类
传输限制。
Freed, et al. 当前最佳实践 [第 16 页]
RFC 6838 媒体类型注册 2013 年 1 月
因此，在注册中注明媒体类型可由何种数据组成是有用的。为此
提供了一个“编码考虑事项”字段。该字段的可能取值为：
7bit： 媒体类型的内容仅由以 CRLF 分隔的 7bit US-ASCII
文本组成。
8bit： 媒体类型的内容仅由以 CRLF 分隔的 8bit 文本组成。
binary： 内容由不受限制的八位字节序列组成。
framed： 内容由一系列帧或分组组成，没有内部成帧或对齐
指示符。需要额外的带外信息才能正确解释数据，包括但
不一定限于了解连续帧之间的边界以及了解传输机制。注意，
这种媒体类型不能简单地存储在文件中，或作为简单的八位
字节流传输；因此，此类媒体类型不适合在许多传统协议中
使用。采用 framed 编码的一种常用传输是实时传输协议 RTP。
为使用 RTP 传输而定义的 framed 编码的额外规则见
[RFC4855]。
关于 7bit 和 8bit 文本的额外限制见 [RFC2046] 第
4.1.1 节。
4.9. 使用和实现方面的非要求
在异步邮件环境中，发送者经常无法获得远端邮件代理能力的
信息，因此通过把所用媒体类型限制为预期会被广泛实现的
“通用”格式，可获得最大互操作性。过去曾以此为理由主张限制
可能的媒体类型数量，并导致媒体类型注册过程对注册者而言
存在显著障碍和延迟。
然而，对“通用”媒体类型的需求并不要求限制新媒体类型的注册。
如果针对某个特定应用推荐使用一组有限的媒体类型，则应由
专门针对该应用和/或环境的独立适用性声明来提出这一点。
因此，对某种媒体类型的普遍支持和实现，并不是注册要求。
但是，如果某种媒体类型明确意在受限使用，则必须在其注册中
Freed, et al. 当前最佳实践 [第 17 页]
RFC 6838 媒体类型注册 2013 年 1 月
注明这一点。为此提供了“使用限制”字段。
4.10. 发布要求
由 IETF 自身注册在标准树中的媒体类型必须作为 RFC 发布。
厂商和个人媒体类型注册允许作为 RFC 发布，但不是必需的。
在所有情况下，IANA 都会保留所有媒体类型注册的副本，并将
它们作为媒体类型注册树本身的一部分“发布”。
如前所述，对于由其他标准相关组织产生的文档中定义的媒体
类型，其标准树注册必须由该组织产生的正式标准规范加以描述。
此外，注册模板上的任何版权都必须允许 IANA 将其复制到 IANA
注册表中。
除 IETF 在标准树中的注册外，媒体类型的注册并不意味着 IANA
或 IETF 的背书、批准或推荐，甚至也不表示规范足够充分的
认证。若要成为 IETF 标准，协议或数据对象必须经过 IETF
标准流程。虽然在适当情况下这会提供额外保证，但对于便捷的
媒体类型注册而言，该流程过于困难且耗时过长。
标准树存在于那些确实需要由公认标准相关组织进行实质性审查
和批准过程的媒体类型。厂商树和个人树存在于那些不需要这类
过程的媒体类型。预期 IETF 会不时发布针对特定应用的适用性
声明，建议实现和支持在这些语境中已被证明特别有用的媒体
类型。
如上所述，注册顶级类型需要 IETF 的标准行动，因此也需要发布
一份标准轨道 RFC。
4.11. 片段标识符要求
媒体类型注册可以规定应用应该如何解释与该媒体类型相关联的
片段标识符（在 [RFC3986] 第 3.5 节中规定）。
Freed, et al. 当前最佳实践 [第 18 页]
RFC 6838 媒体类型注册 2013 年 1 月
鼓励媒体类型采用语义相近媒体类型所使用的片段标识符方案。
特别是，使用带有已注册 "+suffix" 的具名结构化语法的媒体
类型，必须遵循结构化语法后缀注册中给出的任何片段标识符
规则。
4.12. 额外信息
如果可用，媒体类型规范中应该包含各种可选信息：
o 魔数（长度、八位字节值）。魔数是始终出现在文件中某个给定
位置的字节序列，因此可用于识别实体属于某个给定媒体类型。
o 在一个或多个平台上常用、用于表示某个文件包含给定媒体类型
的文件扩展名。
o Mac OS 文件类型代码（4 个八位字节），用于标记包含给定媒体
类型的文件。关于 Macintosh 文件类型代码及其目的的一些
讨论，可见 [MacOSFileTypes]。
对于标准树中的注册，这些额外信息可以在该媒体类型格式的
正式规范中提供。建议通过把 IANA 媒体类型注册表单纳入格式
规范本身来做到这一点。
5. 媒体类型注册程序
媒体类型注册程序不是正式标准流程，而是一种行政程序，旨在
允许社区评论和合理性检查，同时避免过度延迟。
对于标准树中的所有 IETF 注册，需要遵循正常的 IETF 流程。
发布 Internet-Draft 是必要的第一步，随后如下面所讨论的那样
发布到 media-types@iana.org 列表。
5.1. 初步社区审查
标准树中潜在媒体类型注册的通知应该发送到 media-types@iana.org
邮件列表进行审查。该邮件列表的建立目的，是审查提议的媒体
类型和访问类型。其他树中的注册也可以发送到该列表进行审查；
这样做完全是可选的，但强烈鼓励。
Freed, et al. 当前最佳实践 [第 19 页]
RFC 6838 媒体类型注册 2013 年 1 月
公开发布到该列表的意图是，就类型/子类型名称的选择、引用
相对于版本和外部概要信息的明确性，以及任何互操作性或安全
考虑事项的审查，征求评论和反馈。提交者可以随时提交修订后
的注册提案，或完全放弃注册。
5.2. 向 IANA 提交请求
由 IETF 自身注册在标准树中的媒体类型，必须作为正常标准流程
的一部分由 IESG 审查和批准。公认标准相关组织的标准树注册，
以及厂商树和个人树中的注册，均直接提交给 IANA，除非作为
联络协议的一部分作出了其他安排。在任一情况下，都强烈鼓励
在提交之前将注册发布到 media-types@iana.org 列表进行审查。
注册请求可以发送到 iana@iana.org。也可使用注册请求网页表单：
http://www.iana.org/form/media-types
5.2.1. 临时注册
标准化过程通常需要相当长的时间才能完成。为了便利原型设计
和测试，在流程早期分配标识符通常很有帮助，包括但不限于
媒体类型。这样，标准开发期间使用的标识符在流程完成后可以
保持不变，并且实现和文档无需更新。
因此，提供了临时注册流程，以支持在标准树中早期分配媒体
类型名称。可以向 IANA 提交标准树类型的临时注册。此类注册
中唯一必需的字段是媒体类型名称和联系信息（包括标准相关
组织名称）。
收到临时注册后，IANA 将检查名称和联系信息，然后在一个单独
的公开可见临时注册列表中发布该注册。
临时注册可以随时更新或放弃。注册被放弃时，该媒体类型在
任何意义上都不再注册；随后它可以像任何其他未分配的媒体
类型名称一样被注册。
Freed, et al. 当前最佳实践 [第 20 页]
RFC 6838 媒体类型注册 2013 年 1 月
5.3. 审查和批准
除临时标准树注册外，提交给 IANA 的注册将被转交给媒体类型
审查员。媒体类型审查员由 IETF 应用领域主任任命，将审查
注册以确保其满足本文档规定的要求。不满足这些要求的注册将
退回提交者修订。
媒体类型审查员作出的决定，可以使用 [RFC2026] 第 6.5.4 节
规定的程序向 IESG 申诉。
一旦媒体类型注册通过审查，IANA 将注册该媒体类型，并向社区
提供该媒体类型注册。
对于来自其他标准相关组织的标准树注册，IANA 还将检查提交者
实际上是否为公认标准相关组织。如果提交者当前并未被认可为
这类组织，则会请求 IESG 确认其状态。必须先获得 IESG 的认可，
标准树注册才能继续。
5.4. 媒体类型注册的评论
社区成员可以向 IANA 的 iana@iana.org 提交对已注册媒体类型的
评论。这些评论将由媒体类型审查员审查，然后在可能的情况下
转交给媒体类型的“所有者”。评论提交者可以请求将其评论附加
到媒体类型注册本身；如果 IANA 与媒体类型审查员协商后批准，
该评论将与该类型注册一起提供访问。
5.5. 变更程序
一旦媒体类型由 IANA 发布，所有者可以请求更改其定义。上文
对不同注册树的描述指定了每类注册的“所有者”。处理变更请求
时使用与原始注册请求相适合的同一程序。
媒体类型注册不得删除；不再认为适合使用的媒体类型，可以
通过更改其“预期用途”字段声明为 OBSOLETE；这类媒体类型将在
IANA 发布的列表中清楚标记。
Freed, et al. 当前最佳实践 [第 21 页]
RFC 6838 媒体类型注册 2013 年 1 月
只有在已发布规范存在严重遗漏或错误时，才应请求对媒体类型
定义作出重大变更。当需要审查时，如果变更请求会使先前定义下
有效的实体在新定义下变为无效，则可以拒绝该请求。
媒体类型的所有者可以通过通知 IANA，将责任转交给另一人或
机构；这可以无需讨论或审查即可完成。
IESG 可以重新分配媒体类型的责任。最常见的情况是，当注册
作者已经去世、失去联系，或因其他原因无法作出对社区重要的
变更时，使这些类型能够被变更。
5.6. 注册模板
类型名称：
子类型名称：
必需参数：
可选参数：
编码考虑事项：
安全考虑事项：
互操作性考虑事项：
已发布规范：
使用此媒体类型的应用：
片段标识符考虑事项：
额外信息：
此类型的已弃用别名：
魔数：
文件扩展名：
Macintosh 文件类型代码：
联系人及电子邮件地址，用于获取更多信息：
Freed, et al. 当前最佳实践 [第 22 页]
RFC 6838 媒体类型注册 2013 年 1 月
预期用途：
（COMMON、LIMITED USE 或 OBSOLETE 之一。）
使用限制：
（媒体类型可在何处使用的任何限制都写在这里。）
作者：
变更控制者：
临时注册？（仅限标准树）：
（作者认为有趣的任何其他信息都可以添加在此行下方。）
如果需要，可以在任何字段中使用按此方式准确书写的 "N/A"，
以强调其不适用，或强调该问题并非意外遗漏。不要使用 'none'
或其他可能被误认为答复的词。
受限使用的媒体类型还应该在应用列表中注明该列表是否穷尽。
6. 结构化语法后缀注册程序
希望定义一个 "+suffix" 名称，供新的媒体类型注册使用以表示
某种结构化语法的人，应该：
1. 检查 IANA 的媒体类型名称后缀注册表，查看是否已经存在该
明确定义的结构化语法的条目。
2. 如果没有其后缀方案的条目，则填写模板（在第 6.2 节
中规定）并将其包含在媒体类型注册中。该模板可以包含在
Internet-Draft 中，单独存在或作为其他协议规范的一部分。
该模板也可以以其他形式提交（作为另一份文档的一部分或
作为独立文档），但其内容将按 BCP 78 [RFC5378] 的
指南作为“IETF 贡献”处理。
3. 将模板副本或指向包含该模板的文档的指针（并具体引用含有
模板的章节）发送到 media-types@iana.org 邮件列表，请求
Freed, et al. 当前最佳实践 [第 23 页]
RFC 6838 媒体类型注册 2013 年 1 月
审查。这可以与请求审查媒体类型注册合并进行。应留出合理
时间用于讨论和评论。
4. 回应审查评论，并根据需要修订拟议注册，使其符合本文档中
给出的指南。
5. 将（可能已更新的）注册模板（或指向包含该模板的文档的
指针）提交给 IANA，地址为 iana@iana.org。
收到结构化语法后缀注册请求后，
1. IANA 检查提交是否完整；如果缺少章节或引用不正确，IANA
将拒绝注册请求。
2. IANA 检查当前注册表中是否存在同名条目；如果存在这样的
注册项，IANA 将拒绝注册请求。
3. IANA 请求根据相应指南对注册请求进行专家审查。
4. 指定专家可以根据需要请求额外审查或讨论。
5. 如果专家审查建议注册，IANA 会将该注册添加到适当注册表。
初始注册表内容规范 [RFC6839] 提供了结构化语法后缀注册的
示例。
6.1. 变更程序
可以通过与初始注册所需相同的机制，更新每个注册表中的注册。
如果方案的原始定义包含在 IESG 批准的文档中，则规范更新还
需要 IESG 批准。
6.2. 结构化语法后缀注册模板
此模板描述结构化语法后缀注册请求中必须提供的字段：
名称
明确定义的结构化语法的全名。
Freed, et al. 当前最佳实践 [第 24 页]
RFC 6838 媒体类型注册 2013 年 1 月
+suffix
用于表示符合该语法的后缀。
引用
包含理解该结构化语法所需所有规范的完整引用。
编码考虑事项
此处应给出关于采用此语法的任何类型的编码考虑事项的一般
指导。第 4.8 节中给出的媒体类型编码考虑事项的相同要求
在此适用。
互操作性考虑事项
此处应给出关于采用此结构化语法的类型在互操作使用方面的
任何问题。示例包括语法存在不兼容版本、某些 charset 与
该语法组合的问题，或与其他类型或协议的不兼容性。
片段标识符考虑事项
此处应描述采用此语法的任何类型对片段标识符的一般处理。
安全考虑事项
此处必须规定采用此结构化语法的媒体类型共有的安全考虑
事项。第 4.6 节中给出的媒体类型安全考虑事项的相同要求
在此适用，但后缀注册不能选择不评估安全考虑事项。
联系人
用于获取更多信息的联系人（包括联系信息）。
作者/变更控制者。
被授权更改此后缀注册的人（包括联系信息）。
7. 安全考虑事项
媒体类型和媒体类型后缀注册的安全要求在第 4.6 节中讨论。
Freed, et al. 当前最佳实践 [第 25 页]
RFC 6838 媒体类型注册 2013 年 1 月
8. IANA 考虑事项
本文档的目的是定义媒体类型和结构化语法后缀的 IANA 注册表，
以及管理这些注册表的程序。此外，本文档要求 IANA 维护一份
标准相关组织列表，列出已获 IESG 批准在标准树中进行媒体类型
注册的组织。
现有媒体类型注册表已被扩展，以包含一个临时注册部分。标准
树中仅允许标准树注册，并且只能应 IANA 标准相关组织列表上
某个组织的请求进行。有关临时注册的更多信息见第 5.2.1 节。
IANA 还在临时注册表顶部添加了以下说明：
此注册表不同于某些其他临时 IANA 注册表，仅用于临时使用。
此注册表中的条目要么最终确定并移入主媒体类型注册表，要么
被放弃并删除。此注册表中的条目仅适合用于开发和测试目的。
结构化语法名称后缀注册表已按如下方式创建：
o 名称为“Structured Syntax Suffix”注册表。
o 注册流程在第 6 节中规定。
o 注册项所需的信息以及条目格式在第 6.2 节中规定。
o 注册表的初始内容在 [RFC6839] 中规定。
媒体类型和结构化后缀注册表中的条目，将由 IANA 注明原始
注册日期以及该条目的最近更新日期。在本规范实施之前作出的
注册，如有必要，可以标记为此类注册，而不是标注具体日期。
由于注册条目可以多次更新，IANA 还将维护每个注册的变更历史，
以便能够确定注册在任意给定时间的状态。
Freed, et al. 当前最佳实践 [第 26 页]
RFC 6838 媒体类型注册 2013 年 1 月
最后，根据本文档，IANA 已为媒体类型审查列表创建新的电子邮件
地址 media-types@iana.org，它取代了 RFC 4288 中规定的
ietf-types@iana.org 地址。ietf-types@iana.org 已保留为别名。
9. 致谢
当前作者希望感谢已故的 Jon Postel 博士；他关于 IANA 注册
程序的一般模型和具体贡献塑造了本文档的前身 [RFC2048]
[RFC4288]。我们希望当前版本会是他同意的版本；但由于无法
验证这一同意，我们遗憾地将其姓名从共同作者中移除。
Randy Bush、Francis Dupont、Bjoern Hoehrmann、Barry Leiba、Murray
Kucherawy、Alexey Melnikov、S. Moonesamy、Mark Nottingham、Tom Petch、
Peter Saint-Andre 和 Jeni Tennison 提供了许多有益的审查评论
和建议。
10. 参考文献
10.1. 规范性引用
[RFC2045] Freed, N. and N. Borenstein, "多用途 Internet
邮件扩展（MIME）第一部分：Internet
消息正文的格式", RFC 2045, 1996 年 11 月。
[RFC2046] Freed, N. and N. Borenstein, "多用途 Internet
邮件扩展（MIME）第二部分：媒体类型",
RFC 2046, 1996 年 11 月。
[RFC2119] Bradner, S., "RFC 中用于表示要求级别的关键词",
BCP 14, RFC 2119, 1997 年 3 月。
[RFC2978] Freed, N. and J. Postel, "IANA 字符集注册
程序", BCP 19, RFC 2978, 2000 年 10 月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML
媒体类型", RFC 3023, 2001 年 1 月。
[RFC3629] Yergeau, F., "UTF-8，ISO 10646 的一种转换
格式", STD 63, RFC 3629, 2003 年 11 月。
[RFC3979] Bradner, S., "IETF 技术中的知识产权",
BCP 79, RFC 3979, 2005 年 3 月。
Freed, et al. 当前最佳实践 [第 27 页]
RFC 6838 媒体类型注册 2013 年 1 月
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
"统一资源标识符（URI）：通用
语法", STD 66, RFC 3986, 2005 年 1 月。
[RFC4855] Casner, S., "RTP 载荷格式的媒体类型注册",
RFC 4855, 2007 年 2 月。
[RFC5226] Narten, T. and H. Alvestrand, "RFC 中 IANA
考虑事项章节的编写指南",
BCP 26, RFC 5226, 2008 年 5 月。
[RFC5234] Crocker, D. and P. Overell, "语法规范的扩充
BNF：ABNF", STD 68, RFC 5234,
2008 年 1 月。
[RFC5378] Bradner, S. and J. Contreras, "贡献者向
IETF Trust 提供的权利", BCP 78, RFC 5378,
2008 年 11 月。
[RFC6532] Yang, A., Steele, S., and N. Freed,
"国际化电子邮件头", RFC 6532,
2012 年 2 月。
[RFC6657] Melnikov, A. and J. Reschke, "关于文本型
媒体类型中 "charset" 参数处理的 MIME 更新",
RFC 6657, 2012 年 7 月。
[RFC6839] Hansen, T. and A. Melnikov, "额外媒体类型
结构化语法后缀", RFC 6839,
2013 年 1 月。
10.2. 资料性引用
[MacOSFileTypes] Apple Computer, Inc., "Mac OS：文件类型和
创建者代码，以及文件格式", Apple Knowledge
Base Article 55381, 1993 年 6 月,
<http://www.info.apple.com/kbnum/n55381>.
[RFC2026] Bradner, S., "Internet 标准流程 --
修订版 3", BCP 9, RFC 2026, 1996 年 10 月。
[RFC2048] Freed, N., Klensin, J., and J. Postel,
"多用途 Internet 邮件扩展（MIME）第四部分：
注册程序", BCP 13, RFC 2048,
1996 年 11 月。
Freed, et al. 当前最佳实践 [第 28 页]
RFC 6838 媒体类型注册 2013 年 1 月
[RFC2231] Freed, N. and K. Moore, "MIME 参数值和
编码词扩展：
字符集、语言和续行",
RFC 2231, 1997 年 11 月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee,
"超文本传输协议 -- HTTP/1.1",
RFC 2616, 1999 年 6 月。
[RFC4288] Freed, N. and J. Klensin, "媒体类型
规范和注册程序",
BCP 13, RFC 4288, 2005 年 12 月。
[RFC5987] Reschke, J., "超文本传输协议（HTTP）头字段
参数的字符集和语言编码", RFC 5987, 2010 年 8 月。
[RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham,
"弃用应用协议中的 "X-" 前缀及类似构造",
BCP 178, RFC 6648,
2012 年 6 月。
Freed, et al. 当前最佳实践 [第 29 页]
RFC 6838 媒体类型注册 2013 年 1 月
附录 A. 祖父化媒体类型
许多具有无方面子类型名称的媒体类型是在 1996 年之前注册的；
如果按本文档中的指南注册，则会被赋予带方面的名称，并被放入
厂商树或个人树。鼓励但不要求重新注册这些类型，以反映适当的
树。本文档中概述的所有权和变更控制原则适用于这些类型，就像
它们已经注册在上述树中一样。
有时也可能出现这样的情况：某个具有无方面子类型名称的媒体
类型已经被广泛部署，却没有注册。（注意，这包括以 "x-" 前缀
开头的子类型名称。）如果可能，这类媒体类型应该使用适当的
带方面子类型名称重新注册，并可使用已弃用别名来标识原始名称
（见第 4.2.9 节）。不过，如果这不可行，则在获得媒体
类型审查员和 IESG 双方批准后，该类型可以使用其无方面名称
注册到适当的树中。
附录 B. 自 RFC 4288 以来的变更
o 现在已经完整规定了用于表示特定结构化语法使用情况的后缀，
并定义了后缀注册流程。
o 现在允许在媒体类型审查员和 IESG 批准的前提下，将广泛部署
但未注册的无方面类型名称注册到厂商树或个人树中。
o 标准树注册流程已修订为包含专家审查，并泛化以处理诸如非
IETF 流文档中的媒体类型等情况。
o 已向注册模板添加片段标识符字段，并添加了关于指定片段
标识符的简要指导。
o 个人树注册的规范要求已经更改为与厂商树相同。文本已经修改
为鼓励（但不要求）规范可获得。
o 定义额外树的流程已经澄清，说明需要 IETF 标准行动。
o 带有 "x-" 名称的广泛部署类型现在可以作为例外注册到厂商树。
Freed, et al. 当前最佳实践 [第 30 页]
RFC 6838 媒体类型注册 2013 年 1 月
o 对注册变更的要求已经放宽，使小变更更容易进行。
o 注册流程已经完全重构，因此除了 IETF 在标准树中生成的类型
外，所有请求都由 IANA 而非 IESG 处理。
o 已为标准树中的类型早期分配添加临时注册流程。
o 整个文档中已经进行了许多编辑性修改，以使其描述的要求和
流程更加清晰、更易遵循。
o 已添加为媒体类型指定已弃用别名列表的能力。
o 名称以 "x-" 开头的类型不再被视为未注册 "x." 树的成员。
与任何无方面类型一样，已经添加特殊程序，允许在适当树中
注册这类类型。
o 由第三方注册的类型，现在即使指定的变更控制者不是创建该
类型的厂商或组织，也可以由其进行变更。然而，厂商或组织
可以随时选择主张对该类型的所有权和变更控制权。
o 现在要求受限使用的媒体类型注明所提供的、使用该媒体类型的
应用列表是否穷尽。
o 媒体类型名称的 ABNF 已进一步限制为要求名称以字母数字字符
开头。
o 注册媒体类型之前不再要求邮件列表审查。此外，与媒体类型
审查邮件列表相关联的地址已更改为 media-types@iana.org。
o text/* 媒体类型的规则已经更新，以反映 [RFC6657] 中规定的
变更。
Freed, et al. 当前最佳实践 [第 31 页]
RFC 6838 媒体类型注册 2013 年 1 月
作者地址
Ned Freed
Oracle
800 Royal Oaks
Monrovia, CA 91016-6347
USA
EMail: ned+ietf@mrochek.com
John C. Klensin
1770 Massachusetts Ave, #322
Cambridge, MA 02140
USA
EMail: john+ietf@jck.com
Tony Hansen
AT&T Laboratories
200 Laurel Ave.
Middletown, NJ 07748
USA
EMail: tony+mtsuffix@maillennium.att.com
Freed, et al. 当前最佳实践 [第 32 页]