Zusammenfassung

  • CLDAP senkte mit UDP und einer begrenzten Auswahl an Operationen den Verbindungsaufwand kleiner Verzeichnisabfragen; Zuverlässigkeit, Wiederholungen und Aktualität der Antworten blieben jedoch Entscheidungen der jeweiligen Bereitstellung.
  • RFC 3352 machte nicht einen einzelnen Fehler verantwortlich, sondern hielt mehrere wahrscheinliche Gründe fest – besonders fehlenden Integritäts- und Vertraulichkeitsschutz – und empfahl, RFC 1798 als Historic einzustufen, während weitere Experimente nötig blieben.

Eine kürzere Abfrage mit engerem Versprechen

RFC 1798 begann mit einer praktischen Frage: Warum eine vollständige Verbindung und Sitzung einrichten, wenn nur wenige Attribute eines einzelnen Verzeichniseintrags gelesen werden? CLDAP übernahm LDAP-Nachrichtenstrukturen, übertrug sie aber mit UDP oder einem anderen verbindungslosen Transport und beschränkte die verfügbaren Operationen. Das RFC illustriert eine Abfrage mit vier Paketen, unter bestimmten lokalen oder Cache-Bedingungen mit zwei. Das ist ein Ablaufbeispiel, kein Benchmark.

CLDAP sollte DAP und LDAP ergänzen, nicht allgemein ersetzen. Datagramme können verloren gehen; Clients mussten daher eigene Zeitlimits und Wiederholungsregeln wählen. RFC 1798 schrieb keinen universellen Algorithmus vor. Caching konnte die Antwort beschleunigen, doch der DAP-Pfad hatte weder ein Cache-Invalidierungsprotokoll noch eine dontUseCopy-Steuerung. Die geringere Latenz verlagerte somit Entscheidungen über Zuverlässigkeit und zulässige Datenalterung zu Implementierern und Betreibern. RFC 1798

Die Sicherheitsgrenze war noch deutlicher: CLDAP bot keine Authentifizierung von Anfragen. Eine redaktionelle Anmerkung in RFC 1798 dokumentiert die Diskussion über Zugangsdaten, erklärt aber auch, warum sie fehlten: Ihr Aufwand hätte den Vorteil des verbindungslosen Ansatzes aufheben können. Für Anwendungen, die authentifizierten Verzeichniszugriff benötigen, sei CLDAP ungeeignet. Dieser Kompromiss stand bereits in der ursprünglichen Spezifikation.

Was der Rückblick von 2003 festhielt

RFC 3352 erschien im März 2003 und blickte auf RFC 1798 vom Juni 1995 zurück. Das Dokument stellte fest, dass CLDAP in den sieben Jahren dazwischen im Internet nicht weit verbreitet gewesen sei. Das ist die damalige Einschätzung des RFC-Autors, keine quantitative Bestandsaufnahme, kein Beweis für die Abwesenheit jeder Implementierung und keine Messung heutiger Nutzung.

Genannt werden wahrscheinliche Gründe, keine belegte Kausalrangfolge: anonymer und schreibgeschützter Zugriff, kleine Ergebnisse, fehlender Integritäts- und Vertraulichkeitsschutz, unzureichende Internationalisierung und Erweiterbarkeit sowie das Fehlen mehrerer unabhängig entwickelter Implementierungen. Diese Grenzen verstärkten einander. Ein kleines Ergebnis kann genügen; eine schwer zu schützende, erweiternde und interoperable Schnittstelle wird aber kaum zu einem langfristig tragfähigen gemeinsamen Vertrag. RFC 3352 belegt weder, welcher Mangel am schwersten wog, noch dass jede Bereitstellung alle Probleme hatte. RFC 3352

Hinzu kam dokumentarischer Wartungsaufwand. RFC 3352 verweist auf normative Referenzen zu veralteten Spezifikationen, darunter ältere X.500-Texte und RFC 1487. Ohne Aktualisierung konnten diese Abhängigkeiten RFC 1798 auf dem Standards Track blockieren. Die 1997 gegründete Arbeitsgruppe LDAP Extensions beendete ihre Arbeit ohne CLDAP-Update; ein entsprechendes Standardisierungsvorhaben bestand damals nicht mehr.

Die Empfehlung lautete, RFC 1798 als Historic einzustufen – nicht, ein Nachfolgeprotokoll zu veröffentlichen. RFC 3352 hielt fest, dass Interesse an verbindungslosem Verzeichniszugriff fortbestand, die Betriebserfahrung aber weitere Experimente verlangte, insbesondere zur Sicherheit. Ein Entwurf für LDAP über UDP wird als Arbeit in Bearbeitung erwähnt, nicht als Ersatzstandard. Die separate Einstufung von LDAPv2 aus RFC 1777 als Historic erfolgte mit RFC 3494. RFC 3352 behandelt CLDAP, nicht die Stilllegung von LDAP insgesamt.

Spätere LDAPv3-Dokumente bilden einen anderen technischen Kontext, belegen aber nicht, was CLDAP-Produkte tatsächlich ausführten.

Historic ist kein Löschbefehl

Historic beschreibt die Stellung eines Dokuments im Standardregister. Das Etikett deinstalliert keinen Server, macht eine alte lokale Installation nicht ungültig und beweist nicht, dass alle Betreiber die Schnittstelle aufgegeben haben. RFC 3352 empfiehlt eine Statusänderung und erklärt in den Sicherheitsbetrachtungen, die Stilllegung werde die Sicherheit des Internets nicht beeinträchtigen. Das ist die Einschätzung des Autors, kein Beweis für die Sicherheit von CLDAP oder für Risikofreiheit jeder lokalen Nutzung.

Der Fall handelt deshalb vom Lebenszyklus eines Protokolls, nicht bloß von einem alten Standard. CLDAP senkte einen sichtbaren Aufwand – den Verbindungsaufbau –, ließ aber Schutz, Paketverlust, Aktualität, Ergebnisgröße und Weiterentwicklung offen. Der zeitgenössische Bericht sah weder einen tragfähigen Überarbeitungspfad noch eine ausreichende Basis unabhängiger Implementierungen. Historic machte diese Grenze lesbar, ohne Empfehlung, Einführung und universelle Abschaltung gleichzusetzen.

Heng Lus Gedanken zur minimalen Anfangsspezifikation und zum Vorrang laufenden Codes werden hier ausdrücklich als redaktionelle Perspektive verwendet, nicht als IETF-Befund. Sie helfen, drei Fragen zu trennen: Was spezifizierte RFC 1798? Was hielt RFC 3352 für die Lehre aus Betriebserfahrung? Was könnte ein einzelner Betreiber danach weiter ausgeführt haben? Die Quellen nennen weder Installationszahlen noch konkrete Produktabläufe oder Migrationsdaten.

Quellen

Primärdokumente: RFC 3352, RFC Editor und Datatracker; ursprüngliches Protokoll und Kontext: RFC 1798, RFC Editor, RFC 1777, RFC 3377, RFC 3494, RFC 4510, RFC 4511, RFC 4513 und RFC 2026. Offen gelegte redaktionelle Perspektiven: Heng Lu, Note 64 und Note 65.