摘要

  • CLDAP 用 UDP 和受限的操作集合，降低了小型目录查询的连接成本；代价是可靠性、重试和数据新鲜度更多落在具体部署者身上。
  • RFC 3352 没有把结果归因于单一缺陷，而是列出一组可能因素，尤其是缺少完整性和机密性保护，并建议将 RFC 1798 移入历史状态，同时继续实验。

查询更短，承诺也更窄

RFC 1798 从一个实际问题出发：若应用只需读取一个目录条目的少量属性，建立连接、启动会话所耗费的时间可能比查询本身还长。CLDAP 因此重用 LDAP 的消息结构，却通过 UDP 或其他无连接传输发送，并只保留部分操作。RFC 举例称一次查询可用四个数据包完成，在某些本地部署或缓存条件下可缩减为两个。这是协议交换示例，不是性能测试结果。

原文将 CLDAP 定位为 DAP 与 LDAP 的补充，而非普遍替代品。无连接传输允许请求或响应丢失，因此客户端必须自行设定超时和重试策略；RFC 没有规定一个适用于所有环境的算法。服务器缓存可以降低延迟，但 RFC 1798 指出，DAP 路径缺乏缓存失效协议，也没有 dontUseCopy 控制。于是，“更快”把两个具体选择留给了部署者：允许多久的数据陈旧，以及客户端如何获得足够可靠的答复。RFC 1798

安全边界更加明确。CLDAP 不提供请求认证。RFC 1798 的编者说明记下了增加凭据的讨论，也说明为何最终没有加入：额外开销可能抵消无连接设计的优势。它直接指出，需要认证目录访问的应用不适合使用 CLDAP。这一取舍从一开始就在规格文本里，而不是多年后才被发现。

退场报告列出的不是单一死因

RFC 3352 于 2003 年 3 月发布，回顾了 1995 年 6 月发布的 RFC 1798。它称 CLDAP 在这七年里并未在 Internet 上广泛部署。这句话是 RFC 作者当时写下的判断，不是量化普查；它既不证明没有任何实现，也不是对今天使用情况的测量。

作者列出的是“可能”原因，而非已证实的因果排序：匿名且只读、结果大小有限、没有完整性和机密性保护、国际化支持不足、扩展能力不够，以及缺少多个独立开发的实现。这些因素会互相加重。即使某种用途只需小型结果，如果接口难以保护、扩展和互操作，也更难成为可长期维护的共同契约。RFC 没有证明哪项缺陷最重要，也没有说每个部署都同时遇到所有问题。RFC 3352

另一个压力来自规格维护。RFC 3352 指出，RFC 1798 规范性引用了一些已经过时的技术规格，包括早期 X.500 文档和 RFC 1487。若不更新，这些依赖使它无法继续留在标准轨道上。LDAP Extensions 工作组于 1997 年成立，但 RFC 3352 写道，该组即将结束，却没有为 CLDAP 产出更新；当时也已没有针对 CLDAP 的标准化工作。

因此，结论是建议把 RFC 1798 转为 Historic，并非发布继任协议。RFC 3352 承认，无连接目录访问仍有人感兴趣，但根据运行经验，仍需更多实验，特别是处理安全问题。它提及一份 LDAP-over-UDP 草案，但标注为进行中的工作，不是替代标准。LDAPv2 的退役是另一项记录：其规格 RFC 1777 后来由 RFC 3494 移入 Historic。RFC 3352 讨论的是 CLDAP，不是把整个 LDAP 判退。后续 LDAPv3 文档可提供不同的技术背景，却不能证明 CLDAP 产品实际运行了什么。

Historic 不是卸载命令

Historic 描述的是一份规格在标准记录中的位置。这个标签本身不会卸载服务器、使某台本地旧系统无效，也不能证明所有运营者都停用了相关接口。RFC 3352 作出的是状态建议，并在安全考虑中称这次退役不会影响 Internet 安全。那是作者的评估，不是 CLDAP 安全无虞或任何本地部署都没有风险的证据。

这段历史的意义在于生命周期，而不只是“旧协议”。CLDAP 优化了一个显眼成本——连接建立，却把保护、丢包、数据新鲜度、结果大小和后续演进留作问题。RFC 3352 的当时评估没有看到一条可行的修订路径，也没有看到足以支撑标准的独立实现基础。改变文档状态让这个限度更清楚，却不会把建议变成部署事实或强制停机令。

这里披露采用 Heng Lu 关于最小初始规格和运行代码优先的观点作为编辑分析框架，而非 IETF 的发现。它提醒我们区分三件事：RFC 1798 写了什么、RFC 3352 认为社区从运行经验中看到了什么、以及个别运营者后来可能仍在运行什么。现有来源并未给出安装数量、具体产品行为或迁移日期，不能补写这些事实。

来源

核心记录：RFC 3352 正文、RFC Editor和IETF Datatracker；原始协议及后续背景：RFC 1798 正文、RFC Editor、RFC 1777、RFC 3377、RFC 3494、RFC 4510、RFC 4511、RFC 4513、RFC 2026。编辑视角（并非 IETF 证据）：Heng Lu，Note 64和Note 65。