Zusammenfassung

  • Eine LDAP-MessageID musste nur gegenüber gleichzeitig laufenden Anfragen derselben Sitzung eindeutig sein. Alle Einträge, Verweise und das Endergebnis einer Suche trugen dieselbe Zahl, wodurch sich Antwortfolgen überlagern durften.
  • Abandon besaß eine eigene Hüllen-ID und nannte im Inhalt eine zweite ID als Ziel, lieferte aber keine Ergebnisantwort. RFC 3909 ergänzte deshalb Cancel für Anwendungen, die Erfolg, Ablehnung oder ein zu spätes Eingreifen unterscheiden müssen.
  • Bei paginierten Suchen erhielt jede Seite eine neue message ID; ein opakes Cookie trug die Fortsetzung. Die Zahl war weder Identitätsnachweis noch dauerhafter Suchname oder Rollback-Beleg.

Eine Suche bestand aus einer Antwortfolge

„Lightweight“ senkte die Kosten des Zugangs zum X.500-Verzeichnismodell. Es versprach nicht, dass jede Operation in eine einzige Antwort passte. Eine Suche unterhalb eines Knotens konnte zahlreiche Einträge, Verweise auf weitere Namensräume und erst danach einen Schlussstatus liefern.

RFC 1487 führte im Juli 1993 die gemeinsame LDAPMessage-Hülle ein. Ihr einziges gemeinsames Feld war die ganzzahlige messageID. Sie musste sich von den IDs anderer noch offener Anfragen derselben LDAP-Sitzung unterscheiden. Der Server spiegelte den Wert in jeder zugehörigen Antworthülle.

Die Zahl zählte also keine Pakete. Sie bezeichnete den laufenden Vorgang, zu dem viele Nachrichten gehören konnten. Distinguished Names benannten Verzeichnisobjekte, der Typ der Protocol Operation erklärte die Nachricht. Die ID verband den empfangenen Baustein mit dem richtigen lokalen Zustand beim Client.

Globale Eindeutigkeit war weder gefordert noch hilfreich. Zwei Sitzungen konnten denselben Wert führen. Nach sicherem Abschluss durfte auch dieselbe Sitzung ihn wiederverwenden. Die prüfbare Eigenschaft lautete: Unter den gleichzeitig bearbeiteten Vorgängen im gemeinsamen Vergleichsraum gibt es keine Verwechslung.

Asynchronität machte die Zahl notwendig

RFC 1777 stellte 1995 klar, dass Client und Server nicht synchron arbeiten müssen. Anfragen und Antworten mehrerer Operationen konnten in beliebiger Reihenfolge ausgetauscht werden.

Zwischen zwei Einträgen der Suche 31 konnte das Ergebnis eines Compare 32 eintreffen. TCP ordnete die Bytes, aber nicht deren fachliche Zugehörigkeit. Die Message ID zerlegte einen Transportstrom in mehrere logische Abläufe.

RFC 2251 übernahm die Regel 1997 in LDAPv3, begrenzte den Wert auf 2^31−1 und untersagte die Wiederverwendung vor der letzten Antwort. Typische Clients erhöhten einen Zähler; entscheidend war jedoch nicht die Monotonie, sondern die Eindeutigkeit unter offenen Arbeiten.

Eine Suche konnte SearchResultEntry und SearchResultReference in wechselnder Reihenfolge liefern. Genau ein SearchResultDone beendete die Folge mit Erfolg oder Fehler. Ein bereits empfangener Eintrag bewies deshalb keinen vollständigen Suchlauf. Die Schlussantwort war sowohl Ergebnis als auch gewöhnliche Lebensdauergrenze der ID.

Null kennzeichnete die Nachricht ohne Client-Anfrage

2006 wurde LDAPv3 neu geordnet. RFC 4510 dokumentiert die Ablösung der älteren Spezifikation; RFC 4511 enthält die revidierten Protokollregeln.

Request-IDs mussten nun ausdrücklich ungleich null sein. Null blieb einer unaufgeforderten Serverbenachrichtigung vorbehalten, etwa der Notice of Disconnection. Sie war keine Antwort auf einen Client-Vorgang und durfte nicht wie die Antwort auf eine fiktive Operation null aussehen.

Die Reservierung verlieh der Nachricht keine Authentizität. Sie schuf eine lokal erkennbare Klasse außerhalb clientinitiierter Arbeit. Operationstyp und Benachrichtigungs-OID blieben nötig; Schutz und Identität kamen aus anderen Mechanismen.

