Zusammenfassung

  • RFC 2345 trennte die Suche nach Firmeninformationen von DNS-Verwaltung und Namensrechten und behandelte ausschließlich die Frage, wo ein Nutzer weitersuchen sollte.
  • Welche Schreibweisen, Abkürzungen und Varianten zusammengehörten, entschied der Server; ob diese Entscheidung richtig war, lag ausdrücklich außerhalb der Spezifikation.
  • Die Antwort enthielt eine URL und einen frei gestaltbaren Anzeigenamen, aber keine Registernummer, Jurisdiktion, Quelle, Prüfzeit oder Kontrollevidenz.
  • Der Demonstrator sortierte nach einem Score, begrenzte die Ausgabe auf zehn Treffer und öffnete einen Einzeltreffer automatisch; sichtbare Eindeutigkeit war daher nur lokal.
  • Unternehmensidentität, Domain-Kontrolle, Seitenauthentizität und tatsächliche Dienstleistung blieben getrennte Beweisstufen.

Das Experiment löste nur das Auffindungsproblem

In der frühen kommerziellen Webnutzung lag eine einfache Annahme nahe: Wer den Namen der XYZ Company kannte, probierte www.xyz.com. Mit dem Wachstum des Netzes wurde die Annahme unhaltbar. Kurze Namen kamen in mehreren Branchen und Ländern vor, Marken unterschieden sich von Firmierungen, und viele Angebote lagen außerhalb von .com.

RFC 2345 zerlegte das damalige „Top-Level-Domain-Problem“ in drei Teile: Verwaltungspolitik, Rechte an Namen und das Auffinden von Informationen über eine bekannte Organisation. Der Vorschlag nahm sich nur des dritten Teils an.

Diese Begrenzung war keine Schwäche. Sie verhinderte, dass ein Verzeichnis nebenbei Markenrecht oder DNS-Delegation entscheiden sollte. Wer die Trefferzeile später als Identitätsurteil las, gab ihr genau jene Befugnisse zurück, die der Entwurf bewusst getrennt hatte.

WHOIS lieferte die einfache Transportform

Der Client verband sich mit TCP-Port 43, sendete eine Zeile, erhielt eine oder mehrere Zeilen und ließ die Verbindung vom Server schließen. RFC 954 hatte dieses knappe, menschenlesbare WHOIS-Muster bereits beschrieben.

Bei RFC 2345 enthielt die Anfrage einen vermuteten Firmennamen. Eine normale Antwort begann mit einer URL; Leerzeichen trennten sie von der anschließenden Firmenbezeichnung. Die Reihenfolge sparte Parserlogik, weil die angenommene URL-Syntax keine Leerzeichen zuließ.

Gleiche Syntax bedeutete aber keine gemeinsame Datenbasis. Anbieter konnten unterschiedliche Quellen, Abgleichsregeln und Rankings verwenden und dennoch vollständig protokollkonform sein. Das Format bewies, was ein Server ausgab, nicht weshalb seine Zuordnung zutraf.

Ein Name ist kein eindeutiger Unternehmensschlüssel

Die Bedeutung von „company name“ blieb dem Server überlassen. Er entschied über Schreibvarianten, Abkürzungen und akzeptierte Formen. Die Spezifikation erklärte ausdrücklich, dass die Richtigkeit einer daraus abgeleiteten Übereinstimmung nicht von ihr erfasst wurde.

Die Unsicherheit reicht weit über Groß- und Kleinschreibung hinaus. Unverbundene Unternehmen können denselben Handelsnamen führen. Muttergesellschaft, Tochter und Produkt können eine Marke teilen. Nach einer Fusion kann ein alter Name fortleben. Transliteration erzeugt mehrere Schreibungen. Das Entfernen einer Rechtsform verbessert die Trefferquote und kann zugleich zwei juristische Personen ununterscheidbar machen.

Ein Match zeigte deshalb zunächst nur die Entscheidung dieses Verzeichnisdienstes. Es war kein universeller Identitätsnachweis.

Auch die ausgegebene Firmenbezeichnung blieb offen

Der Text hinter der URL durfte ausschließlich einen Namen, einen Namen samt Ort oder Branche oder andere Angaben nach Wahl des Servers enthalten. Er sollte dem Menschen die Auswahl erleichtern.

Es gab keine Standardfelder für Register, Rechtsraum, Unternehmensnummer, Quelle, verantwortliche Redaktion, Prüfdatum, Konfidenz oder Korrekturhistorie. Ebenso fehlte eine Aussage dazu, ob die Verbindung zur Domain auf Inhaberschaft, Beauftragung, Vertrieb, Hosting oder redaktioneller Vermutung beruhte.

Die geringe Struktur war Teil des Versuchs. Sie reduzierte die Implementierungskosten, entfernte aber zugleich Informationen, mit denen ein Nutzer die Beweiskraft hätte beurteilen können.

Eine URL war eine Adresse, kein Eigentumstitel

RFC 1738 beschrieb die URL als kompakte Zeichenfolge zum Auffinden und Abrufen einer Internetressource. Sie warnte zugleich davor, dass eine URL später auf ein anderes Objekt zeigen könne.

