3.1. 注册的文档要求

3.1. 注册的文档要求 (Documentation Requirements for Registrations)

通常，文档会请求在现有注册表（由先前发布的文档创建的注册表）中进行分配。

此类文档应明确标识要注册每个值的注册表。使用 IANA 网页上列出的确切注册表名称，并引用定义注册表的 RFC。当引用现有注册表时，提供 URL 以精确识别注册表很有帮助（请参见第 2.2 节）。

在现有注册表中进行新分配时，无需提及分配策略是什么，因为这应该从引用中清楚。但是，如果可能适用多个分配策略，例如在具有不同范围且具有不同策略的注册表中，重要的是明确请求哪个范围，以便 IANA 知道哪个策略适用并可以在正确的范围内分配值。

确保提供注册所需的所有信息，并遵循为注册表设置的任何特殊流程。注册表有时需要完成注册模板进行注册，或要求注册者在注册前将其请求发布到特定邮件列表进行讨论。查找注册表的参考文档：所需信息和特殊流程应在那里记录。

通常，要使用的数值由 IANA 在文档获得批准时选择；草稿不应指定最终值。相反，应在整个文档中一致使用诸如 "TBD1" 和 "TBD2" 之类的占位符，为要注册的每个项目提供不同的占位符。IANA 注意事项应要求 RFC 编辑器用 IANA 分配的值替换占位符名称。当草稿需要为测试或早期实现指定数值时，它们将请求早期分配（请参见第 3.4 节）或使用已经为测试或实验预留的值（如果相关注册表允许无需明确分配）。重要的是草稿不要选择自己的值，以免 IANA 在此期间将这些值之一分配给另一个文档。草稿可以在 IANA 注意事项部分中请求特定值，IANA 将在可能的情况下满足此类请求，但所提议的编号可能在草稿获得批准时已被分配给其他用途。

通常，要使用的文本字符串值在文档中指定，因为文本字符串不太可能发生冲突。如果实际上存在冲突，IANA 将与作者协商，并且必须使用不同的值。当草稿需要为测试或早期实现指定字符串值时，它们有时会使用预期的最终值。但使用草稿值通常很有用，可能包括草稿版本号。这允许将早期实现与实现最终版本的实现区分开来。例如，打算在最终版本中使用 "foobar" 的文档可能在草稿的 -05 版本中使用 "foobar-testing-draft-05"。

对于某些注册表，存在长期政策，禁止基于虚荣或组织名称分配名称或代码。例如，除非有充分的理由进行例外，否则代码可能总是按顺序分配。本文档中的任何内容都不旨在更改这些政策或阻止其未来应用。

作为示例，可以使用以下文本来请求分配 DHCPv6 选项编号：

要求 IANA 将选项代码值 TBD1 分配给 DNS 递归名称服务器选项，
并将选项代码值 TBD2 分配给域搜索列表选项，
这些值来自 RFC 3315 第 24.3 节中定义的 DHCP 选项代码空间。

IANA 注意事项部分应总结所有 IANA 操作，并根据需要指向文档其他地方的相关部分。当参考文档很大时，包含节号特别有用；节号将使搜索参考文档的人更容易找到相关信息。

当请求多个值时，包含添加/更改的摘要表通常很有帮助。该表与它在 IANA 网站上出现或将出现的格式相同也很有帮助。例如：

Value     Description          Reference
--------  -------------------  ---------
TBD1      Foobar               this RFC, Section 3.2
TBD2      Gumbo                this RFC, Section 3.3
TBD3      Banana               this RFC, Section 3.4

注意：在作者认为包含完整的更改表过于冗长或重复的情况下，作者仍应在草稿中包含该表，但可以包含一条说明，要求在最终 RFC 发布前删除该表。