Zusammenfassung

  • RFC 1 teilte die Verantwortung auf: BBN hatte die Software der Interface Message Processors (IMPs) spezifiziert; die Host-Gruppen mussten sich auf Software einigen, mit der ihre Rechner das Netz nutzen konnten.
  • Steve Crocker bezeichnete den Inhalt als vorläufig und bat um Reaktionen. RFC 3 erklärte später, dass Leser einen veröffentlichten Text allein wegen seiner Schriftform für maßgeblich halten könnten – obwohl die Reihe gerade die Diskussion noch nicht verbindlicher Ideen erleichtern sollte.
  • Änderungen in RFC 6, die in RFC 11 beschriebene GORDO-Implementierung an der UCLA und die späteren Anpassungen in RFC 33 zeigen einen laufenden Prozess. Sie beweisen nicht, dass jeder Host RFC 1 unverändert übernommen hatte.

Über dem Paketnetz fehlte noch eine Verständigung zwischen den Hosts

Das frühe ARPA Network hatte eine klare technische Trennlinie. Bolt, Beranek and Newman spezifizierte die IMP-Software; diese Rechner transportierten Nachrichten zwischen den Standorten. Die angeschlossenen Computer brauchten zusätzlich gemeinsame Softwarekonventionen: zum Aufbau von Verbindungen, zur Kennzeichnung logischer Links und für den Umgang mit Daten eines entfernten Hosts.

Mit RFC 1 vom 7. April 1969 brachte Steve Crocker dieses Host-zu-Host-Problem in ein gemeinsames Dokument. Er fasste das Nachrichtenformat der IMPs zusammen und skizzierte Host-Software für Verbindungsanfragen, teletypeähnliche Sitzungen, größere Dateiübertragungen, Fehlerprüfung und interaktive Nutzung. Außerdem erwog er ein lokales Frontend, das unmittelbare Terminalreaktionen nahe beim Nutzer bearbeiten sollte, statt jede Eingabe über das Netz zu schicken.

Das war keine einzelne Entscheidung für alle Schichten. Die Weiterleitung durch IMPs und das Verhalten der Host-Betriebssysteme lagen bei unterschiedlichen Zuständigkeiten und hatten unterschiedliche Fehlerbilder. Eine Nachricht konnte den richtigen IMP erreichen, obwohl beide Systeme noch keine gemeinsame Vorstellung davon hatten, wie eine Sitzung zu beginnen oder eine Nachricht zu deuten war.

Crockers Einleitung macht den Status des Vorschlags ungewöhnlich deutlich: Die Gruppe hatte einige vorläufige Vereinbarungen getroffen, war auf offene Fragen gestoßen, und kaum etwas im Text war endgültig. Der Wert des Dokuments liegt auch darin, diesen unfertigen Zustand festzuhalten. Wer es als abgeschlossene Spezifikation liest, löscht die Arbeitsphase aus, die es dokumentiert.

Was die erste Notiz tatsächlich vorschlug

RFC 1 ordnete die Kommunikation über logische Verbindungen zwischen Host-Paaren. Ein Link sollte für die Steuerung zwischen Betriebssystemen reserviert, die übrigen sollten für Nutzersitzungen verwendet werden. Eine Verbindung konnte sich wie eine Wählleitung mit Fernschreiber verhalten; eine parallele Datei-Verbindung sollte größere Übertragungen ermöglichen, ohne auf Terminalpuffer und Unterbrechungszeichen angewiesen zu sein.

Der Text suchte auch nach einer Lösung für die Verzögerung interaktiver Fernarbeit. Vorgeschlagen wurde ein kleines lokales Frontend, beschrieben in einer damals DEL genannten Sprache, das alltägliche Terminalreaktionen am Nutzerstandort ausführen könnte. Die Spezifikation war noch in Arbeit. RFC 1 behauptete nicht, dass diese Funktion bereits auf allen Hosts lief.

Auch die ersten Experimente waren klar begrenzt. Crocker beschrieb Arbeiten am SRI an einem Abrufsystem und einem DEL-Frontend sowie geplante Nutzung mit UCLA und Utah. Das zeigt, was die Beteiligten entwickeln wollten. Es ist weder ein Installationsverzeichnis für jeden Standort noch ein Nachweis, dass alle vier frühen Hosts jeden Vorschlag umgesetzt hatten.

Die erste RFC war also kein Befehl einer Normungsinstanz. Sie bot eine gemeinsame Fläche, um Entwurfsentscheidungen sichtbar zu machen, Korrekturen einzuladen und einer standortübergreifenden Gruppe einen konkreten Diskussionsgegenstand zu geben.

Die Reihe machte Meinungsverschiedenheiten dokumentierbar

Zwei Tage nach RFC 1 verfasste Bill Duvall RFC 2, ebenfalls mit dem Titel „Host Software“. RFC 3 legte anschließend einige Dokumentationsregeln fest: Jede Person an jedem Standort durfte eine Notiz schreiben; Aktualität war wichtiger als Feinschliff; ein Titel musste nicht einmalig sein. Bill Duvall am SRI vergab die laufenden Nummern.