Auch die Wiederverwendung hing am tatsächlichen Dienstzustand. Erst wenn der Client feststellen konnte, dass der Server die frühere Anfrage nicht mehr bearbeitete—gewöhnlich nach der finalen Antwort oder einem später abgeschlossenen Bind—durfte er die Zahl erneut einsetzen. Ein lokaler Timeout löschte keinen entfernten Zustand.

Abandon traf das Ziel, meldete aber kein Ergebnis

Die Abandon-Anfrage ist selbst eine LDAP-Operation und trägt deshalb eine neue MessageID in ihrer Hülle. Ihr Inhalt ist eine weitere MessageID: die zuvor gestartete Zieloperation. Identität des neuen Akts und Auswahl des Ziels bleiben getrennt sichtbar.

Eine Abandon-Antwort gibt es nicht. Nach RFC 4511 kann der Server die Zieloperation aufgeben. Bei einer laufenden Suche muss er weitere Eintragsantworten stoppen und darf kein SearchResultDone senden. Bereits unterwegs befindliche Ergebnisse können dennoch eintreffen; bestimmte Vorgänge lassen sich gar nicht aufgeben.

Das Schweigen spart Arbeit, wenn der Client das Resultat ohnehin nicht mehr benötigt. Es ist aber keine Quittung. Ein korrektes Ziel sagt nicht, ob der Server tatsächlich angehalten hat.

RFC 2251 verschob deshalb die Wiederverwendung sowohl der Abandon-ID als auch der Ziel-ID, bis eine Antwort auf eine später angestoßene Anfrage eingetroffen war. Diese spätere Antwort bestätigte Abandon nicht. Sie war lediglich ein vorsichtiger Fortschrittsbeleg auf derselben Verbindung.

Cancel führte eine überprüfbare Folge ein

RFC 3909 definierte 2004 die Extended Operation Cancel. Abandon wurde nicht nachträglich stärker dargestellt; Anwendungen mit Ergebnisbedarf erhielten einen eigenen Ablauf.

Cancel besitzt eine Hüllen-ID und nennt die Zieloperation mit cancelID. Bei Erfolg antwortet der Server auf Cancel mit success, und die Zieloperation endet mit canceled. Andere Codes unterscheiden eine unbekannte Operation, einen nicht abbrechbaren Vorgang und ein Eingreifen, das zu spät kam.

Als Beispiel für tooLate nennt der RFC eine bereits im zugrunde liegenden Datenspeicher festgeschriebene Änderung. Exakte Zuordnung erzeugt keine Rückspulfunktion. Die richtige Operation kann gefunden werden, obwohl ihre Wirkung nicht mehr rückgängig zu machen ist.

Bind, StartTLS, Unbind, Abandon und Cancel selbst sind nicht cancelbar. Sie errichten oder verändern den Sicherheits- und Sitzungsrahmen, in dem gewöhnliche IDs erst Bedeutung erhalten. Ein Korrelationsschlüssel darf diesen Rahmen nicht beliebig beherrschen.

Die nächste Seite war eine neue Operation

RFC 2696 macht die Begrenzung besonders anschaulich. In SearchResultDone liefert der Server ein opakes Cookie. Für die nächste Seite wiederholt der Client die Suchwerte, ändert aber die messageID, sendet das jüngste Cookie und darf die Seitengröße anpassen.

Jede Seite ist eine neue LDAP-Operation. Das Cookie hält den serverseitigen Fortsetzungszustand. Ein älteres Cookie kann unbrauchbar sein; ein leeres beendet die Folge. Abandon kann eine laufende Seite stoppen und dabei das Cookie entwerten. Ein geordnetes Ende der ganzen Folge verlangt eine neue Suche mit Größe null und dem letzten Cookie.

Message ID beantwortet somit: Welche laufende Operation dieser Sitzung erzeugte die Nachricht? Das Cookie beantwortet: Welche Ergebnisposition darf eine spätere Operation fortsetzen? Objektname, Berechtigung und Wahrheitsgehalt benötigen andere Nachweise.

Grenzen des Quellenbestands

Die geschlossene historische Grundlage besteht aus RFC 1487, RFC 1777, RFC 2251, RFC 2696, RFC 3909, RFC 4510 und RFC 4511. Sie belegen Format, normative Grenze und Revision. Sie messen keine heutige Verbreitung, zertifizieren kein Produkt und beweisen nicht den Ausgang einer konkreten Operation.

Die Zahl blieb nützlich, weil ihre Autorität klein blieb. Sie ordnete Nachrichten einem überprüfbaren Zustand zu. Abschluss, Abbruch, Fortsetzung, Authentisierung und Autorisierung verlangten jeweils eigene Evidenz.