Zusammenfassung

  • Centroids waren komprimiertes Vorwissen für die Auswahl möglicher Server, keine Kopien oder Beweise der zugrunde liegenden Datensätze.
  • Ein WHOIS++-Client verfolgte SERVER-TO-ASK, entdeckte weitere Indexbeziehungen und führte selbst eine Besuchsliste, weil das Mesh Zyklen enthalten konnte.
  • Mehr Suchbreite konnte die Trefferchance erhöhen, aber auch Zeit, Ressourcen und Antwortgebühren; ein Nullergebnis galt nur für den tatsächlich durchlaufenen Graphen.

Ein Wort im Index war noch kein Fund

RFC 1913 beschrieb den Centroid als verdichtete Sicht auf einen WHOIS++-Datenbestand. Er führte Template- und Attributnamen sowie eine deduplizierte Liste der Wörter, die mindestens einmal in den betreffenden Attributen vorkamen. Ein Indexserver konnte dieses Vokabular prüfen und eine Anfrage an einen möglicherweise passenden Basisserver weiterleiten, ohne dessen vollständige Datenbank zu kopieren.

Gerade die Verdichtung setzte der Aussage eine Grenze. Ein Wort im Centroid identifizierte keinen Datensatz. Zwei passende Wörter mussten nicht im selben Eintrag stehen. Der Index belegte weder Frische noch Richtigkeit des ursprünglichen Feldes. Er begründete eine weitere Anfrage, nicht deren Ergebnis.

Damit entstanden voneinander getrennte Belege: die Version des Centroids, die vermutete Übereinstimmung, der daraus erzeugte Verweis, die Auswahl durch den Client, der Verbindungsversuch und schließlich ein zurückgegebener Datensatz. Wer diese Schritte zu einem einzigen „Treffer“ zusammenzieht, macht Vorwissen zur behaupteten Wahrheit.

Der Client verwandelte Verweise in eine Suche

Die einzelne Transaktion war einfach. Der Client verband sich mit einem WHOIS++-Server, schickte seine Anfrage, empfing die Antwort und schloss die Verbindung. Die Antwort konnte Datensätze enthalten oder SERVER-TO-ASK-Blöcke mit weiteren Zielen.

Ein Verweis versprach weder Erreichbarkeit noch niedrige Kosten, Vertrauenswürdigkeit oder einen tatsächlichen Datensatz. Der Indexserver beherrschte seine Empfehlung; der Basisserver beherrschte seine Daten; der Client entschied, ob aus der Empfehlung eine neue Verbindung wurde. Ohne obligatorisches Zentrum verschwand Koordination nicht. Sie wurde im Ablauf des Clients sichtbar.

Reichte die erste Runde nicht aus, fragte der Client nach polled-by und polled-for. So entdeckte er weitere Indexserver und wiederholte dort die ursprüngliche Anfrage. Er erkundete den Suchraum, während er suchte.

Mehrere Hierarchien machten aus dem Bild einen Graphen

Ein Server konnte in mehr als einer Indexhierarchie erscheinen. Lokale Abkürzungen konnten sonst entfernte Teile verbinden. Das Mesh war deshalb nicht zwingend ein Baum; ein späterer Verweis konnte zu einem bereits besuchten Server zurückführen.

RFC 1914 übertrug Erkennung und Beseitigung solcher Schleifen vollständig dem Client. Der Beispielalgorithmus trennte OriginalServers, ServerList, QueriedServers und AnswerList. Vor jeder Anfrage prüfte er, ob das Ziel bereits besucht worden war. Die stabilisierende Erinnerung lag nicht im Mesh, sondern beim Akteur, der einzelne kurzlebige Verbindungen zu einer Reise zusammensetzte.

Diese Erinnerung bestimmt die Beweiskraft eines Ergebnisses. Aus der letzten Trefferliste lässt sich nicht erkennen, ob ein Zweig als Duplikat übersprungen, gesperrt, nicht erreichbar oder nie entdeckt wurde. Zwei Clients können dieselbe Anfrage stellen und verschiedene Listen liefern, weil ihre Startpunkte, Verweispfade, Cachezustände oder Abbruchregeln verschieden waren.

Vollständigkeit konnte exponentiell teuer werden

RFC 1914 warnte ausdrücklich davor, das Mesh blind und automatisch zu erweitern. Der Ressourcenverbrauch könne exponentiell wachsen. In Teilen der beschriebenen Umgebung wurden Antworten berechnet, sodass eine zusätzliche Verzweigung nicht nur Zeit und Datenverkehr, sondern auch Geld kosten konnte.

Der Text empfahl keine schrankenlose Automatik. Ein anspruchsvoller Client sollte einzelne Server abschneiden oder auf eine Sperrliste setzen können, etwa weil sie zu teuer waren. Nutzer mussten eine lange Transaktion abbrechen dürfen. Der Abbruchknopf markierte damit die Grenze dessen, was später als durchsucht gelten konnte.

Schnelligkeit und Reichweite waren keine neutralen Messwerte. Ein Client konnte schnell erscheinen, indem er langsame Zweige still verwarf. Ein anderer konnte umfassender suchen und gerade deshalb langsam oder fehlerhaft wirken. Ohne Anfragenzahl, Tiefe, Wartezeit, übertragene Bytes, Gebühren, Wiederholungen und Abbruchgrund blieb die Qualitätsbehauptung unprüfbar.

Der Standort des Servers begrenzte die Daten nicht

