Summary

  • CLDAP cut connection overhead for simple directory lookups by sending a restricted LDAP-derived operation set over UDP, but it also left reliability, freshness and retries at the edges.
  • RFC 3352 did not blame one flaw or prove universal failure: it recorded a bundle of probable limits—especially missing integrity and confidentiality—then recommended moving RFC 1798 to Historic while further experimentation continued.

A shorter lookup with a narrower promise

The original CLDAP specification began with a practical objection: a directory read can be small while the machinery around it is not. RFC 1798 compared the exchanges required by X.500's Directory Access Protocol and ordinary LDAP with a simpler request path. For an application that needed a few attributes from one entry, the connection setup and session work could cost more elapsed time than the lookup itself. CLDAP tried to remove that cost.

Its bargain was explicit. CLDAP borrowed LDAP's message structures, but carried them over UDP or another connectionless transport and exposed a restricted set of operations. The RFC's example reduced a lookup to four packets, or two in a colocated or cached case. Those were protocol illustrations, not a benchmark. The target was a narrow job: return a small answer quickly when connection-mode features were unnecessary. RFC 1798 called the protocol a complement to DAP and LDAP, not their replacement. RFC 1798

Removing a connection did not remove state from the problem. Datagrams could be lost, so clients had to choose retries and timeouts for their own operating conditions. The RFC deliberately did not prescribe one retry algorithm. Servers could cache to reduce delay, but the directory path had no cache-invalidation protocol or dontUseCopy control. The fast answer therefore depended on a second decision: how much staleness the application could tolerate. CLDAP moved these reliability and freshness choices toward clients and deployments instead of resolving them in a session protocol.

The sharpest boundary was identity and protection. RFC 1798 did not provide request authentication. An editorial note records discussion of adding credentials, then explains why none were included: authentication overhead might cancel the connectionless advantage. Its conclusion was direct—applications needing authenticated directory access should not use CLDAP. The security section likewise says the protocol itself provides no authentication and expects anonymous or simple, passwordless server binding. Speed was not free; it was purchased by narrowing what the operation could safely claim.

Why the standards record changed

RFC 3352, published in March 2003, looked back at RFC 1798, published in June 1995. It reported that CLDAP had not become widely deployed during the intervening seven years. That wording matters: it is the contemporary assessment written into the RFC, not a deployment census, a claim that no implementation existed, or a measurement of present use.

The report offered several probable reasons, not a proven ranking. CLDAP was anonymous and read-only, limited results to small sizes, lacked integrity and confidentiality protection, had inadequate internationalization and extensibility, and lacked multiple independently developed implementations. These constraints reinforce one another. A small lookup can be useful, but a protocol that cannot protect or verify its request, cannot return larger results, and has a thin independent implementation base is harder to turn into a dependable shared interface. The RFC does not establish which defect mattered most or that every deployment faced every limit. RFC 3352

There was also a maintenance problem. RFC 3352 noted normative references to obsolete specifications, including older X.500 material and RFC 1487. Without an update, those references kept RFC 1798 from remaining on the Standards Track. The LDAP Extensions Working Group had been chartered in 1997 to work on LDAP extensions, but RFC 3352 says it was concluding without an update to CLDAP; no CLDAP standardization effort then remained. The text joins implementation weakness to document maintenance: there was no active revision path to close the gaps or refresh the dependencies.

The result was a recommendation to move RFC 1798 to Historic, not a replacement protocol. RFC 3352 says interest in connectionless directory access remained, but operational experience called for more experimentation, especially around security. It points readers to an LDAP-over-UDP draft as work in progress and to other possible alternatives; it does not claim that draft became a successor standard. The separate move of LDAPv2, specified in RFC 1777, to Historic came in RFC 3494. RFC 3352 concerns CLDAP and should not be flattened into a retirement of LDAP as a whole.

Later LDAPv3 documents—RFC 3377 and then RFCs 4510–4513—provide a different, connection-oriented standards context; their existence does not prove what CLDAP products did.

A status label is not a process kill

“Historic” answers a question about the standards record. It says that this specification should no longer be treated as a current standards-track destination. It does not, by itself, remove code from a server, invalidate an old local installation, or prove that every operator stopped using it. RFC 3352's own language is careful: it makes a status recommendation, describes the contemporaneous deployment judgment and says retirement would not impact Internet security. That last sentence is the RFC author's assessment, not evidence that CLDAP had been secure or that no local risk existed.

The history is therefore more informative than a simple story of an obsolete protocol. CLDAP tried to minimize the initial cost of a lookup. The later record asks whether the narrow design could still satisfy the shared requirements that make a protocol dependable: adequate security, usable internationalization, extensibility, independent implementations and references that can be maintained. Its designers had not hidden the authentication tradeoff; RFC 1798 states it. What RFC 3352 adds is a lifecycle judgment that the overall proposal had not developed a viable path through those constraints.

The editorial lens here is deliberately limited. Heng Lu's “Minimum Initial Specification” and “Running-Code Primacy” arguments ask readers to distinguish a published coordination artifact from adopted operational reality, and a declared design from evidence in running systems. They are not IETF findings and do not establish CLDAP's adoption. Applied as questions, they help keep three records apart: what RFC 1798 specified, what RFC 3352 believed the community had learned, and what individual operators may have continued to run.

The lesson is not that connectionless directory access was inherently unsound, nor that a standards body can make deployed software disappear by relabelling a document. It is narrower: a shortcut that reduces one visible cost can leave security, reliability, freshness and maintenance costs unresolved. When no active revision effort or independent implementation base can carry those costs forward, a standards-track label may promise more maturity than the record supports. Moving the specification to Historic made that limit legible without pretending that publication, status or recommendation was the same thing as adoption.

Sources

Primary record: RFC 3352, RFC Editor, Datatracker; original and context: RFC 1798, RFC Editor, RFC 1777, RFC 3377, RFC 3494, RFC 4510, RFC 4511, RFC 4513, RFC 2026. Disclosed editorial lenses: Heng Lu, Note 64 and Note 65.