3. 注册树和子类型名称
为了提高注册流程的效率和灵活性, 可以注册具有不同结构的子类型名称, 以适应不同的自然需求.例如, 某个子类型可能被建议由 Internet 社区广泛支持和实现, 而另一个子类型可能用于传送与专有软件相关的文件.以下小节定义注册 "树", 它们通过使用分面名称来区分, 例如以 "tree." 前缀开头的子类型名称.注意, 本文档之前定义的某些媒体类型并不符合下文描述的命名约定.相关讨论见附录 A.
3.1 标准树
标准树用于 Internet 社区普遍关注的类型.标准树中的注册 MUST 属于以下两种情况之一:
-
对于与 IETF 规范关联的注册, 由 IESG 直接批准, 或
-
由受认可的标准相关组织使用 "Specification Required" IANA 注册策略 [RFC5226] (这意味着 Expert Review) 进行注册.
第一种程序用于来自 IETF Consensus 文档的注册, 或在少数情况下, 当注册祖父化 (见附录 A) 和/或其他不完整注册符合 Internet 社区利益时使用.注册提案 MUST 作为 RFC 发布.当注册 RFC 属于 IETF 流时, 它必须具有 IETF Consensus, 该共识可通过 Standards Track, BCP, Informational 或 Experimental 状态取得.也允许在非 IETF RFC 流中发布注册, 但需要 IESG 批准.注册可以位于独立的 "registration only" RFC 中, 也可以并入某种更通用的规范.
在第二种情况下, IESG 对注册提交者是否代表受认可的标准相关组织作出一次性决定; 此后, 媒体类型审查者 (Designated Expert 或一组 Designated Experts) 按本文档规定执行 Expert Review.来自同一来源的后续提交不涉及 IESG.该格式 MUST 由提交注册的标准相关组织生成的正式标准规范描述.
标准树中的媒体类型 MUST NOT 具有分面名称, 除非它们通过附录 A 所述流程被祖父化.
在标准树中注册的媒体类型的 "owner" 被认为是标准相关组织本身.对规范进行修改或变更时, 使用与初始注册相同级别的处理 (例如, 以 Standards Track 提交的注册可以在另一个 Standards Track RFC 中修订, 但不能在 Informational RFC 中修订).
来自受认可标准相关组织的标准树注册直接提交给 IANA, 在批准前进行 Expert Review [RFC5226].在这种情况下, Expert Reviewer 将确保所需规范提供充分文档, 这只是其职责之一.
3.2 供应商树
供应商树用于与公开可用产品关联的媒体类型.在此上下文中, "vendor" 和 "producer" 解释得非常宽泛, 并被视为等同.注意, 不符合受认可标准相关组织资格的行业联盟以及非商业实体, 也完全可以在供应商树中注册媒体类型.
任何需要交换与某个产品或一组产品相关文件的人都可以将注册放入供应商树.但是, 该注册实际属于生产使用所注册类型的软件的供应商或组织, 并且该供应商或组织可以随时选择主张对第三方所做注册的所有权, 以便更正或更新该注册.更多信息见第 5.5 节.
当第三方代表其他人注册类型时, 注册中的 Change Controller 字段 SHOULD 记录两个实体.一种可能格式为 "Foo, on behalf of Bar".
供应商树注册通过前导分面 "vnd." 区分.其后可以由注册者自行决定, 接来自知名生产者的媒体子类型名称 (例如 "vnd.mudpie"), 或接经 IANA 批准的生产者名称标识, 再后接媒体类型或产品标识 (例如 vnd.bigcompany.funnypictures).
虽然在供应商树中注册的媒体类型不要求公开暴露和审查, 但鼓励使用 [email protected] 邮件列表进行审查, 以提高这些规范的质量.供应商树中的注册可以直接提交给 IANA, 并在批准前进行 Expert Review [RFC5226].
3.3 个人或虚荣树
实验性创建的媒体类型, 或作为非商业分发产品一部分创建的媒体类型, 可以在个人或虚荣树中注册.这些注册通过前导分面 "prs." 区分.
"personal" 注册及其关联规范的所有者是进行注册的个人或实体, 或如下文所述责任已转移到的个人或实体.
虽然在个人树中注册的媒体类型不要求公开暴露和审查, 但鼓励使用 [email protected] 邮件列表 (见第 5.1 节) 进行审查, 以提高这些规范的质量.个人树中的注册可以直接提交给 IANA, 并在批准前进行 Expert Review [RFC5226].
3.4 未注册的 x. 树
以 "x." 作为第一个分面的子类型名称可用于专门在私有,本地环境中使用的类型.此树中的类型不能注册, 并且仅拟在交换双方明确同意的情况下使用.
然而, 有了上述供应商树和个人树的简化注册程序, 很少需要使用未注册类型, 如果还有需要也应极少.因此, 强烈不建议使用 "x." 树中的类型.
注意, 名称以 "x-" 开头的类型不再被视为此树的成员 (见 [RFC6648]).还需注意, 如果某个通常有用且广泛部署的类型错误地使用了 "x-" 名称前缀, 它 MAY 按照附录 A 中定义的程序, 使用其当前名称注册到替代树中.
3.5 附加注册树
根据社区不时提出的需求, 可以通过 IETF Standards Action 创建新的顶层注册树.明确假定这些树可以创建出来, 供知名的永久性组织进行外部注册和管理, 例如由科学学会管理其覆盖科学领域特定的媒体类型.