Skip to main content

4. Registration Requirements (注册要求)

所有媒体类型注册都应符合以下各节中规定的各种要求.请注意,要求的具体内容有时会因注册树而异,以下各节中再次详细说明.

4.1 Functionality Requirement (功能要求)​

媒体类型必须作为实际的媒体格式发挥作用.不允许注册那些更适合被视为传输编码 (transfer encoding),字符集 (charset) 或另一种类型的单独实体集合的内容.例如,尽管存在用于解码 base64 传输编码 [RFC2045] 的应用程序,但 base64 不能注册为媒体类型.

此要求适用于所涉及的任何注册树.

4.2 Naming Requirements (命名要求)​

所有已注册的媒体类型必须被分配顶级类型 (top-level type) 和子类型 (subtype) 名称.这些名称的组合用于唯一标识媒体类型,子类型名称分面 (facet)(或其缺失)标识注册树.顶级类型和子类型名称都不区分大小写.

类型和子类型名称必须符合以下 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> 应限制为 64 个字符.

4.2.1 Text Media Types (Text 媒体类型)​

"text" 顶级类型旨在用于发送主要以文本形式呈现的材料.

text 的许多子类型,特别是包括子类型 "text/plain"(这是在 [RFC2046] 中定义的纯文本的通用子类型),定义了 "charset" 参数.如果为 text 的特定子类型定义了 "charset" 参数,则必须使用它来指定根据 [RFC2978] 中规定的程序定义的字符集名称.

4.2.2 Image Media Types (Image 媒体类型)​

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

4.2.3 Audio Media Types (Audio 媒体类型)​

"audio" 顶级类型表示内容包含音频数据.子类型命名特定的音频格式.

4.2.4 Video Media Types (Video 媒体类型)​

"video" 顶级类型表示内容指定时变图像,可能带有颜色和协调的声音.术语"video"在其最通用的意义上使用,而不是参考任何特定的技术或格式,并不意味着排除诸如紧凑编码的动画图形之类的子类型.

4.2.5 Application Media Types (Application 媒体类型)​

"application" 顶级类型用于不符合任何其他类型名称的离散数据,特别是用于由某种类型的应用程序处理的数据.

4.2.6 Multipart and Message Media Types (Multipart 和 Message 媒体类型)​

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

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

4.2.7 Additional Top-Level Types (附加顶级类型)​

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

4.2.8 Structured Syntax Name Suffixes (结构化语法名称后缀)​

使用命名结构化语法的媒体类型在注册时应该为该结构化语法使用适当的已注册 "+suffix".同样,媒体类型不得被赋予包含它们实际上不使用的结构化语法后缀的名称.

4.2.9 Deprecated Aliases (已弃用的别名)​

在某些情况下,单个媒体类型可能在注册之前以多个名称广泛部署.在这种情况下,必须为媒体类型选择一个首选名称,应用程序必须使用此名称才能符合该类型的注册.

4.3 Parameter Requirements (参数要求)​

媒体类型可以选择使用一个或多个媒体类型参数,或者某些参数可能会通过作为内容类型的子类型而自动可用于媒体类型,该内容类型定义了一组适用于其任何子类型的参数.

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

parameter-name = restricted-name

参数名称不区分大小写,并且它们出现的顺序没有任何意义.为特定参数指定多次是错误的.

4.4 Canonicalization and Format Requirements (规范化和格式要求)​

所有已注册的媒体类型必须采用单一的规范编码格式 (canonical encoding format).

4.5 Interchange Recommendations (互换建议)​

媒体类型应该包括关于如何最好地在异构系统之间完成互换的建议.

4.6 Security Requirements (安全要求)​

必须对所有注册进行安全问题分析.所有媒体类型注册必须包括详细说明媒体类型安全影响的"Security considerations" (安全考虑) 部分.

4.7 Requirements Specific to XML Media Types (特定于 XML 媒体类型的要求)​

使用 XML 的媒体类型必须符合 [RFC7303] 中指定的要求.

4.8 Encoding Requirements (编码要求)​

媒体类型注册必须明确指定如何对类型进行编码以与各种传输协议一起使用.

4.9 Usage and Implementation Non-Requirements (使用和实现非要求)​

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

4.10 Publication Requirements (发布要求)​

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

4.11 Fragment Identifier Requirements (片段标识符要求)​

使用片段标识符 (fragment identifiers) 的媒体类型必须记录支持哪种片段标识符语法.

4.12 Additional Information (附加信息)​

媒体类型注册模板包括许多附加信息字段.

Last updated on