摘要

  • RFC 3494 明确指出：独立开发者若严格按 RFC 1777 实现 LDAPv2，反而无法同现有实现互通，因为部署中的语法和语义已经偏离书面规范。
  • 把 LDAPv2 及其依赖文档移至 Historic，是对未来协调方向的调整，不是远程关机；采用 LDAPv3 这个版本号，也不自动证明认证、完整性或保密性已经成立。

RFC 3494 的锋利之处，不在于说旧协议“过时”，而在于它承认了一个开放标准最尴尬的失败：文档仍然公开、规则仍然清楚，可是照着文档从零实现，已经到不了现实中的网络。

第一条裂缝是字符。RFC 1777 把 LDAPString 编码为 OCTET STRING，却将合法字符限制为 IA5；RFC 1778 又提供了相关属性语法及 T.61 背景。RFC 3494 观察到，实际产品通常不再遵守这些边界：有的用 ISO 8859-1，有的用 UCS-2，有的用 UTF-8，还有的直接依赖本机当前字符集。

这不是“都支持更多字符”这么简单。不同实现可能对同一组字节作不同解释，也可能把同一人名转成不同序列。仅用 ASCII 测试通过，无法证明真实目录中的姓名、机构或证书条目能够往返。一个完全合规的实验室实现，反而可能拒绝现场系统早已接受的数据。

第二条裂缝只有一个字母。RFC 1777 要求使用 X.500 中的文本属性名；对象标识符 2.5.4.10 应写成 organizationName，无法取得文本名时才可写数字 OID。但已部署的 LDAPv2 实现常用 LDAPv3 模式中的短 NAME：o。继任规范的习惯，先于正式退役进入了旧协议的现实。

长名、短名和数字 OID 可以指向同一属性类型，但这不等于任何解析器都会把它们认成同一件事。映射成功也不证明模式接受、访问控制允许、属性值正确或应用动作完成。把 organizationName 改写成 o 的兼容层解决了一处接口，同时也产生了一条必须被记录和治理的新规则。

因此，RFC 3494 并没有断言所有 LDAPv2 产品彼此都不能工作。共享相同历史和偏差的客户端、服务器当然可能互通。它说的是规范“不被普遍遵守”，以及独立按规范实现的软件无法同现有实现互通。互操作的权威从公开文档转移到了产品血缘和隐性经验。

这种转移制造锁定。既有供应商若纠正文档偏差，会破坏客户；新供应商若坚持形式合规，会丢掉客户。测试套件也容易从“是否符合 RFC”变成“是否像主流产品”。名义上开放的接口，实际门票变成未经标准化的兼容知识。

安全问题让离开的理由更充分。RFC 3494 指出 LDAPv2 没有数据完整性和保密机制，也不支持 DIGEST-MD5、Kerberos V、X.509 公钥等当时现代的认证方式。RFC 1777 的 simple bind 只携带明文密码，并列出的还是 Kerberos 4。RFC 3377 随后把 LDAPv3 的认证与传输安全文档纳入完整技术规范，以回应此前 IESG 对更新功能安全性的警告。

但“LDAPv3”仍不是安全收据。RFC 4510 后来重组整套规范，RFC 4513 说明认证和安全机制。操作者仍需选择机制、建立受保护通道、核验凭据并正确实施授权。Bind 中请求版本 3，只证明客户端请求了哪个协议版本，不证明 TLS、SASL、强身份或正确权限已经生效。

退役还沿依赖关系传播。RFC 1781 依赖 RFC 1779 的友好命名语法，而 RFC 2253 不再保留它。RFC 2559 把 LDAPv2 用于 PKIX 仓库，依赖 RFC 1777 并更新 RFC 1778。RFC 3494 因而建议把这些文档、LDAPv2 核心，以及已被替代的 RFC 1484、1485、1487、1488 一并移至 Historic。

Historic 描述文档状态，不描述进程存亡。RFC 2026 将它用于已被替代或因其他理由被视为过时的规范；RFC 2400 提醒，单词状态只是指示，必须结合适用性说明。2003 年的动作告诉开发者不要再按 RFC 1777 新做 LDAPv2，告诉部署者优先使用 LDAPv3。它没有关闭 389 端口，没有卸载软件，也没有测量剩余流量。

这段历史也不应抹杀 LDAP 的贡献。它降低了访问 X.500 目录的成本，促成了真实部署；正因为部署形成规模，实践才有能力偏离文本。RFC 3494 不是把过去宣布为不存在，而是重新选择未来要共同趋近的坐标。

审计时应保留一串独立收据：RFC 状态、实现行为、启用配置、请求版本、字符转换、模式别名、安全机制、交换结果、授权结果和应用结果。Historic 能证明第一项制度决定，不能替代后面的任何运行事实。

来源