3. Registration Trees and Subtype Names (注册树与子类型名称)

为了提高注册过程的效率和灵活性,可以注册不同结构的子类型名称以适应不同的自然需求,例如,建议互联网社区广泛支持和实现的子类型,或用于移动与专有软件相关的文件的子类型.以下小节定义了由分面名称 (faceted names) 的使用所区分的注册"树"(trees),例如,以"tree."前缀开头的子类型名称.请注意,在本文档之前定义的某些媒体类型不符合下述命名约定.有关它们的讨论,请参见附录 A.

3.1 Standards Tree (标准树)

标准树旨在用于互联网社区普遍感兴趣的类型.标准树中的注册必须是:

1. 对于与 IETF 规范相关的注册,由 IESG 直接批准,或

2. 由公认的标准相关组织使用 "Specification Required" IANA 注册策略 RFC5226进行注册.

第一个程序用于来自 IETF Consensus 文档的注册,或在罕见情况下,当注册一个祖父级 (grandfathered)(见附录 A) 和/或其他不完整的注册符合互联网社区的利益时.注册提案必须作为 RFC 发布.当注册 RFC 在 IETF 流中时,它必须具有 IETF Consensus,这可以通过 Standards Track,BCP,Informational 或 Experimental 的状态来达到.在非 IETF RFC 流中发布的注册也是允许的,并需要 IESG 批准.注册可以在独立的"仅注册"RFC 中,也可以合并到某种更通用的规范中.

在第二种情况下,IESG 对注册提交者是否代表公认的标准相关组织做出一次性决定;之后,媒体类型审查者 (Media Types Reviewer)(指定专家或一组指定专家)按照本文档中规定的方式执行专家审查.来自同一来源的后续提交不涉及 IESG.格式必须由提交的标准相关组织生成的正式标准规范描述.

标准树中的媒体类型不得具有分面名称,除非它们使用附录 A 中描述的过程进行祖父化.

在标准树中注册的媒体类型的"所有者" (owner) 被假定为标准相关组织本身.规范的修改或更改使用与初始注册相同的处理级别(例如,在 Standards Track 上提交的注册可以在另一个 Standards Track RFC 中修订,但不能在 Informational RFC 中修订).

来自公认标准相关组织的标准树注册直接提交给 IANA,在那里它们将在批准之前经过专家审查 [RFC5226].在这种情况下,专家审查者将确保所需的规范提供足够的文档,以及其他事项.

3.2 Vendor Tree (供应商树)

供应商树用于与公开可用产品相关的媒体类型.在此上下文中,"Vendor" (供应商) 和 "producer" (生产商) 被非常广泛地解释,并被视为等同.请注意,不符合公认标准相关组织资格的行业联盟以及非商业实体可以非常适当地在供应商树中注册媒体类型.

任何需要交换与某些产品或产品集相关的文件的人都可以在供应商树中进行注册.但是,注册适当地属于生产使用所注册类型的软件的供应商或组织,并且该供应商或组织可以随时选择主张由第三方完成的注册的所有权,以便更正或更新它.有关更多信息,请参见第 5.5 节.

当第三方代表其他人注册类型时,两个实体都应该在注册的 Change Controller (变更控制者) 字段中注明.此情况的一种可能格式是 "Foo, on behalf of Bar" (Foo 代表 Bar).

供应商树注册将通过前导分面 "vnd." 来区分.这可以根据注册者的自由裁量权,后跟来自知名生产商的媒体子类型名称(例如 "vnd.mudpie"),或后跟 IANA 批准的生产商名称指定,该指定后跟媒体类型或产品指定(例如 vnd.bigcompany.funnypictures).

虽然不要求对在供应商树中注册的媒体类型进行公开披露和审查,但鼓励使用 [email protected] 邮件列表进行审查,以提高这些规范的质量.供应商树中的注册可以直接提交给 IANA,在那里它们将在批准之前经过专家审查 [RFC5226].

3.3 Personal or Vanity Tree (个人或虚荣树)

为实验创建的或作为非商业分发产品的一部分创建的媒体类型的注册可以在个人或虚荣树中注册.这些注册通过前导分面 "prs." 来区分.

"个人" (personal) 注册及相关规范的所有者是进行注册的人或实体,或如下所述已转移责任的人.

虽然不要求对在个人树中注册的媒体类型进行公开披露和审查,但鼓励使用 [email protected] 邮件列表(见第 5.1 节)进行审查,以提高这些规范的质量.个人树中的注册可以直接提交给 IANA,在那里它们将在批准之前经过专家审查 [RFC5226].

3.4 Unregistered x. Tree (未注册 x. 树)

具有 "x." 作为第一个分面的子类型名称可用于专门在私有本地环境中使用的类型.此树中的类型不能注册,并且仅用于在交换它们的各方积极同意的情况下使用.

但是,使用上述针对供应商树和个人树描述的简化注册程序,应该很少(如果有的话)需要使用未注册的类型.因此,强烈不鼓励使用 "x." 树中的类型.

请注意,名称以 "x-" 开头的类型不再被视为此树的成员(见 [RFC6648]).还要注意,如果一个通常有用且广泛部署的类型错误地以 "x-" 名称前缀结束,则可以按照附录 A 中定义的程序使用其当前名称在替代树中注册.

3.5 Additional Registration Trees (附加注册树)

根据社区的需要,可以通过 IETF Standards Action 不时创建新的顶级注册树.明确假定这些树可能是为知名永久组织的外部注册和管理而创建的,例如科学社团,用于其所涵盖的科学特定的媒体类型.

---