Als Einstieg sollte ein möglichst lokaler, vorkonfigurierter Server dienen. Das konnte Latenz oder Kosten senken, setzte der Anfrage aber keine geografische Grenze. Ein in den Vereinigten Staaten betriebener Server konnte durch Polling schwedische Einträge kennen.

Wer ausschließlich US-amerikanische Datensätze wollte, musste die Länderbedingung in die Anfrage schreiben. Standort des Einstiegs und Bedeutung der Anfrage waren getrennte Größen. Eine operative Topologie durfte nicht als administrativer oder geografischer Datenumfang missverstanden werden.

Auch deshalb war ein leeres erstes Ergebnis nur ein lokaler Befund. Es sagte nichts darüber, welche anderswo indizierten Daten bei weiterer Expansion erreichbar gewesen wären.

Auch das Serververzeichnis brauchte eine bekannte Adresse

Das Directory of Servers war ein besonderer WHOIS++-Dienst. Seine Navigationsdatensätze verbanden einen relativ stabilen Server-Handle mit dem jeweils bekannten Hostnamen und Port sowie beschreibenden Merkmalen. Daraus konnte der Nutzer einen geeigneteren Einstieg wählen.

Der Hostname und Port dieses Verzeichnisses mussten jedoch selbst vorkonfiguriert sein. Es löste den Bootstrap nicht vollständig und wurde nicht zu einer universellen Datenwurzel. RFC 1914 empfahl, die Optionen dem Nutzer zu zeigen, statt den Startserver automatisch zu bestimmen.

Der Handle half außerdem bei veralteten Verweisen. Ein in SERVER-TO-ASK genannter Host oder eine IP-Adresse konnte seit einem Wochen zurückliegenden Poll unverändert im Cache stehen. Scheiterte die Verbindung, sollte der Client den Handle im Serververzeichnis auflösen und den letzten bekannten Host erhalten. Doch „zuletzt bekannt“ war kein Nachweis aktueller Erreichbarkeit oder unveränderter Daten. Alter Verweis, Fehlschlag, Handle-Auflösung und neuer Versuch blieben separate Ereignisse.

Eine Sperrliste war keine Authentifizierung

RFC 1914 hielt das Einschleusen eines falschen WHOIS++-Servers für möglich und sah eine clientseitige Sperrliste vor. Sie verlieh dem Betreiber lokale Verweigerungsmacht. Sie bestätigte nicht pauschal alle Server, die nicht auf der Liste standen. Unbekannt war nicht gleich vertrauenswürdig.

Die Sicherheitsbehauptungen blieben geschichtet. Ein Index gab einen Verweis aus. Das Serververzeichnis nannte einen registrierten Kontaktpunkt. DNS löste den Namen zu einem Zeitpunkt auf. Das Netz stellte Erreichbarkeit her. Der entfernte Server lieferte eine Antwort nach eigener Politik. Der Client kombinierte diese begrenzten Aussagen mit seinen Regeln; keine einzelne Schicht bestätigte das Ganze.

RFC 1835 trennte ähnlich die verteilte Pflege der Basisdaten vom Indexdienst, der Server auffindbar machte. Das Anfrage- und Authentifizierungsmodell war kein universelles Wahrheitsregister für alle Identitäten und Angaben.

CIP verteidigte die Last als Kontrollrecht

RFC 2651 verallgemeinerte 1999 das Indexprinzip zum Common Indexing Protocol. Das Dokument räumte ein, dass der Client die schwierige Arbeit erhielt, betrachtete dies aber auch als Kontrolle über Tiefe und Geschwindigkeit der Suche sowie über die Größe der Ergebnismenge. Eine einzelne Wurzel wurde aus Skalierungsgründen verworfen, die Zyklusbehandlung blieb erhalten, und der gewählte Einstieg blieb folgenreich.

Diese Fortsetzung belegt keine universelle Verbreitung von WHOIS++. Auch die TISDAG-Szenarien in RFC 2968 dokumentieren spätere Vorschläge und Versuche, nicht weltweite Vollständigkeit. RFC 1914 wurde im Februar 1996 veröffentlicht und wird heute als Historic geführt; die WNILS-Arbeitsgruppe ist abgeschlossen. Daraus folgen weder eine genaue Zahl von Installationen oder Anfragen noch tatsächliche Antwortpreise oder ein präzises Abschaltdatum.

Belegt ist die Architekturentscheidung: Dezentralisierung ließ die Koordinationsarbeit nicht verschwinden. Sie gab dem Client zugleich Freiheit über die Suche und Verantwortung für ihre Grenzen.

Eine negative Antwort brauchte ihr Laufprotokoll

Um „nicht gefunden“ zu verteidigen, müsste ein Betreiber die ursprüngliche Anfrage und ihre expliziten Einschränkungen, den Startserver, jeden SERVER-TO-ASK-Verweis, Pollingbeziehungen, Centroid-Versionen, Handles, angekündigte Endpunkte, Cachealter, DNS- und Verbindungsresultate, Besuchsmenge, Sperren, Zeit-, Mengen- und Kostenbudgets sowie den Abbruchentscheider festhalten.

Ohne dieses Protokoll kann Null vieles bedeuten: kein Datensatz am Einstieg; kein passendes Wort im Centroid; ein veralteter oder unerreichbarer Zielhost; ein zu teurer Zweig; eine unterdrückte Schleife; ein Abbruch durch den Nutzer; oder ein tatsächlich ausgeschöpfter erreichbarer Ausschnitt. Das Mesh hatte keine obligatorische Wurzel. Vollständigkeit brauchte dennoch einen verantwortlichen Client, der seinen Weg erklären konnte.

Quellen