RFC 3 benannte auch ein bis heute bekanntes Problem technischer Governance: Leser halten Geschriebenes oft allein deshalb für maßgeblich, weil es schriftlich vorliegt. Das lockere Format sollte den Austausch von Ideen fördern, die ausdrücklich noch nicht verbindlich waren. Die Nummer machte eine Notiz auffindbar; sie entschied nicht die Frage, die sie aufwarf.

Das war kein verkleinertes, bereits fertiges Normungsverfahren. Die frühen RFCs verbanden Vorschläge, Fragen, Implementierungsdetails und Bitten um Rückmeldung. Ihr gemeinsamer Nutzen bestand darin, technisches Denken zwischen Standorten sichtbar zu machen, die zusammenarbeiten mussten und zugleich verschiedene Rechner und Betriebssysteme behielten.

Änderungen und Implementierungen liefern unterschiedliche Belege

RFC 6, Crockers Bericht über ein Gespräch mit Bob Kahn vom 10. April, verzeichnet eine Änderung des Host–IMP-Linkfelds: Es wurde auf fünf Bit reduziert und um ein Bit zur Kennzeichnung einer Konvertierung ergänzt. Das Detail ist klein, der Zeitpunkt aber aufschlussreich. Nur Tage nach RFC 1 wurde eines ihrer Elemente noch diskutiert und angepasst.

Im August beschrieb Gerard Deloche in RFC 11 die Host-zu-Host-Verfahren und ihre Umsetzung in GORDO, dem Timesharing-System der UCLA für SDS Sigma 7. Die Notiz behandelte Verbindungstypen, Kontrollnachrichten, Prüfsummen, Puffer und Programme zwischen Nutzern und IMP-Schnittstelle. RFC 13 verwies im selben Monat auf RFC 11 und schlug eine Nachricht der Länge null als Ende einer Dateiübertragung über eine Hilfsverbindung vor.

Diese Aufzeichnungen zeigen, wie Ideen in einer benannten Implementierung konkreter wurden und anschließend ein gezielter Vorschlag für einen bestimmten Bedarf entstand. Sie belegen nicht, dass alle Hosts GORDOs Verfahren nutzten oder dass das Netz aufhörte, sich zu verändern. Eine Implementierung ist ein stärkerer Betriebsnachweis für einen einzelnen Standort als ein Vorschlag allein; die Zahl der übrigen Anwender liefert sie nicht.

RFC 33 macht den Unterschied ausdrücklich. Im Februar 1970 berichtete sie von zahlreichen Änderungen gegenüber dem älteren Protokoll in RFC 11 und führte sie auf ein Netzwerktreffen im Dezember zurück. Das beigefügte Papier enthalte noch nicht genug Informationen, um ein Network Control Program zu schreiben, hieß es dort; Rückmeldungen waren erwünscht. Verbindungen funktionierten bereits und das Netz wurde genutzt, doch das Host-Protokoll blieb in Überarbeitung und Dokumentation.

Warum RFC 1 wichtig ist, ohne das letzte Wort zu sein

Die historische Bedeutung von RFC 1 liegt nicht darin, dass jedes Feld und jeder Ablauf dauerhaft Bestand hatte. Sie liegt darin, ein gemeinsames Entwurfsproblem diskutierbar gemacht zu haben, bevor für alle Hosts eine stabile Implementierung vorlag. Das Dokument benannte Zuständigkeiten, bot Optionen an und ließ offene Fragen sichtbar.

Das ist etwas anderes als ein Protokoll auszurollen. Ein Text kann das gemeinsame Problem abstecken; eine Revision kann Differenzen verkleinern; Code kann zeigen, dass ein System funktioniert; wiederholte Interoperabilität kann belegen, dass unabhängige Systeme Nachrichten kompatibel verstehen. Diese Schritte hängen zusammen, aber keiner bestätigt automatisch den nächsten.

Die frühen Aufzeichnungen stützen deshalb eine genauere Geschichte der Koordination. BBN spezifizierte die IMP-Schicht. Die Host-Gruppen entwickelten die Software darüber. RFCs boten eine nummerierte, leicht weitergebbare Diskussionsfläche. Implementierungen und spätere Notizen hielten fest, was ausprobiert und geändert wurde. Die erste Nummer eröffnete diesen Prozess; sie schloss ihn nicht ab.

Quellen

Die ursprüngliche RFC 1 ist die Primärquelle für Crockers vorläufigen Softwarevorschlag. RFC 2 enthält Bill Duvalls Notiz „Host Software“, RFC 3 erläutert die ersten Dokumentationsregeln. Crockers RFC 6 hält eine spätere Diskussion zur Host–IMP-Schnittstelle fest. Deloche beschreibt Verfahren und GORDO-Implementierung in RFC 11; Cerf schlägt in RFC 13 ein Endezeichen für Hilfsübertragungen vor. RFC 33 von Crocker und Kollegen dokumentiert spätere Änderungen und offene Fragen. Der RFC-170-Index von 1971 listet die ersten Notizen mit Datum.