Summary

  • RFC 3494 said an independently developed LDAPv2 implementation that followed RFC 1777 would not interoperate with existing implementations, because deployed syntax and semantics had diverged from the document.
  • Moving LDAPv2 and its dependent specifications to Historic changed the standards community’s recommendation. It did not switch off deployed endpoints, and choosing LDAPv3 did not by itself establish authentication, integrity or confidentiality.

Conformance normally promises a meeting place. Two engineers can work from the same public document, build independently and expect their systems to exchange meaningful messages. RFC 3494 recorded the inverse. By March 2003, the LDAPv2 document and the installed population had become different coordinates. Following the older coordinate precisely was no longer a safe route to the network that actually existed.

The split was not presented as theory. RFC 1777 had limited LDAPString characters to IA5, while RFC 1778 supplied related syntax rules involving T.61. RFC 3494 reported that deployed products did not commonly keep those limits. Some used ISO 8859-1, some UCS-2, some UTF-8 and some the machine’s current local character set. “LDAPv2 text” therefore named no single operational repertoire. A laboratory implementation could accept every value permitted by the RFC and still reject the names its intended peer emitted.

The second example was smaller and, for that reason, more revealing. RFC 1777 said an attribute type should use its X.500 textual name. Object identifier 2.5.4.10 was organizationName, not o. Existing LDAPv2 products commonly used the short NAME from the LDAPv3 schema instead. The deployed ecosystem had imported a convention from its successor before the nominal predecessor was retired.

Neither token alone identified the underlying directory object. The long name, the short name and the numeric OID could refer toward the same attribute type, yet a parser still needed an agreed mapping. Schema acceptance, access control, the value returned and the application’s decision all sat farther down the chain. Treating o as a harmless abbreviation hid an interoperability choice inside what looked like typography.

This is why RFC 3494’s language matters. It did not claim that every pair of existing LDAPv2 systems failed. Products sharing the same extra convention could communicate. It said the specification was not generally adhered to and that a newly independent implementation of that specification would not interoperate with existing implementations. Operational compatibility had become lineage-dependent: copying the behaviour of familiar code might work better than reading the standard.

That condition changes incentives. A vendor maintaining installed customers is rewarded for preserving their deviations. A new entrant is punished for formal correctness. Test suites written around dominant products can convert the deviation into a de facto rule without ever changing the RFC. The public specification remains open, but practical entry depends on unwritten knowledge.

Security supplied a second reason to leave. LDAPv2 had no mechanism for data integrity or confidentiality, and RFC 3494 said it did not support modern authentication based on DIGEST-MD5, Kerberos V or X.509 public keys. RFC 1777’s simple bind carried a cleartext password; its Kerberos choices belonged to version 4. LDAPv3’s standards bundle, identified by RFC 3377, incorporated authentication and transport-security work that addressed the earlier IESG concern.

“LDAPv3” was still not a security receipt. RFC 4510 later reorganized the suite, and RFC 4513 describes the mechanisms and their requirements. A deployment has to select a method, validate credentials, establish the protected channel and apply authorization correctly. A version number in Bind proves which protocol version was requested, not that integrity, confidentiality or a strong identity has been achieved.

Retirement also propagated through dependencies. RFC 1781 relied on naming syntax that RFC 2253 no longer carried. RFC 2559 profiled LDAPv2 for PKIX repositories and depended on RFC 1777 while updating RFC 1778. RFC 3494 therefore recommended that these documents, the LDAPv2 core and their already superseded RFC 1484-era ancestors move together to Historic.

Historic was a standards-layer action. RFC 2026 assigns that level to a specification superseded or otherwise considered obsolete. RFC 2400 cautions that a one-word status is only an indication and that the fuller applicability statement matters. The action told developers not to build new LDAPv2 implementations from RFC 1777 and told deployers to prefer LDAPv3. It did not uninstall software, close port 389, terminate sessions or measure how much version-2 traffic remained.

That distinction preserves the historical achievement as well as the failure. LDAP lowered the cost of reaching X.500 directories and helped directory applications spread. Its installed conventions then moved faster than its written contract, while its security model aged. RFC 3494 did not erase that lineage. It changed the target toward which future coordination should converge.

The durable audit is a ladder: document status, implementation behaviour, enabled configuration, negotiated version, chosen character and schema rules, selected security mechanisms, successful exchange, authorization and application outcome. Each rung needs its own receipt. A Historic label can settle the first. It cannot silently supply the rest.

Sources