Zusammenfassung

  • RFC 1959 fasste Serverort, Distinguished Name, Attribute, Suchbereich und Filter in einer tragbaren LDAP-URL zusammen; ausgelassene Felder aktivierten Vorgaben.
  • Ein Host durfte fehlen, Zugangsdaten konnten nicht angegeben werden. Dieselbe Zeichenfolge konnte unter verschiedenen Server-, Sitzungs- und Zugriffsbedingungen laufen.
  • Die URL beschrieb eine Suchabsicht, bewies aber weder die gewählte Ausführung noch ein vollständiges Ergebnis oder die Berechtigung zu einer Folgehandlung.

Eine Anfrage bekam ein Transportformat

LDAP war als leichter Zugang zum X.500-Verzeichnis entstanden. RFC 1959 wollte Internet-Clients unmittelbaren Protokollzugang geben und erklärte das Format zugleich für eigenständige LDAP-Server geeignet. Die Neuerung bestand nicht in einem neuen Verzeichnisurteil, sondern in einer kompakten Hülle für eine bestehende Operation.

Die Reihenfolge war fest: ldap://, optional Host und Port, dann ein Schrägstrich mit Distinguished Name und anschließend Attribute, Bereich und Filter, getrennt durch Fragezeichen. Der Host zeigte auf einen Server. Der Name bestimmte die Suchbasis. Attribute bezeichneten die gewünschten Felder. Der Bereich wählte Basisobjekt, eine Ebene oder Teilbaum. Der Filter selektierte Einträge.

Der Filter hatte bereits in RFC 1558 eine eigene Grammatik als lesbare Darstellung eines LDAP-Prädikats. RFC 1959 behandelte den Umschlag, der dieses Prädikat mit den übrigen Parametern beförderte. Ein Filter wählte keinen Server und verlieh keine Zugriffsrechte; die URL ersetzte nicht die Filtersyntax.

Leere Positionen waren wirksam

Ohne Port galt TCP 389. Ohne Attributliste sollten alle Attribute angefordert werden. Ohne Bereich galt base. Ohne Filter galt (objectClass=*). Diese Vorgaben vervollständigten den Auftrag eines Clients. Sie sagten nichts darüber, welche Daten existierten oder sichtbar waren.

Alle Attribute anzufordern bedeutete nicht, alle zu erhalten. Der Standardfilter bestätigte weder Identität noch Aktualität. Der Distinguished Name konnte fehlen, veraltet oder unzugänglich sein. Erst der Server verarbeitete die Suche unter seinen Regeln.

Im Teilbaumbeispiel der University of Michigan stehen zwei Fragezeichen hintereinander. Das leere Attributfeld hielt sub und den Filter an den richtigen Positionen. Für eine belastbare Spur reicht daher der sichtbare Text nicht: Auch die durch Auslassung ausgelösten Vorgaben gehören zum Ausführungsnachweis.

Distinguished Name und Filter behielten ihre Syntaxen; andere Zeichen wurden nach RFC 1738 prozentkodiert. Die verifizierte Errata 528 berichtigt den Verweis für die DN-Syntax von RFC 1485 auf RFC 1779. Transportkodierung machte weder den Namen kanonisch noch den Filter sicher oder eine Behauptung wahr.

Ohne Host blieb die Auswahl beim Client

ldap:/// benannte keinen Server. Lag ein Eintrag im X.500-Namensraum, durfte der Client laut RFC 1959 irgendeinen LDAP-Server mit X.500-Backend-Zugriff ansprechen. Das löste die Referenz von einer Maschine, dokumentierte aber weder Auswahlverfahren noch Replikat, Sicht oder Zeitpunkt. Irgendein erreichbarer Server war nicht dasselbe wie alle Server und kein globales Autoritätssiegel.

RFC 2255 formulierte die Trennung später deutlicher: Ohne Host brauchte der Client Vorwissen über einen geeigneten Server. Er konnte eine Verbindung öffnen oder wiederverwenden, Sicherheit und Authentifizierung wählen und nicht in der URL enthaltene SearchRequest-Felder wie Größen- und Zeitgrenzen oder Aliasbehandlung festlegen.

Diese spätere Präzisierung darf nicht rückwärts in den Text von 1996 hineingelesen werden. RFC 1959 enthielt keinen Auswahlalgorithmus, keinen Verbindungsverlauf und keine vollständige Laufzeitpolitik. Es trug nur die benannten Suchbestandteile.

Eine URL besaß keine Identität

RFC 1959 bot kein Feld für Anmeldedaten und erwartete deshalb nicht authentifizierte Auflösung. Anonyme Suche kann für öffentliche Verzeichnisdaten beabsichtigt sein. Sie ist dennoch kein Anspruch auf jede gewünschte Information.

Die Attributauswahl war ein Wunsch des Clients. Der Server behielt Zugriffskontrolle und administrative Beschränkungen. RFC 4511 erklärte später, dass ein zurückgegebener Eintrag nur einige angeforderte Attribute oder sogar keine Werte enthalten kann.

Auch zwei Benutzer derselben URL haben nicht automatisch dieselbe Identität. Eine anonyme Sitzung, eine authentifizierte Verbindung und eine geänderte ACL können eine öffentliche Sicht, eine erweiterte Sicht oder einen Fehler erzeugen. Die Abweichung ist Ausführungskontext, kein Widerspruch innerhalb der Zeichenfolge.

Die Antwort begann erst nach der URL

RFC 4511 beschreibt null oder mehr Einträge und Referenzen, gefolgt von SearchResultDone mit Erfolg oder Fehler. RFC 1959 nahm diese Nachrichten nicht in die URL auf und fror keinen Verzeichnisschnappschuss ein.

Eine gespeicherte URL belegt die beabsichtigte Frage. Sie beweist nicht, dass später dieselben Daten geprüft wurden, dass kein Limit die Suche verkürzte, dass Verweise verfolgt wurden oder dass eine abschließende Erfolgsmeldung eintraf. Ein einzelner Eintrag beweist ebenso wenig Vollständigkeit.

RFC 4516, die heutige LDAPv3-URL-Spezifikation, hält fest, dass nicht alle Parameter einer SearchRequest ausdrückbar sind. Die URL bleibt kleiner als die Operation; die Operation bleibt kleiner als die Entscheidung eines nachgelagerten Systems.

Mit Heng Lus Minimum Initial Specification gelesen, ist diese Begrenzung eine Stärke: Eine kleine gemeinsame Oberfläche erleichtert Koordination, ohne dauerhafte Entscheidungsgewalt zu beanspruchen. Running-Code Primacy verlangt getrennte Belege für Zeichenfolge, Interpretation, Verbindung, Nachrichten und Handlung. RFC 1959 ließ die Frage reisen. Es machte sie nicht souverän.

Quellen und Grenzen

Dokumentstatus und Herkunft stehen im IETF Datatracker und auf der Informationsseite des RFC Editor. Maßgeblich sind HTML, Klartext und Errata 528. Kontext liefern RFC 1777, RFC 1558 und RFC 1738; spätere Grenzen erläutern RFC 2255, RFC 4511 und RFC 4516.

Die redaktionelle Lesart stützt sich auf Heng Lus Running-Code Primacy, Minimum Initial Specification und Reality Layers. Diese Essays sind keine Belege für LDAP-Implementierungen. Die Quellen belegen Spezifikationen und erklärte Grenzen, nicht heutige Verbreitung, Produktkonformität, reale Verzeichnisinhalte, Vorfälle, ACLs oder Anwendungsentscheidungen.