Ein Verzeichnis, aber kein einzelner Server: die Choreografie des RFC 1309

Zusammenfassung

• RFC 1309 beschrieb X.500 als globales, verteiltes Verzeichnis: Standorte pflegten ihren lokalen Anteil, während DUA, DSA, Chaining und Referrals eine einheitliche Sicht erzeugten.
• Ein Eintrag enthielt Attribute über ein Objekt; Objektklasse, DN und Alias ordneten seine Struktur und seine Wege, bestätigten aber weder das reale Objekt noch eine eindeutige Identität.
• Treffer konnten vom lokalen Master oder einer Replik stammen und administrativ begrenzt sein. Sichtbarkeit bewies deshalb keine Vollständigkeit, Aktualität, eindeutige Route, Autorität oder reale Wirkung.

Der einfache Treffer war das Ende einer Inszenierung

Gute Infrastruktur lässt ihre Übergaben verschwinden. Der Benutzer stellt eine Frage, das System liefert Namen und Attribute, und die Zwischenstationen treten aus dem Blick. Im X.500-Bild des RFC 1309 war diese Unsichtbarkeit kein Zufall, sondern das zentrale Leistungsversprechen: Viele Stellen sollten ihre Informationen selbst verwalten, ohne den Benutzer mit der Verteilung zu belasten.

Der Text erschien im März 1992 als FYI 14 mit dem Status Informational und legte keinen Internetstandard fest. Er erklärte X.500 für Einsteiger, verglich damalige Verzeichnisdienste und skizzierte Implementierungen und mögliche Anwendungen. Er ist eine zeitgenössische Übersicht, keine Beobachtung heutigen Betriebs.

Eine Zentralmaschine hätte Verarbeitung, Speicher und Aktualisierung konzentriert. X.500 verteilte die Arbeit: Standorte verantworteten ihren lokalen Teil, Benutzer suchten im homogenen Namensraum nach Attributen. Lokale Pflege ersetzte den Engpass hinter einer gemeinsamen Ansicht.

Was im Eintrag stand, blieb vom Objekt getrennt

Die zentrale Informationseinheit war ein Eintrag mit Attributen über genau ein Objekt, etwa eine Person, Organisation oder ein Netz. Attribute trugen einzelne Werte nach definierten Syntaxen. RFC 1309 nutzte den Vergleich mit einem Datenbanksatz, stellte später aber ausdrücklich klar, dass X.500 weder eine allgemeine Datenbank noch ein DBMS war.

Der Eintrag ist eine Sammlung gespeicherter Aussagen über eine Person oder Organisation, nicht das Objekt selbst. Ein gelesener Wert belegt seinen Platz in einer gelieferten Ansicht. Aktualität, Vollständigkeit und Wirklichkeitstreue folgen daraus nicht.

Auch objectClass war keine Wahrheitsmaschine. Die Klasse bestimmte Pflicht- und optionale Attribute und konnte Eigenschaften durch Vererbung weitergeben. Damit wussten verschiedene Implementierungen, welche Form eines Eintrags sie vor sich hatten. Schema-Konformität bedeutete interpretierbare Struktur. Sie authentifizierte weder das Objekt noch jede Behauptung im Eintrag.

Ein DN bezeichnete die Lage, nicht das Wesen

Die Directory Information Base, DIB, wurde in einem Directory Information Tree, DIT, geordnet. Jeder Eintrag hatte eine Position in diesem Baum. Sein Distinguished Name, DN, entstand aus der Folge der Relative Distinguished Names, RDNs, vom Wurzelpunkt bis zum Eintrag.

Ein DN war damit präzise als Verzeichnispfad. Er sagte, unter welchen Namenskontexten der Eintrag lag. RFC 1309 machte daraus aber kein biometrisches Merkmal, kein Rechtssubjekt und keinen Eigentumsnachweis. Der Pfad kann organisatorisch sinnvoll sein, ohne die ganze Identität seines beschriebenen Objekts aufzunehmen.

Aliases machten die Wegfrage sichtbar. Ein Alias-Eintrag an einem DN durfte auf einen Eintrag an einem anderen DN zeigen. Zwei Wege konnten also zu demselben Ziel führen. Das vervielfachte die Erreichbarkeit, nicht das reale Objekt. Ebenso wenig erklärte der erfolgreiche Alias-Weg den einen Pfad zum einzig maßgeblichen. Für eine belastbare Spur müssen Alias, Ziel und Auflösungsweg getrennt erhalten bleiben.

DUA und DSA teilten die Anfrage unter sich auf

Der Directory User Agent, DUA, handelte für den Benutzer. Er brachte eine Operation zu einem Directory System Agent, DSA. Dieser bot einen Zugangspunkt an und hielt nur einen Ausschnitt der DIB. Erst die weltweite Sammlung der DSAs bildete die verteilte Basis.

Wenn der erste DSA die benötigte Information nicht lokal hatte, konnte Chaining die Operation von Agent zu Agent weiterreichen. Bei einem Referral bekam der Anfragende einen Verweis auf eine andere Zuständigkeit. Beide Techniken sollten die Verteilung so transparent machen, dass das globale Verzeichnis am Schreibtisch wie ein Ganzes erschien.