Die in einer RFC-2345-Antwort enthaltene Domain konnte dem genannten Unternehmen, einer Muttergesellschaft, einer Agentur, einem Händler oder einem technischen Dienstleister gehören. Die Seite konnte offiziell delegiert, veraltet, umgeleitet oder kompromittiert sein. Die Antwortzeile unterschied diese Beziehungen nicht.

RFC 2345 selbst nannte die Täuschung des Übersetzungsservers als Gefahr: Ein falscher Server könnte für eine Firma eine falsche URL liefern. Zertifikate, Signaturen und andere Authentizitätssignale sollten dann zusätzliche Sicherheit schaffen. Das Mapping war somit gerade kein selbstgenügsamer Nachweis.

RFC 1591 trennte außerdem Domain-Registrierung von Markenrechten. Wenn selbst eine Registrierung keinen Markenstatus verlieh, konnte eine bloße Verzeichnisempfehlung erst recht keine Namensrechte begründen.

Der Einzeltreffer wirkte eindeutiger, als er war

Bei einer Antwortzeile durfte der Client nachfragen oder die URL öffnen, als hätte der Nutzer sie selbst eingegeben. Das Demonstrationsprogramm ging den reibungslosen Weg: Ein einziger Datenbanktreffer startete ohne weitere Bestätigung den Standardbrowser.

„Einzig“ galt jedoch nur innerhalb einer Datenbank, eines Regelwerks und eines Zeitpunkts. Eine junge Firma konnte fehlen. Eine abweichende Schreibweise konnte einen Kandidaten unsichtbar machen. Übermäßige Normalisierung konnte zwei Gesellschaften zusammenführen. Ein anderer Anbieter konnte mehrere Treffer liefern.

Automatisches Öffnen beschleunigte die Folgehandlung. Es erhöhte nicht die Gewissheit.

Die ersten zehn waren nicht alle

Der dokumentierte Demonstrationsserver enthielt ungefähr 209.000 von Dun & Bradstreet bereitgestellte Firmeneinträge. Bei zehn oder mehr Treffern gab er nur die ersten zehn zurück. Der Client zeigte zwei bis zehn Namen nach Score sortiert.

Der Score war nicht Bestandteil der Protokollnorm. Platz eins war eine Anbieterentscheidung, keine neutrale Eigenschaft der Beziehung zwischen Firma und Domain. Die Grenze nach zehn Einträgen machte erfolgreiche Antworten absichtlich unvollständig.

Auch Not found hatte nur lokale Bedeutung: Die Zeichenfolge passte zu keinem Eintrag dieser Datenbank. Daraus folgte weder die Nichtexistenz der Firma noch das Fehlen einer Website.

Der Demonstrator bot keine Ergänzungs- oder Korrekturfunktion, übernahm keine Verantwortung für die Datengenauigkeit und räumte fehlende Unternehmen ein. Besonders ein negatives Ergebnis brauchte daher externe Gegenprüfung.

Verzeichnisqualität entstand außerhalb des Protokolls

RFC 2345 benannte die entscheidende Grenze selbst: Die Ergebnisqualität hing vom zugrunde liegenden Verzeichnis und von der redaktionellen sowie recherchierenden Arbeit an seinem Aufbau ab. Beides regelte das Protokoll nicht.

Ein perfekt formatiertes Ergebnis konnte veraltet sein. Ein Cache konnte einen alten Fehler besonders schnell wiederholen. Umgekehrt konnte ein sorgfältig gepflegter Dienst dasselbe minimale Zeilenformat verwenden.

Zur Unterscheidung brauchte man Herkunft, Gültigkeitszeit, Abgleichsmethode, Konfliktbehandlung, Aktualisierungsrhythmus und Korrekturweg. Protokollkonformität beantwortete: „Was hat der Server gesagt?“ Informationsqualität verlangte: „Auf welche Belege stützte er sich?“

Die Serverwahl gehörte zur Provenienz

Die RFC verlangte weder einen einzigen Anbieter noch ein Anbieterregister. Clients sollten die Wahl des Servers ermöglichen.

Das erlaubte spezialisierte regionale und sprachliche Angebote. Es bedeutete zugleich, dass dieselbe Eingabe zu unterschiedlichen Kandidaten, Reihenfolgen und Negativmeldungen führen konnte. Eine gespeicherte Antwort ohne Serveridentität, Zeit, exakte Anfrage und Datenversion verlor einen zentralen Teil ihrer Herkunft.

Marktdruck konnte bessere Verzeichnisse belohnen. Er authentifizierte nicht rückwirkend jede einzelne Zeile.

Die offizielle Seite war noch kein Leistungsbeleg

Selbst eine zutreffende Zuordnung ließ den praktischen Erfolg offen. DNS-Auflösung, Netzwerkpfad, TLS-Kontext und Weiterleitungskette mussten funktionieren. Die Seite musste tatsächlich die gesuchte Leistung anbieten, und Formular, Bestellung oder Support mussten zu einem beobachtbaren Ergebnis führen.

Eine offizielle Website kann ein eingestelltes Produkt zeigen. Ein Formular kann laden und beim Absenden scheitern. Die vertragliche Gegenpartei kann eine andere Gesellschaft sein. Ein erfolgreicher Besuch beweist keine künftige Kontinuität.

Das Verzeichnis beantwortete, wo man nachsehen sollte. Identität, technische Kontrolle und Leistungsresultat blieben eigene Feststellungen.