跳到主要内容

4. 选择注册策略与知名策略 (Choosing a Registration Policy and Well-Known Policies)

4. 选择注册策略与知名策略 (Choosing a Registration Policy and Well-Known Policies)​

registration policy (注册策略) 是控制 registry (注册表) 中新 assignment (分配) 如何被接受的政策。定义注册策略时需要考虑若干问题。

若注册表的 namespace (命名空间) 有限, 分配必须谨慎进行以防耗尽。

即便空间实质上无限, 通常仍希望在分配前至少进行最低限度的 review (审查), 以便:

  • 防止囤积或无谓浪费值。例如, 若空间由文本字符串构成, 可能希望阻止实体获取大量对应于理想名称的字符串 (例如现有公司名称)。

  • 提供 sanity check (合理性检查), 确认请求确实有意义且有必要。经验表明, 来自 subject matter expert (主题专家) 的某种最低限度审查有助于在请求格式错误或并非真正需要时阻止分配 (例如, 已存在针对实质等价服务的分配)。

或许最重要的是, 未经审查的扩展可能影响 interoperability (互操作性) 与 security (安全性)。见 [RFC6709]。

当命名空间实质上无限且不存在潜在的互操作性或安全问题时, assigned numbers (分配的号码) 通常可以在没有任何主观审查的情况下分配给任何人。在此类情况下, IANA (Internet Assigned Numbers Authority, 互联网号码分配机构) 可以直接进行分配, 前提是向 IANA 提供了关于应批准何类请求的详细说明, 且其无需行使主观判断。

若并非如此, 则需要某种程度的审查。然而, 必须在充分审查与注册便利之间取得平衡。在许多情况下, 进行注册的人并非 IETF 参与者; 请求常来自其他标准组织、未直接参与标准的组织、临时社区工作 (例如开源项目) 等。注册不得不必要地困难、不必要地耗费 (时间与资源), 也不应不必要地遭受拒绝。

虽然有时有必要限制可注册的内容 (例如字节中的位等有限资源, 或不受支持的值可能损害协议运行的项目), 但在许多情况下, 将实际使用中的内容体现在注册表中更为重要。过于严格的审查标准与过高的成本 (时间与精力) 会阻碍人们尝试注册。若注册表未能反映实际使用的协议元素, 可能对互联网上的协议部署产生不利影响, 注册表本身也会贬值。

因此, 重要的是具体思考注册策略, 而非任意选择或从其他文档复制文本。工作组与其他文档开发者在文档创建注册表时应谨慎选择适当的注册策略。应选择满足注册表需要的最宽松策略, 并对需要显著社区参与的政策 (就知名策略而言, 比 Expert Review (专家评审) 或 Specification Required (需要规范) 更严格者) 寻求具体 justification (理由)。此处需求因注册表而异, 且会随时间变化, 本 BCP (Best Current Practice, 最佳当前实践) 也不会是对此主题的定论。

以下为常见用法定义的策略。它们涵盖用于描述在命名空间中分配新值的程序的典型策略范围。文档并非严格必须使用这些术语; 实际要求是对 IANA 的说明清晰无歧义。然而, 强烈建议使用这些术语, 因为其含义被广泛理解。若这些策略均不适用, 可以使用新制定的策略, 包括以新颖方式组合与这些术语相关的程序要素; 若说明为何如此, 将有助于审查过程。以下各小节完整解释这些术语。

  1. Private Use (私用)
  2. Experimental Use (实验性使用)
  3. Hierarchical Allocation (层次化分配)
  4. First Come First Served (先到先得)
  5. Expert Review (专家评审)
  6. Specification Required (需要规范)
  7. RFC Required (需要 RFC)
  8. IETF Review (IETF 审查)
  9. Standards Action (标准行动)
  10. IESG Approval (IESG 批准)

应注意, 将命名空间划分为多个类别、并在各类别内以不同方式处理分配往往是有意义的。许多协议现在将命名空间划分为两部分或更多, 一部分范围保留给 Private Use 或 Experimental Use, 其他范围保留给遵循某种审查流程分配的全局唯一分配。将命名空间划分为范围使得可以为不同范围与不同用例实施不同策略。

同样, 通常有必要并行指定多种策略, 每种策略在不同情况下使用。关于该主题的更多讨论见第 4.12 节。

并行指定多种策略的 RFC 示例:

  • LDAP [RFC4520]
  • TLS ClientCertificateType Identifiers [RFC5246] (如下文各小节详述)
  • MPLS Pseudowire Types Registry [RFC4446]
最后于 更新