摘要

  • RFC 3383 没有给所有 LDAP 扩展设置同一道审批门槛，而是把 Standards Action、专家评议、Specification Required、先到先得、实验和私用空间分配给不同的互操作风险。
  • 登记标识符只是协调证据，不是实现、安全或互操作认证；真正有价值的是它所连接的公开规范、负责人、评议过程与变更控制路径。

两个开发者都可以“扩展 LDAP”，却仍可能造出无法互通的产品。假如双方把同一个结果码整数赋予不同含义，线上的数值依旧能被正常解码，但语义已经分裂。问题不是空间不够，而是共享空间被占了两次。

RFC 3383 于 2002 年 9 月以 BCP 64 发布，把这件事视为会产生技术后果的治理问题。LDAP 已允许增加操作、扩展既有操作并扩充 schema。文档要解决的是：这些扩展的标识符怎样进入共同使用，才能不让灵活性变成碰撞。

答案并非统一排队。消息类型、结果码、认证方法、协议机制、OID descriptor 与 AttributeDescription option 的风险不同，因此登记摩擦也不同。

IETF 开发的元素可以申请 Internet Directory Numbers 弧下的一个 OID。它需要 Expert Review with Specification Required。获得该弧后，规范可以自行分配任意数量的下级 OID，不必让 IANA 审批每个叶子。登记处协调树枝，定义文档治理枝下的局部空间。

其他开发者可以使用正确授权的 OID，包括 Private Enterprise Number 下的空间。开发中的早期实现被建议使用实验 OID，以免先行代码与后来发布规范所选标识发生冲突。实验 OID 不应写入正式发布规范；临时通道之所以有用，正因为它不是终点。

可发现的控制与扩展又采用另一种平衡。Root DSE 可以用 OID 宣告支持的机制。普通可发现机制大体按 First Come First Served with Specification Required 登记，让公开技术说明可查，却不要求完整标准行动；Standards Track 机制则必须经 Standards Action。

这些政策不能压成同一种“批准”。先到先得不证明技术质量，Specification Required 不等于 IETF 标准化，Standards Action 也不证明已经部署。它们只回答某个值进入某类共享空间之前必须具备什么证据和评议。

descriptor 是数字 OID 上的人类可读名称，不区分大小写，同一 OID 还能有多个名称。以连字符结尾的名称可以保留整个名称族。x- 开头属于 Private Use，不能登记；e- 开头留给实验并采用先到先得；其他 descriptor 需要专家评议。AttributeDescription option 也有相似分区。前缀不是装饰，而是在声明不同的协调承诺。

结果码的数值区间把风险分配写得更清楚：0 至 1023 需要 Standards Action；1024 至 4095 需要 Expert Review with Specification Required；4096 至 16383 采用先到先得，并配合 e- 实验关键字；16384 以上和 x- 关键字属于不可登记的 Private Use。

认证方法沿用这些区间，还要标为 COMMON、LIMITED USE 或 OBSOLETE。没有公开规范的方法不能标 COMMON，新登记也不能直接以 OBSOLETE 进入。登记记录的不只是号码，还有对预期用途的主张以及支撑该主张的证据条件。

新 LDAP 消息类型需要 Standards Action。LDAP 的可扩展消息减少了新增顶层类型的需要，却没有完全消除它。改变消息封套的基本选择空间，与命名一次私有实验显然不是同一种协调成本。

RFC 3383 也知道何时应关闭登记。Directory Systems Names 曾服务于 LDAPv2 distinguished name 的字符串表示；LDAPv3 改用语法不同的 OID descriptor。旧名单停止接受新登记，却仍须为历史用途公开保存。关闭不等于抹除。

登记程序让政策能够执行。Standards Action 经过 IESG。专家评议请求要用完整模板公开两周；一旦修订表格，评议期重新开始；任何参与者都可以提出异议；专家批准并转交，或者拒绝，决定还可以申诉。先到先得则把完整表格直接交给 IANA。

所有权决定日后如何维护。Standards Action 值由 IESG 视为所有者；专家评议与先到先得值通常由申请者持有。所有者可以按新登记相同的约束更新记录。若其无法或不愿完成必要修正，IESG 可以接管；第三方重大异议在专家评议后还能作为评论附在登记项上。协调保存的不只是最终表格，也包括争议的记忆。

附录模板揭示登记真正要保存什么：标识符、描述、规范、联系人、作者或变更控制者、用途和评论。裸号码只能避免两次干净分配完全相同，却无法解释号码的含义、谁能修正它、实现者去哪里找技术契约。

RFC 2434 提供了当时的一般登记政策词汇，RFC 8126 后来更新了相关指导。今天的 IANA LDAP Parameters 页面说明登记表仍是活的公共表面，但不能据此断言每个字段和程序自 2002 年以来从未变化，更不能证明每个条目都有活跃实现。

RFC 3377 把 RFC 3383 放在当时 LDAPv3 技术规范的语境中；RFC 2251、RFC 2252 与 RFC 2255 提供协议、schema 和 URL 扩展背景；RFC 4510 后来描述修订后的 LDAP 技术规范。这些连接证明年代与依赖，不是采用率调查。

设计的持久价值是“分级摩擦”。会撕裂核心消息语义的碰撞需要 Standards Action；公开定义的普通扩展可采用专家评议或较轻分配；实验和私用仍保留出口，但前缀和区间警告他人不要把它们当作全球协调的公共含义。

用 Lu Heng 的最小初始规范视角看，文档没有预先决定未来每个 LDAP 扩展，而是定义让未来决定保持局部的最小治理底座：分区、政策、模板、所有者和修复路径。他的现实层次视角则提醒我们，分配、登记、规范、实现、部署、协商成功与用户结果是不同层次。

RFC 3383 的历史贡献，是把可扩展性写成了持续保管的责任。标识符给扩展一个位置；政策决定它进入共享空间前必须披露什么；登记表让含义、负责人和纠错路径在分配动作结束多年后仍然可查。

来源