跳到主要内容

4. 注册要求

所有媒体类型注册都应符合以下各节列出的各种要求.注意, 具体要求有时会因注册树而异, 详见以下各节.

4.1 功能性要求​

媒体类型 MUST 作为实际媒体格式发挥作用.不允许注册更适合被视为传输编码,字符集或另一类型的独立实体集合的事物.例如, 虽然存在可解码 base64 传输编码 [RFC2045] 的应用, 但 base64 不能注册为媒体类型.

无论涉及哪种注册树, 此要求均适用.

4.2 命名要求​

所有已注册媒体类型 MUST 分配顶层类型和子类型名称.这些名称的组合用于唯一标识媒体类型, 而子类型名称分面 (或没有分面) 标识注册树.顶层类型和子类型名称均不区分大小写.

类型和子类型名称 MUST 符合以下 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 =/ "." ; Characters before first dot always
                             ; specify a facet name
restricted-name-chars =/ "+" ; Characters after last plus always
                             ; specify a structured syntax suffix

注意, 此语法比 [RFC2045] 第 5.1 节或 [RFC4288] 第 4.2 节中的 ABNF 所允许的语法稍微更严格.还需注意, 虽然此语法允许最长 127 个字符的名称, 但实现限制可能使这种长名称产生问题.因此, <type-name> 和 <subtype-name> SHOULD 限制为 64 个字符.

4.2.1 文本媒体类型​

"text" 顶层类型用于发送主要以文本形式存在的材料.

text 的许多子类型定义了 "charset" 参数, 其中尤其包括 [RFC2046] 中定义的普通文本通用子类型 "text/plain".如果为某个特定 text 子类型定义了 "charset" 参数, 则该参数 MUST 用于指定按 [RFC2978] 中程序定义的 charset 名称.

4.2.2 图像媒体类型​

"image" 顶层类型表示内容指定一个或多个单独图像.子类型命名具体图像格式.

4.2.3 音频媒体类型​

"audio" 顶层类型表示内容包含音频数据.子类型命名具体音频格式.

4.2.4 视频媒体类型​

"video" 顶层类型表示内容指定随时间变化的画面图像, 可能带有颜色和同步声音.术语 'video' 以其最通用含义使用, 而不是指任何特定技术或格式, 也不意味着排除紧凑编码动画图形等子类型.

4.2.5 应用媒体类型​

"application" 顶层类型用于不适合任何其他类型名称的离散数据, 尤其是将由某类应用程序处理的数据.

4.2.6 Multipart 和 Message 媒体类型​

Multipart 和 message 是复合类型; 也就是说, 它们提供了一种封装零个或多个对象的方式, 其中每个对象都是单独的媒体类型.

multipart 和 message 的所有子类型 MUST 符合 [RFC2046] 中规定并由 [RFC6532] 第 3.5 节修订的语法规则和其他要求.

4.2.7 附加顶层类型​

在某些情况下, 新媒体类型可能不 "fit" 当前定义的任何顶层类型名称.预计这种情况相当少见.不过, 如果确实出现这种情况, 可以定义新的类型名称来容纳它.新顶层类型名称的定义 MUST 通过 Standards Track RFC 完成; 不得使用其他机制定义附加类型名称.

4.2.8 结构化语法名称后缀​

使用命名结构化语法的媒体类型在注册时 SHOULD 使用该结构化语法适当的已注册 "+suffix".同理, 媒体类型 MUST NOT 在名称中包含其并未实际采用的结构化语法后缀.

4.2.9 已弃用别名​

在某些情况下, 单一媒体类型可能在注册前已通过多个名称广泛部署.在这种情况下, MUST 为该媒体类型选择首选名称, 应用 MUST 使用该名称才能符合该类型注册.

4.3 参数要求​

媒体类型 MAY 选择使用一个或多个媒体类型参数, 或者某些参数可能因该媒体类型是某内容类型的子类型而自动可用, 该内容类型定义了一组适用于其任意子类型的参数.

参数名称具有与媒体类型名称和值相同的语法:

parameter-name = restricted-name

参数名称不区分大小写, 其出现顺序不具有含义.多次指定同一特定参数是错误.

4.4 规范化和格式要求​

所有已注册媒体类型 MUST 采用单一规范编码格式.

4.5 交换建议​

媒体类型 SHOULD 包含关于如何最好地完成异构系统之间交换的建议.

4.6 安全要求​

所有注册 MUST 进行安全问题分析.所有媒体类型注册 MUST 包含 "Security considerations" 节, 详细说明该媒体类型的安全影响.

4.7 XML 媒体类型特定要求​

采用 XML 的媒体类型 MUST 符合 [RFC7303] 中规定的要求.

4.8 编码要求​

媒体类型注册 MUST 明确规定该类型如何编码以供各种传输协议使用.

4.9 使用和实现非要求​

媒体类型注册并不意味着对任何特定实现的认可.

4.10 发布要求​

广泛部署媒体类型的标准树注册 SHOULD 作为 RFC 发布.

4.11 片段标识符要求​

采用片段标识符的媒体类型 MUST 记录其支持的片段标识符语法.

4.12 附加信息​

媒体类型注册模板包含若干附加信息字段.

最后于 更新