互联网工程任务组 (IETF) N. Freed
征求意见：6838 Oracle
BCP：13 J. Klensin
废止：4288
类别：最佳当前实践 T. Hansen
ISSN：2070-1721 AT&T 实验室
2013 年 1 月
媒体类型规范与注册程序
摘要
本文档定义了媒体类型的规范制定和
注册程序，这些媒体类型用于 HTTP、MIME 和其他互联网
协议。
本备忘录状态
本备忘录记载了一项互联网最佳当前实践。
本文档是互联网工程任务组
(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 等人 最佳当前实践 [第 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. 多部分和消息媒体类型 . . . . . . . . . . . . . 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 等人 最佳当前实践 [第 2 页]
RFC 6838 媒体类型注册 2013 年 1 月
10. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. 规范性参考文献 . . . . . . . . . . . . . . . . . . . 27
10.2. 资料性参考文献 . . . . . . . . . . . . . . . . . . . 28
附录 A. 祖父条款媒体类型 . . . . . . . . . . . . . . . . . 30
附录 B. 自 RFC 4288 以来的变更 . . . . . . . . . . . . . . . 30
1. 引言
近来的互联网协议经过精心设计，使其在某些方面易于
扩展。特别是，许多协议，包括但不限于 HTTP
[RFC2616] 和 MIME [RFC2045]，都能够
承载任意带标签的内容。
用于标记这类内容的机制是媒体类型，它由
顶级类型和子类型组成，子类型还进一步组织为
树。媒体类型还可以选择定义称为
参数的伴随数据。
这些标签需要一个注册过程，以便使此类值的集合
以合理有序、定义明确且公开的方式
得到定义。
本文档规定媒体类型注册的准则，并
定义在互联网号码分配机构 (IANA) 中央注册表中注册媒体类型（第 5 节）
以及媒体类型结构化后缀（第 6 节）时应使用的程序。
按这些程序管理的媒体类型注册表位置
是：
http://www.iana.org/assignments/media-types/
1.1. 历史说明
媒体类型注册过程最初是为
在异步互联网邮件环境中使用的媒体类型进行注册而定义的。在这种邮件环境中，需要
限制可能的媒体类型数量，以提高
在远程邮件系统能力未知时的互操作性
可能性。随着媒体类型被用于新的
环境，而在这些环境中媒体类型数量增加并不会成为
互操作性的障碍，原来的程序显得
过于严格，因此必须进行泛化。这一工作
最初在 [RFC2048] 中完成，但其中定义的程序
仍然是 MIME 文档集的一部分。媒体类型规范
和注册程序现在成为一份独立文档，以明确
它独立于 MIME。
Freed 等人 最佳当前实践 [第 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. 注册树和子类型名称
为提高
注册过程的效率和灵活性，可以注册不同结构的子类型名称，
以适应不同的自然需求，
例如，一个将被推荐由互联网社区广泛支持和
实现的子类型，或者一个用于
传输与专有软件关联文件的子类型。以下
小节定义了通过使用分面名称来区分的注册“树”，
例如，以“树.”
前缀开头的子类型名称。请注意，在本文档之前定义的一些媒体类型
并不符合下述命名约定。有关这些类型的讨论见附录
A。
3.1. 标准树
标准树用于互联网社区普遍感兴趣的
类型。标准树中的注册必须
满足以下二者之一：
Freed 等人 最佳当前实践 [第 4 页]
RFC 6838 媒体类型注册 2013 年 1 月
1. 对于与 IETF 规范关联的注册，
由 IESG 直接批准；或者
2. 由公认的标准相关组织使用
“需要规范”IANA 注册策略 [RFC5226]
进行注册（这意味着专家审查）。
第一种程序用于来自 IETF 共识
文档的注册，或者在少数情况下，当注册一个祖父条款（见
附录 A）和/或其他不完整注册符合互联网社区利益时使用。
注册提案必须
以 RFC 形式发布。当注册 RFC 位于 IETF
流中时，它必须具有 IETF 共识，这可以通过
标准路线、BCP、资料性或实验性状态获得。
在非 IETF RFC 流中发布的注册同样允许，
但需要 IESG 批准。注册既可以位于独立的
“仅注册”RFC 中，也可以包含在某种更一般的
规范中。
在第二种情况下，IESG 会对
注册提交者是否代表公认的标准相关
组织作出一次性决定；此后，由媒体类型审查者（指定专家
或一组指定专家）按照本文档中的规定执行专家审查。
来自同一
来源的后续提交不再涉及 IESG。格式必须由提交该格式的标准
相关组织制定的正式标准规范进行说明。
标准树中的媒体类型不得具有分面名称，除非
它们通过附录 A中所述过程按祖父条款保留。
在标准树中注册的媒体类型的“所有者”
被认为是标准相关组织本身。
规范的修改或变更使用与
初始注册所需相同级别的处理（例如，以标准路线提交的注册可以
在另一个标准路线 RFC 中修订，但不能在
资料性 RFC 中修订）。
来自公认标准相关
组织的标准树注册直接提交给 IANA，在批准前
将接受专家审查 [RFC5226]。在这种情况下，
专家审查者除其他事项外，将确保所需
规范提供充分的文档。
Freed 等人 最佳当前实践 [第 5 页]
RFC 6838 媒体类型注册 2013 年 1 月
3.2. 供应商树
供应商树用于与公开
可用产品关联的媒体类型。在此上下文中，“供应商”和“生产者”的含义非常
宽泛，并被视为等同。请注意，
行业联盟以及不符合公认标准相关组织资格的非商业实体，
完全可以在供应商树中注册媒体类型。
任何需要
交换与某个产品或一组产品关联文件的人，都可以将注册放入供应商树。
但是，该注册恰当地归属于
生产使用被注册类型的软件的供应商或
组织，并且该供应商或组织可以随时选择
声明由第三方完成的注册的所有权，以便
更正或更新它。更多信息见第 5.5 节。
当第三方代表其他人注册类型时，两个
实体都应该在注册的 Change Controller 字段中注明。
一种可能的格式是“Foo，代表
Bar”。
供应商树注册通过前导分面
“vnd.” 来区分。之后可以由注册者自行决定，
接一个知名生产者的媒体子类型名称（例如
“vnd.mudpie”），或者接一个经 IANA 批准的生产者
名称标识，再跟随媒体类型或产品标识（例如
vnd.bigcompany.funnypictures）。
虽然供应商树中待注册媒体类型无需进行公开展示
和审查，但鼓励使用 media-types@iana.org
邮件列表进行审查，以提高
这些规范的质量。供应商树中的注册可以
直接提交给 IANA，在批准前将接受专家审查
[RFC5226]。
3.3. 个人或自定义树
以实验方式创建或作为
非商业分发产品一部分创建的媒体类型，可以在
个人或自定义树中注册。这些注册通过
前导分面“prs.”来区分。
“个人”注册及相关规范的所有者
是进行注册的人或实体，或者是按照
下文所述转移了责任的人或实体。
Freed 等人 最佳当前实践 [第 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 等人 最佳当前实践 [第 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 等人 最佳当前实践 [第 8 页]
RFC 6838 媒体类型注册 2013 年 1 月
类似地，子类型名称中最后的“+”引入一个结构化
语法说明符后缀。结构化语法后缀要求
在第 4.2.8 节中规定。
尽管可以为某个媒体类型分配额外的
名称，但不建议使用不同名称来标识同一媒体类型。
无论涉及哪一种注册树，
这些要求都适用。
顶级类型的选择必须考虑所涉及
媒体类型的性质。顶级类型的新子类型必须遵守
该顶级类型的限制（如果有）。以下
各节说明初始顶级类型集合中的每一种及其
相关限制。此外，包括但不限于
HTTP 和 MIME 的各种协议，可以对其能够传输的媒体类型
施加其他限制。（有关 MIME 所施加限制的更多信息，
见 [RFC2046]。）
4.2.1. 文本媒体类型
“text”顶级类型用于发送主要
以文本形式存在的材料。
文本的许多子类型，尤其包括
[RFC2046] 中定义的纯文本通用子类型“text/plain”，
定义了一个“charset”参数。如果为某个特定文本子类型
定义了“charset”参数，则必须使用该参数指定
按照 [RFC2978] 中规定程序定义的
字符集名称。
如 [RFC6657] 所规定，当字符集信息在有效载荷内部传输
（例如“text/xml”）时，不应该
指定“charset”参数。
如果指定了“charset”参数，它应该是一个必需
参数，从而消除指定默认值的选项。如果
尽管有此建议仍有充分理由让该参数可选，
每个子类型可以指定自己的默认值，或者
也可以指定不存在默认值。
最后，应该选择“UTF-8”字符集 [RFC3629] 作为
默认值。有关“charset”参数与文本子类型结合使用的更多信息，
见 [RFC6657]。
无论选择哪种方法，所有新的 text/* 注册
都必须明确规定如何确定字符集；不再允许依赖
[RFC2046] 第 4.1.2 节中定义的 US-ASCII 默认值
Freed 等人 最佳当前实践 [第 9 页]
RFC 6838 媒体类型注册 2013 年 1 月
。如果需要说明文字，则应该将其放在
注册的附加信息部分中。
纯文本既不提供也不允许格式化命令、字体
属性规范、处理指令、解释
指令或内容标记。纯文本仅被视为字符的线性
序列，可能由换行或分页
中断。纯文本可以允许在文本中的同一位置
叠放若干字符。阿拉伯文和
希伯来文等文字系统中的纯文本还可以包含允许任意混合
不同书写方向文本片段的机制。
除纯文本之外，还存在许多表示所谓
“富文本”的格式。许多这类表示形式的一个有趣特点是，
即使没有解释它们的软件，在某种程度上仍然可读。
在最高层面将它们与图像、音频或者
以不可读形式表示的文本等不可读数据区分开来是很有用的。
在没有适当解释软件的情况下，
向用户呈现“text”的子类型是合理的，而对
大多数非文本数据这样做则不合理。这类带格式的文本数据可以
使用“text”的子类型表示。
4.2.2. 图像媒体类型
“image”顶级类型表示内容指定了一个
或多个独立图像。子类型指定具体的图像
格式。
4.2.3. 音频媒体类型
“audio”顶级类型表示内容包含音频
数据。子类型指定具体的音频格式。
4.2.4. 视频媒体类型
“video”顶级类型表示内容指定了
随时间变化的画面，可能带有颜色和同步的
声音。“video”一词按其最一般意义使用，而不是
指代任何特定技术或格式，也并不意味着
排除诸如以紧凑方式编码的动画绘图
之类的子类型。
请注意，虽然通常不鼓励在单个正文中
混合多种媒体 [RFC2046]，但应认识到许多
视频格式包含同步音频和/或
文本的表示形式，并且“video”子类型明确允许这样做。
Freed 等人 最佳当前实践 [第 10 页]
RFC 6838 媒体类型注册 2013 年 1 月
4.2.5. 应用媒体类型
“application”顶级类型用于不适合
其他任何类型名称的离散数据，尤其用于
需要由某种应用程序处理的数据。这类
信息必须先由应用程序处理，才能被用户
查看或使用。“application”
类型名称的预期用途包括但不限于文件传输、电子表格、
演示文稿、日程数据，以及用于“主动”
（计算型）材料的语言。（尤其是最后一种可能带来
实现者必须了解的安全问题。
[RFC2046] 中的“application/postscript”媒体类型注册
提供了一个如何处理这些问题的良好示例。）
例如，会议日程程序可以为
关于拟议会议日期的信息定义标准
表示形式。智能用户代理会使用这些信息与用户
进行对话，然后可能根据该
对话发送其他材料。更一般地说，已经开发出若干
“主动”语言，其中以适当专用语言编写的程序
被传输到远程位置，并在
接收者的环境中自动运行。此类应用可以定义为
“application”顶级类型的子类型。
“application”的子类型通常是
数据所针对应用程序名称的全部或一部分。
但这并不意味着任何应用程序名称都可以
随意直接用作“application”的子类型；该子类型
需要注册。
4.2.6. 多部分和消息媒体类型
multipart 和 message 是复合类型；也就是说，它们提供一种
封装零个或多个对象的方法，每个对象都是一个独立的
媒体类型。
multipart 和 message 的所有子类型都必须符合
[RFC2046] 中规定并由
[RFC6532] 第 3.5 节修订的语法规则及其他要求。
Freed 等人 最佳当前实践 [第 11 页]
RFC 6838 媒体类型注册 2013 年 1 月
4.2.7. 其他顶级类型
在某些情况下，新媒体类型可能无法“归入”任何当前
已定义的顶级类型名称之下。预计这种情况非常
少见。但是，如果确实出现这种情况，可以
定义新的类型名称来容纳它。新顶级类型名称的定义
必须通过标准路线 RFC 完成；不得使用其他机制
定义额外的类型名称。
4.2.8. 结构化语法名称后缀
MIME 中的 XML [RFC3023] 定义了对媒体类型定义的
第一个此类扩充，用于进一步指定该
媒体类型的底层结构。引用如下：
本文档还标准化了一种约定（使用后缀
“+xml”）来命名媒体类型……当这些媒体类型
表示 XML MIME（多用途互联网邮件扩展）
实体时。
也就是说，它规定了一个后缀（在该例中为“+xml”），附加
到基础子类型名称之后。
自该文档发布以来，使用这种后缀约定表示其他知名
结构化语法已经成为事实上的实践。特别是，
已有媒体类型注册了诸如
“+der”、“+fastinfoset”和“+json”的后缀。本规范将
这种实践正式化，并建立结构化类型名称
后缀注册表。
判断某个结构化类型名称后缀是否可注册的主要准则
是：该后缀应由易于获得的
说明进行描述，最好是在成熟的
标准相关组织发布的文档中，并且存在一个
可用于 RFC 规范性参考文献部分的引用。
使用命名结构化语法的媒体类型在注册时
应该使用该结构化语法对应的
已注册“+suffix”。同样，媒体类型不得被赋予
包含其实际上并未使用的结构化语法后缀的
名称。鉴于可能与未来的后缀定义发生
冲突，不应该使用尚未注册的结构化语法
“+suffix”构造。
Freed 等人 最佳当前实践 [第 12 页]
RFC 6838 媒体类型注册 2013 年 1 月
4.2.9. 已弃用别名
在某些情况下，单个媒体类型可能在注册之前已经
以多个名称广泛部署。在这种情况下，必须为该媒体类型
选择一个首选名称，应用程序必须使用此名称，
才符合该类型的注册要求。但是，
可以提供该类型已知的已弃用别名列表作为附加信息，
以帮助应用程序
正确处理该媒体类型。
4.3. 参数要求
媒体类型可以选择使用一个或多个媒体类型参数，或者
某些参数可能因为该媒体类型是定义了一组
适用于其任何子类型的参数之内容类型的子类型，而自动对其可用。
无论哪种情况，当媒体类型在标准树中注册时，
任何参数的名称、值和含义都必须完整规定；
当媒体类型在供应商树或个人树中注册时，
则应该尽可能完整地规定。
参数名称的语法与媒体类型名称和值一样：
parameter-name = restricted-name
请注意，此语法比 [RFC2045] 中并由 [RFC2231] 修订的 ABNF
所允许的语法限制稍多。
参数名称不区分大小写，其出现顺序
不具有任何含义。同一个特定参数被指定
多次属于错误。
参数值没有已定义的语法。因此，
注册必须规定参数值语法。此外，
某些传输机制会对参数值语法施加限制，因此
需要注意限制使用可能有问题的
语法；例如，尽管某些协议允许纯二进制值参数，
但最好避免使用。
请注意，协议可以根据其选择如何表示参数，
对参数值语法施加进一步限制。
MIME [RFC2045] [RFC2231] 和 HTTP [RFC2045] [RFC5987] 都允许
二进制参数以及使用特定字符集表示的参数值，
但其他协议可能不那么灵活。
不应该通过定义新参数的方式，为标准树中已注册的类型
引入新功能，不过可以添加新
参数来传递不会
Freed 等人 最佳当前实践 [第 13 页]
RFC 6838 媒体类型注册 2013 年 1 月
以其他方式改变现有功能的附加信息。一个
示例是使用“revision”参数表示外部规范
（例如 JPEG）的修订级别。对于
在供应商树或个人树中注册的媒体类型，也鼓励采取类似做法，但
不是必需的。
参数的变更（包括引入新参数）按照
与媒体类型其他变更相同的方式管理；见
第 5.5 节。
4.4. 规范化和格式要求
无论注册树为何，所有已注册媒体类型都必须采用
单一、规范的数据格式。
对于标准树中注册的所有类型，都必须存在
一份永久且易于公开获取的媒体类型格式规范。
该规范必须提供足够的细节，以便
使用该媒体类型的独立实现之间可以实现互操作。
该规范至少必须在媒体类型
注册提案本身中被引用（如果没有实际包含在其中）。
对于在供应商树
和个人树中注册的媒体类型，其格式和处理细节规范可能公开，也可能不公开。
明确允许此类注册将注册中的
信息限制为哪些软件及
版本生成或处理这类媒体类型。因此，鼓励
在注册中引用或包含格式规范，
但不要求这样做。不过请注意，一份有意义规范的
公开可用性，通常会决定该注册究竟只是
保留一个名称以避免与其他用途冲突，
还是能够让该媒体类型出现其他实现并与其进行
有用的互操作。
某些媒体类型涉及使用专利技术。
明确允许注册涉及专利技术的媒体类型。
但是，当媒体类型规范是标准路线协议的一部分时，
必须遵守 BCP
79 [RFC3979] 和 BCP 78 [RFC5378] 对 IETF 标准路线协议中
使用专利技术所规定的限制。
此外，使用标准树的其他标准相关组织
可能有自己的知识产权规则，
在其注册中必须遵守这些规则。
鼓励但不要求供应商树和个人树中的注册
披露知识产权 (IPR)。
Freed 等人 最佳当前实践 [第 14 页]
RFC 6838 媒体类型注册 2013 年 1 月
4.5. 互换建议
理想情况下，媒体类型的定义应使其能够在尽可能多的
系统和应用之间互操作。但是，某些媒体类型
不可避免地会在不同平台之间存在
互操作问题。不同版本、字节顺序以及
网关处理细节方面的问题都可能且确实会出现。
并不要求媒体类型具有普遍互操作性，但只要可能，
就应该指出已知的互操作问题。
发布媒体类型不要求对互操作性进行穷尽审查，
互操作性考虑部分也需要
持续评估。
无论涉及哪一种注册树，
本小节中的建议都适用。
4.6. 安全要求
对所有在标准树中注册的类型，都必须进行安全问题
分析。对于在供应商树或个人树中注册的媒体类型，
鼓励但不要求进行类似分析。
不过，无论是否进行了安全分析，
无论注册树为何，对所有安全问题的描述都必须尽可能
准确。特别是，
安全考虑不得声称“此类型不存在相关安全
问题”。供应商树或个人树中的类型
可以在安全考虑中说明“尚未评估
与此类型相关的安全问题”。
完全没有要求任何树中注册的媒体类型
必须安全或完全没有风险。尽管如此，无论注册树为何，
媒体类型注册中都必须指出所有
已知安全风险。
所有注册中的安全考虑部分都需要
持续评估和修改，尤其可以通过
下文第 5.4 节所述的“媒体类型评论”机制进行
扩展。
在媒体类型安全分析中需要检查和说明的
一些问题包括：
o 复杂媒体类型可能包含用于发出指令的机制，
这些指令会对接收者的文件或其他资源执行操作。在
许多情况下，会允许发起者以不受限制的方式指定任意
操作，而这些操作随后可能产生灾难性
后果。有关这种指令以及如何在媒体类型注册中描述它们的示例，
见 application/postscript 媒体
Freed 等人 最佳当前实践 [第 15 页]
RFC 6838 媒体类型注册 2013 年 1 月
类型在 [RFC2046] 中的注册。
o 任何安全分析都必须说明是否使用了这种
“主动内容”；如果使用，则必须说明已经采取了哪些
步骤，或者媒体类型的应用程序必须采取哪些步骤，以
保护媒体类型用户免受伤害。
o 复杂媒体类型可能包含用于发出指令的机制，
这些指令虽然不会直接伤害
接收者，但可能导致信息泄露，从而
为后续攻击提供便利，或者以某种方式侵犯接收者的
隐私。同样，application/
postscript 媒体类型的注册说明了如何处理
这类指令。
o 使用压缩的媒体类型可能提供一种机会，
使发送者发送少量数据，而这些数据在接收并
求值后会急剧膨胀，从而耗尽接收者的所有
资源。所有媒体类型都应该说明它们
是否使用压缩；如果使用，则应该讨论需要采取哪些
步骤来避免此类攻击。
o 某个媒体类型可能面向需要某种
安全保证、但其本身不提供必要安全机制的应用。
例如，可以定义一种媒体类型来
存储敏感医疗信息，而这种信息又需要外部机密性
和完整性保护服务，或者该类型可能被设计为仅在安全
环境中使用。类型应该始终在其安全考虑中说明
是否需要此类服务。
4.7. XML 媒体类型特有的要求
注册 XML 媒体类型还有若干
额外要求。这些要求在
[RFC3023] 中规定。
4.8. 编码要求
某些传输机制会限制其能够
承载的数据类型。例如，互联网邮件传统上仅限于 7bit
US-ASCII 文本。通常使用编码方案来绕过这种
传输限制。
Freed 等人 最佳当前实践 [第 16 页]
RFC 6838 媒体类型注册 2013 年 1 月
因此，在注册中注明媒体类型可以
由哪种数据组成是很有用的。为此提供了“encoding considerations”
字段。该字段可能的值
是：
7bit：媒体类型的内容仅由以 CRLF
分隔的 7bit US-ASCII 文本组成。
8bit：媒体类型的内容仅由以 CRLF
分隔的 8bit 文本组成。
binary：内容由不受限制的八位字节序列组成。
framed：内容由一系列帧或分组组成，
内部没有成帧或对齐指示符。需要额外的带外
信息才能正确解释数据，
包括但不一定限于了解
连续帧之间的边界以及了解
传输机制。请注意，这类媒体类型不能
简单地存储在文件中，也不能作为简单的
八位字节流传输；因此，这类媒体类型不适合在许多
传统协议中使用。使用 framed
编码的常见传输协议是实时传输协议 RTP。有关
为使用 RTP 传输而定义的 framed 编码的附加
规则见 [RFC4855]。
对 7bit 和 8bit 文本的附加限制见
[RFC2046] 第
4.1.1 节。
4.9. 使用和实现非要求
在异步邮件环境中，发送者通常无法获得
关于远程邮件代理能力的信息，
因而通过将所使用的媒体类型限制为预计会广泛实现的
那些“常见”格式，可以获得最大的互操作性。
过去曾以此为理由限制
可能的媒体类型数量，并导致媒体类型
注册过程存在显著障碍和延迟。
但是，对“常见”媒体类型的需求并不要求限制
新媒体类型的注册。如果为某个特定应用
推荐有限的媒体类型集合，则应通过
专门针对该应用和/或环境的独立适用性声明来说明。
因此，对媒体类型的普遍支持和实现
不是注册要求。但是，如果某个媒体类型
Freed 等人 最佳当前实践 [第 17 页]
RFC 6838 媒体类型注册 2013 年 1 月
明确仅用于受限用途，则必须在其
注册中注明。为此提供了“Restrictions on Usage”
字段。
4.10. 发布要求
由 IETF 自身在标准树中注册的媒体类型必须
以 RFC 形式发布。供应商和个人媒体类型注册允许
以 RFC 形式发布，但不要求这样做。在所有情况下，
IANA 都会保留所有媒体类型注册的副本，并将它们作为
媒体类型注册树本身的一部分“发布”。
如前所述，由其他标准相关
组织制定的文档中所定义媒体类型的标准树注册，必须由
该组织制定的正式标准规范进行说明。
此外，注册模板上的任何版权都必须允许
IANA 将其复制到 IANA 注册表中。
除 IETF 在标准树中的注册外，媒体类型的注册
并不意味着 IANA 或 IETF 对其背书、批准或
推荐，甚至也不证明该
规范是充分的。要成为 IETF 标准，协议或
数据对象必须经过 IETF 标准流程。虽然该流程
在适当情况下能够提供额外保证，但对于方便地注册
媒体类型而言，这一过程过于困难且耗时过长。
标准树适用于那些确实需要在公认标准
相关组织中经过实质性审查和批准过程的
媒体类型。供应商树和个人树则适用于那些
不需要此类过程的媒体类型。预计 IETF 会
不时发布针对特定应用的适用性声明，
推荐实现和支持那些已证明在相关场景中特别有用的
媒体类型。
如上所述，注册顶级类型需要
IETF 中的标准行动，因此需要发布一份
标准路线 RFC。
4.11. 片段标识符要求
媒体类型注册可以规定应用程序应如何
解释与该媒体类型关联的片段标识符（见
[RFC3986] 第 3.5 节）。
Freed 等人 最佳当前实践 [第 18 页]
RFC 6838 媒体类型注册 2013 年 1 月
鼓励媒体类型采用与语义相似媒体类型所使用的
片段标识符方案。特别是，使用具有已注册
“+suffix”的命名结构化语法的媒体类型，必须遵循
结构化语法后缀注册中给出的任何片段标识符规则。
4.12. 其他信息
如果可以获得，则媒体类型规范中应该包含
各种可选信息：
o 魔数（长度、八位字节值）。魔数是
始终出现在文件中特定位置的字节序列，因此
可用于识别实体是否属于某种给定媒体
类型。
o 在一个或多个平台上常用的文件扩展名，
用于表示某个文件包含给定媒体类型。
o 用于标记包含给定媒体类型文件的 Mac OS 文件类型代码
（4 个八位字节）。关于 Macintosh 文件类型代码及其用途的
一些讨论见 [MacOSFileTypes]。
对于标准树中的注册，可以在媒体
类型格式的正式规范中提供这些附加
信息。建议通过将
IANA 媒体类型注册表直接纳入格式规范
来实现。
5. 媒体类型注册程序
媒体类型注册程序并不是正式的标准
流程，而是一种管理程序，旨在允许
社区发表评论并进行合理性检查，而不会造成过度的时间延迟。
标准树中的所有 IETF 注册都需要遵循正常的 IETF
流程。发布互联网草案是必需的
第一步，然后按照下文讨论发布到 media-types@iana.org
列表。
5.1. 初步社区审查
标准树中潜在媒体类型注册的通知
应该发送到 media-types@iana.org 邮件列表进行审查。
该邮件列表是为审查
提议的媒体类型和访问类型而设立的。其他树中的注册也可以
发送到该列表进行审查；这样做完全是可选的，
但强烈鼓励。
Freed 等人 最佳当前实践 [第 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 等人 最佳当前实践 [第 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 发布，其所有者可以
请求更改其定义。上文对不同注册树的
描述指定了每类注册的“所有者”。
处理变更请求时使用与原始注册请求
相适用的相同程序。
媒体类型注册不得删除；如果某个媒体类型
被认为不再适合使用，可以通过更改其“intended use”
字段将其声明为 OBSOLETE；这类媒体类型将在
IANA 发布的列表中明确标记。
Freed 等人 最佳当前实践 [第 21 页]
RFC 6838 媒体类型注册 2013 年 1 月
仅当已发布规范中存在严重遗漏或错误时，
才应该请求对媒体类型定义进行重大更改。
当需要审查时，如果变更请求会导致在先前
定义下有效的实体在新定义下变为无效，则该请求可能被
拒绝。
媒体类型的所有者可以通过通知 IANA，
将责任移交给另一个人或机构；此操作无需讨论
或审查。
IESG 可以重新分配媒体类型的责任。
最常见的情况是，当注册作者已经去世、失去联系，
或因其他原因无法进行对社区十分重要的
更改时，使此类更改能够进行。
5.6. 注册模板
类型名称：
子类型名称：
必需参数：
可选参数：
编码考虑：
安全考虑：
互操作性考虑：
已发布规范：
使用此媒体类型的应用程序：
片段标识符考虑：
附加信息：
此类型的已弃用别名：
魔数：
文件扩展名：
Macintosh 文件类型代码：
供进一步联系的信息联系人及电子邮件地址：
Freed 等人 最佳当前实践 [第 22 页]
RFC 6838 媒体类型注册 2013 年 1 月
预期用途：
（COMMON、LIMITED USE 或 OBSOLETE 之一。）
使用限制：
（关于媒体类型可以在哪些位置使用的任何限制写在这里。）
作者：
变更控制者：
临时注册？（仅标准树）：
（作者认为有意义的任何其他信息都可以
添加在此行以下。）
如有需要，可以在任何字段中使用完全按此形式书写的“N/A”，
以强调该字段不适用，或者该问题并非
意外遗漏。不要使用“none”或其他可能
被误认为实际回答的词语。
有限用途媒体类型还应该在应用程序列表中注明
该列表是否详尽无遗。
6. 结构化语法后缀注册程序
希望为新媒体类型注册所使用的结构化语法
定义“+suffix”名称的人应该：
1. 检查 IANA 的媒体类型名称后缀注册表，确认
是否已经存在该明确定义结构化
语法的条目。
2. 如果其后缀方案尚无条目，则填写
模板（见第 6.2 节），并将其与
媒体类型注册一起提交。模板可以包含在
互联网草案中，既可以单独存在，也可以作为其他协议
规范的一部分。模板也可以以其他
形式提交（作为另一文档的一部分或独立文档），
但其内容将按照 BCP 78 [RFC5378] 的指南
被视为“IETF Contribution”。
3. 将模板副本或指向包含该模板之
文档的指针（明确指出含有
模板的章节）发送到邮件列表 media-types@iana.org，请求
Freed 等人 最佳当前实践 [第 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 等人 最佳当前实践 [第 24 页]
RFC 6838 媒体类型注册 2013 年 1 月
+suffix
用于表示符合该语法的后缀。
参考文献
包含理解该结构化语法所需的所有规范的完整
引用。
编码考虑
此处应给出关于任何使用此语法的类型之
编码考虑的一般指导。第 4.8 节中关于媒体类型编码考虑的
相同要求也适用于
此处。
互操作性考虑
此处应给出有关使用此结构化语法之类型
互操作使用的任何问题。例如可能包括
存在不兼容的语法版本、
某些字符集与该语法组合时的问题，或者
与其他类型或协议的不兼容。
片段标识符考虑
此处应说明对任何使用此语法之类型的
片段标识符进行通用处理的方式。
安全考虑
此处必须规定使用此结构化语法的媒体类型
共有的安全考虑。第 4.6 节中关于媒体类型安全考虑的
相同要求也适用于
此处，但有一个例外：对于后缀注册，
不允许选择不评估安全考虑。
联系人
可联系以获取更多
信息的人员（包括联系信息）。
作者/变更控制者。
有权更改此
后缀注册的人员（包括联系信息）。
7. 安全考虑
媒体类型和媒体类型后缀
注册的安全要求均在第 4.6 节中讨论。
Freed 等人 最佳当前实践 [第 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 等人 最佳当前实践 [第 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. 和 N. Borenstein，《多用途互联网
邮件扩展 (MIME) 第一部分：互联网
消息正文格式》，RFC 2045，1996 年 11 月。
[RFC2046] Freed, N. 和 N. Borenstein，《多用途互联网
邮件扩展 (MIME) 第二部分：媒体类型》，
RFC 2046，1996 年 11 月。
[RFC2119] Bradner, S.，《RFC 中用于表示
要求级别的关键词》，BCP 14，RFC 2119，1997 年 3 月。
[RFC2978] Freed, N. 和 J. Postel，《IANA 字符集注册
程序》，BCP 19，RFC 2978，2000 年 10 月。
[RFC3023] Murata, M.、St. Laurent, S. 和 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 等人 最佳当前实践 [第 27 页]
RFC 6838 媒体类型注册 2013 年 1 月
[RFC3986] Berners-Lee, T.、Fielding, R. 和 L. Masinter，
《统一资源标识符 (URI)：通用
语法》，STD 66，RFC 3986，2005 年 1 月。
[RFC4855] Casner, S.，《RTP 有效载荷
格式的媒体类型注册》，RFC 4855，2007 年 2 月。
[RFC5226] Narten, T. 和 H. Alvestrand，《在 RFC 中
编写 IANA 考虑部分的指南》，
BCP 26，RFC 5226，2008 年 5 月。
[RFC5234] Crocker, D. 和 P. Overell，《用于
语法规范的增强 BNF：ABNF》，STD 68，RFC 5234，
2008 年 1 月。
[RFC5378] Bradner, S. 和 J. Contreras，《贡献者
授予 IETF Trust 的权利》，BCP 78，RFC 5378，
2008 年 11 月。
[RFC6532] Yang, A.、Steele, S. 和 N. Freed，
《国际化电子邮件首部》，RFC 6532，
2012 年 2 月。
[RFC6657] Melnikov, A. 和 J. Reschke，《关于文本型
媒体类型中“charset”参数处理的 MIME
更新》，RFC 6657，2012 年 7 月。
[RFC6839] Hansen, T. 和 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.，《互联网标准流程 --
修订版 3》，BCP 9，RFC 2026，1996 年 10 月。
[RFC2048] Freed, N.、Klensin, J. 和 J. Postel，
《多用途互联网邮件扩展 (MIME) 第
四部分：注册程序》，BCP 13，RFC 2048，
1996 年 11 月。
Freed 等人 最佳当前实践 [第 28 页]
RFC 6838 媒体类型注册 2013 年 1 月
[RFC2231] Freed, N. 和 K. Moore，《MIME 参数值和
编码字扩展：
字符集、语言和连续段》，
RFC 2231，1997 年 11 月。
[RFC2616] Fielding, R.、Gettys, J.、Mogul, J.、Frystyk, H.、
Masinter, L.、Leach, P. 和 T. Berners-Lee，
《超文本传输协议 -- HTTP/1.1》，
RFC 2616，1999 年 6 月。
[RFC4288] Freed, N. 和 J. Klensin，《媒体类型
规范与注册程序》，
BCP 13，RFC 4288，2005 年 12 月。
[RFC5987] Reschke, J.，《超文本传输协议 (HTTP) 首部字段
参数的字符集和语言编码》，
RFC 5987，2010 年 8 月。
[RFC6648] Saint-Andre, P.、Crocker, D. 和 M. Nottingham，
《废弃应用协议中的“X-”前缀及类似构造》，
BCP 178，RFC 6648，
2012 年 6 月。
Freed 等人 最佳当前实践 [第 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 等人 最佳当前实践 [第 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 等人 最佳当前实践 [第 31 页]
RFC 6838 媒体类型注册 2013 年 1 月
作者地址
Ned Freed
Oracle
800 Royal Oaks
Monrovia, CA 91016-6347
美国
电子邮件：ned+ietf@mrochek.com
John C. Klensin
1770 Massachusetts Ave, #322
Cambridge, MA 02140
美国
电子邮件：john+ietf@jck.com
Tony Hansen
AT&T 实验室
200 Laurel Ave.
Middletown, NJ 07748
美国
电子邮件：tony+mtsuffix@maillennium.att.com
Freed 等人 最佳当前实践 [第 32 页]