Zusammenfassung

  • RFC 1107 plante ein dreistufiges White-Pages-Verzeichnis für Internet und National Research Network. Das Memo hielt zugleich fest, dass daraus keine zugesagte Forschungsaktivität der Internetgemeinschaft folgte.
  • Erst sollten mehrere Ansätze in begrenzten Feldversuchen verglichen werden; anschließend sollte die Auswertung eine Implementierung und deren Einführung vorbereiten. Verlässliche Personendaten, Namensverwaltung, Zugriffsrechte und Clients blieben Teil der ungelösten Arbeit.

Ein Telefonverzeichnis ist nur so brauchbar wie seine Aktualität. Jemand muss Einträge erfassen, Fehler korrigieren und entscheiden, wer sie lesen oder ändern darf. RFC 1107 verstand unter „White Pages“ einen Dienst, mit dem Menschen im Forschungsnetz andere Personen und Angaben zu deren Erreichbarkeit finden konnten – etwa Mailboxen, Kalender oder Dateiserver. „Yellow Pages“ bezeichnete daneben die Suche nach Netzressourcen anhand ihrer Merkmale. Das war mehr als eine Erweiterung der Hostnamen-Suche.

Karen Sollins veröffentlichte im Juli 1989 den Bericht „A Plan for Internet Directory Services“. Er fasst eine zweitägige Zusammenkunft im Februar zusammen, an der eine kleine Gruppe akademische, wirtschaftliche und staatliche Perspektiven vertrat. Die Teilnehmenden hielten einen Dienst innerhalb von drei Jahren für möglich, sofern starke Förderung und Ermutigung hinzukämen. Der Statusabschnitt setzt jedoch eine klare Grenze: Das Memo wurde zur Diskussion vorgelegt und repräsentierte keine zugesagte Forschungsarbeit der Internetgemeinschaft. Die Jahreszahl war ein bedingtes Ziel, keine genehmigte Finanzierung oder dokumentierte Inbetriebnahme.

Die Architektur sollte zunächst offenbleiben. X.500 galt wegen seiner ausdrucksstarken Semantik und der erwarteten internationalen Standardrolle als wahrscheinlichste Grundlage. Das Dokument verwies aber auf Lücken und auf die Starrheit einer strikten Hierarchie. Die erste Stufe sollte deshalb mehrere Verfahren erproben: mindestens eine X.500-Implementierung, zunächst Quipu als damals ausreichend reif eingeschätzte Option, außerdem Profile und DECnet Naming Architecture Naming Service (DNANS).

Profile erlaubte beschreibende Namen ohne starre Baumstruktur; DNANS hatte Lösungen für Zugriffskontrolle, Replikation und Zwischenspeicherung entworfen. Eine zweite X.500-Implementierung sollte helfen, Spezifikationsprobleme von Eigenheiten eines einzelnen Programms zu trennen.

Ein fairer Vergleich brauchte eine gemeinsame Datengrundlage. RFC 1107 empfahl ein einheitliches Format für die gesammelten Angaben sowie gemeinsame Werkzeuge zu ihrer Verwaltung, damit die Dienste nebeneinander mit vergleichbaren Einträgen getestet werden konnten. Die Feldversuche sollten Fragen sichtbar machen, die X.500 offenließ: Erfassung und Pflege, Verteilung und Replikation, Lese- und Schreibrechte, Datenintegrität, Lastverhalten, Benutzeroberflächen und die Unterstützung mehrerer Protokollfamilien. Vorgesehen war zunächst ein begrenztes, fachkundiges Umfeld; für DNANS wurde eine Gemeinschaft genannt, die ohnehin auf DECnet umstieg.

Das schuf einen Lernraum, belegte aber keine allgemeine Zustimmung zu den späteren Regeln.

Die Größenannahmen zeigen, warum ein erfolgreicher Prototyp nicht genügte. Das Memo rechnete mit rund zehn Millionen Nutzern in Wissenschaft und Forschung, zehn Abfragen pro Woche und Person und damit 10^8 Suchanfragen pro Woche – im Mittel etwa 170 pro Sekunde, mit deutlich höheren Spitzen. Mindestens 10^7 Einträge sollte das System bewältigen. Dies waren Planungswerte, keine Messdaten eines laufenden Dienstes. RFC 1107 hielt deshalb eine verteilte Lösung mit mehreren Servern für nötig. Zugleich warnte es, dass breite Suchanfragen mit der Größe des Gesamtsystems teurer werden könnten.

Cache, Datenverteilung und Aktualisierungsrhythmus würden die Leistung prägen. Eine formal erfolgreiche Abfrage nützte wenig, wenn Kontaktdaten veraltet waren.

Der Zeitplan ordnete das erste Jahr den Versuchen, das zweite der Implementierung und das dritte einer breiten Einführung zu. Alle Phasen sollten möglichst früh beginnen und sich überschneiden. Die Auswertung könnte für einen Dienst oder für eine Kombination seiner Funktionen sprechen. Danach wären zuverlässige Server sowie unterschiedliche Schnittstellen für Menschen und Programme zu entwickeln. Zur dritten Phase enthielt das Treffen noch keine ausgearbeitete Einführungsskizze.

Es blieben Datenerhebung und -pflege, Serverstandorte, Verteilung und Schulung der Clients, laufende Verwaltung und die Delegation von Zuständigkeit über Teile des Namensraums und deren Inhalte.

Damit wurde die Verwaltung selbst zu einer Architekturfrage. Wer durfte einen Organisationszweig anlegen? Wer hielt die maßgeblichen Daten, durfte Personaleinträge einsehen und konnte Fehler berichtigen? RFC 1107 erkennt an, dass Organisationen die Kontrolle über ihre Namensräume möglicherweise nicht abgeben wollten. Einzelne und Arbeitgeber konnten außerdem den Zugriff auf Personaldaten begrenzen. Ein übergreifendes Verzeichnis brauchte zugleich genügend Offenheit, um Menschen jenseits der eigenen Institution auffindbar zu machen.

Gemeinsame Regeln unterstützten Interoperabilität; lokaler Einfluss auf Daten und Zugriffe war eine Voraussetzung für Vertrauen.

RFC 1107 dokumentiert einen ernsthaften Vorschlag und seine offenen Beweisfragen, nicht den Abschluss eines dreijährigen Programms. Der Wert des Plans liegt darin, die Architekturentscheidung zu staffeln und Datenerhebung, Zuständigkeit und Clients neben die Protokollfrage zu stellen. Plausibel wäre der Zeitplan nur mit klaren Verantwortlichen, Ressourcen und belastbaren Ergebnissen aus jeder Stufe gewesen. Das Memo liefert diese spätere Ausführungsgeschichte nicht.

Quellen