Transparenz ist eine Eigenschaft der Benutzung, nicht des Beweises. Ein Treffer verrät weder ersten DSA und Zwischenstationen noch Referral oder Alias-Auflösung. Ein anderer zulässiger Weg könnte dasselbe Ziel erreichen. Die komponierte Einheit beseitigte die Herkunft ihrer Teile nicht.

Nähe konnte eine Kopie bedeuten

Eine Organisation konnte ihren eigenen DSA betreiben und die eigenen Informationen lokal meistern. Für häufig benötigte fremde Daten bot QUIPU Replikation: Der lokale DSA hielt sie als Slave-Kopie und erhielt automatische Aktualisierungen von den Masterdaten auf einem fremden DSA.

Diese Konstruktion tauschte Entfernung gegen eine zusätzliche Zeitdimension. Eine lokale Antwort konnte schnell sein, weil sie nicht beim entfernten Master gesucht werden musste. Doch der Zeitpunkt, zu dem die Kopie zuletzt aktualisiert worden war, blieb eine eigene Tatsache. Die Existenz automatischer Replikation beweist nicht, dass ein konkreter Treffer bereits den neuesten Masterstand enthielt.

Verwahrung und Wahrheit bleiben verschieden. Der Master bezeichnet den Pfleger des Verzeichnissatzes, nicht die letzte Autorität über das reale Objekt. Die Slave-Kopie bezeichnet technische Herkunft; Geschwindigkeit wird dadurch nicht Gewissheit.

Zugangskontrolle entschied über Operationen

Die 1988er Spezifikation kannte einfache Passwort-Authentifizierung und starke kryptografische Authentifizierung, wenn ein Benutzer oder Prozess über einen DUA eine Operation versuchte. QUIPU ergänzte ACL-Rechte auf Attributebene, darunter detect, compare, read und modify.

Das sind präzise Grenzen: Eine Authentifizierung bewertet die vorgelegte Identität im Zusammenhang mit dem Operationsversuch. Eine ACL erlaubt oder verweigert eine bestimmte Handlung an einem bestimmten Verzeichniswert. Keine dieser Entscheidungen bescheinigt, dass der Wert sachlich stimmt. Das Recht, einen Eintrag zu ändern, ist auch kein Beleg dafür, dass der Akteur das dargestellte reale Objekt besitzt oder rechtmäßig in jeder anderen Sphäre vertritt.

Auch eine wegen Zugriffsregeln leere Suche beweist keine Nichtexistenz. Erlaubnis, Sichtbarkeit und Wirklichkeit bleiben getrennt.

Eine begrenzte Liste sah trotzdem fertig aus

Verteilte Suchen konnten laut RFC 1309 wegen Netzverzögerung, zwischengespeicherter Teilergebnisse und Implementierungsleistung langsam werden. Betreiber konnten außerdem die Zahl gelieferter Treffer administrativ begrenzen, um das massenhafte Abschöpfen des Verzeichnisses zu erschweren. Das Beispiel des Textes ist drastisch: Eine Suche mit tausend Treffern konnte nur zwanzig anzeigen und den Benutzer zu engeren Anfragen zwingen.

Die zwanzig Einträge sind dann ein geliefertes Resultat, aber keine Volkszählung. Eine ordentlich gerenderte Liste trägt ihre ausgelassenen 980 nicht im Gesicht. Ohne Größenlimit, Teilresultat-Anzeige, Suchbasis und Filter kann ein Konsument aus der Oberfläche eine Vollständigkeit herauslesen, die der Mechanismus ausdrücklich nicht versprach.

Die Übersicht ließ ihre offenen Flanken stehen

RFC 1309 berichtete, dass es 1992 keinen klaren Konsens über die ideale Form des DIT oder des Objektbaums gab. Neue Attribute und Typen mussten manuell verteilt werden. Ein standardisiertes Ausgabeformat und ein Berichtsgenerator fehlten. Gemeinsam mit der ausdrücklichen Nicht-DBMS-Grenze zeigt das: Die globale Ansicht war ein Verzeichnisdienst mit bestimmten Such- und Namensfunktionen, keine allwissende, beliebig auswertbare Weltendatenbank.

Genannt wurden nationale Piloten, WHOIS- und Ressourcenlokalisierungsarbeit, das Campusverzeichnis und die Mailumleitung der University of Michigan sowie X.400-Adressverwaltung bei Sprint. Das belegt damalige Nennungen, keinen heutigen Betrieb oder konkreten Erfolg.

Damit bleibt auch die redaktionelle Grenze scharf. Hier geht es nicht um die gemeinsame und private Schemaentwicklung des RFC 1274, nicht um den Implementierungskatalog und seine fehlende Interoperabilitätsaussage in RFC 1292 und nicht um die Rechte eines öffentlichen Verzeichnisses in RFC 1295. RFC 1309 gehört hier die Bühne für eine andere Frage: Wie konnte ein Verzeichnis als eines erscheinen, obwohl kein einzelner Server es besaß?

Quelle und Beweisgrenzen

Einzige Quelle ist RFC 1309, veröffentlicht im März 1992 als FYI 14 und Informational RFC. Er belegt seine Architekturübersicht, Begriffe, Grenzen und historischen Einsatzbeispiele. Er belegt keinen heutigen Dienst, keinen beobachteten Anfrageweg, keine Aktualität einer bestimmten Replik, keine vollständige Trefferliste und keine reale Identität, Autorität, Eigentümerschaft oder Wirkung.