2.2. 注册表的文档要求
2.2. 注册表的文档要求 (Documentation Requirements for Registries)
创建新命名空间(或修改现有空间的定义)并期望 IANA 在维护该空间(作为已注册值的存储库)中发挥作用的文档,必须在 IANA 注意事项部分或从中引用的位置提供关于命名空间详细信息的明确说明。
特别是,此类说明必须包括:
注册表的名称 (The name of the registry)
该名称将出现在 IANA 网页上,并将在需要从新空间分配值的未来文档中引用。应提供完整名称(以及缩写,如适用)。非常希望所选名称不容易与另一个注册表的名称混淆。
创建注册表时,必须使用其完整名称识别它所属的组,完全如协议注册表列表中所显示的那样。
提供 URL 以精确识别注册表有助于 IANA 理解请求。此类 URL 可以在最终发布前从 RFC 中删除或留在文档中供参考。如果包含 iana.org URL,IANA 将在审查期间根据需要提供更正。
注册所需的信息 (Required information for registrations)
这告诉注册者他们必须在注册请求中包含哪些信息。一些注册表只需要请求的值和对定义值使用的文档的引用。其他注册表需要更详细的注册模板,描述相关的安全考虑、国际化考虑和其他此类信息。
适用的注册策略 (Applicable registration policy)
将适用于所有未来注册请求的策略。请参见第 4 节。
注册表条目的大小、格式和语法 (Size, format, and syntax of registry entries)
要在注册表中记录哪些字段,对注册表条目的任何技术要求(整数的有效范围、字符串的长度限制等),以及应显示注册表值的确切格式。对于数字分配,应指定是以十进制、十六进制还是其他格式记录值。
字符串预期为 ASCII,应明确指定大小写是否重要,以及例如字符串是否应在注册表中以大写或小写显示。
表示协议参数的字符串很少(如果有的话)需要包含非 ASCII 字符。如果确实需要非 ASCII 字符,说明应非常明确地说明允许它们,并且应使用"(U+XXXX)"约定将非 ASCII 字符表示为 Unicode 字符。任何创建此类注册表的人都应仔细考虑这一点,并考虑国际化建议,例如 [RFC7564] 第 10 节中的建议。
初始分配和保留 (Initial assignments and reservations)
要包含的任何初始分配或注册。此外,应指示要为"私有使用"、"保留"、"未分配"等保留的任何范围(请参见第 6 节)。
例如,文档可能通过包含以下内容来指定新注册表:
---------------------------------------------------------------
X. IANA 注意事项
本文档定义了一个名为"FooBar"的新 DHCP 选项(参见第 y 节),
并从 DHCP 选项空间分配了 TBD1 值
<https://www.iana.org/assignments/bootp-dhcp-parameters>
[RFC2132] [RFC2939]:
Data
Tag Name Length Meaning
---- ---- ------ -------
TBD1 FooBar N FooBar 服务器
FooBar 选项还定义了一个 8 位 FooType 字段,IANA 需要为此
创建和维护一个名为"FooType values"的新注册表,供 FooBar 选项使用。
DHCP FooBar FooType 注册表的初始值如下;未来的分配
将通过专家审查 [BCP26] 进行。分配包括
DHCP FooBar FooType 名称及其关联值。
Value DHCP FooBar FooType Name Definition
---- ------------------------ ----------
0 Reserved
1 Frobnitz RFCXXXX, Section y.1
2 NitzFrob RFCXXXX, Section y.2
3-254 Unassigned
255 Reserved
---------------------------------------------------------------
有关建立注册表的文档示例,请参阅 [RFC3575]、[RFC3968] 和 [RFC4520]。
每当 IANA 在公共注册表中包含姓名和联系信息时,一些个人可能更喜欢不公开其联系信息。在这种情况下,可以与 IANA 安排保持联系信息的私密性。