Wir haben im aktuellen Issue 31 wieder die Mai-2026-RFC-Lese-Runde aufgesetzt — diesmal in einer extra ruhigen Variante, weil wir uns vorgenommen haben, die ersten zehn Memoranden noch einmal so zu lesen, wie man sie 1969 hätte lesen müssen, also als laufende Korrespondenz unter Doktoranden, nicht als Spezifikation. Die Runde trifft sich montagabends, der Druck steht bei iss/0031, und der Stapel auf dem Tisch ist eine schmale Reihe vergilbter Faksimiles aus dem RFC-Editor-Archiv. RFC 1 bis RFC 10, zusammen knapp 80 Seiten, dazwischen die Lücken — RFC 6 ist nie öffentlich publiziert worden, RFC 7 nur als Sitzungsnotiz erhalten — und am Ende der Lektüre die Frage, die in jeder Runde wiederkehrt: woher kam dieser bestimmte Ton, der ein halbes Jahrhundert tragen sollte.

Die Antwort steckt im Titel. Steve Crocker schreibt RFC 1 (Host Software) in der Nacht vom 6. auf den 7. April 1969 im Badezimmer des elterlichen Hauses in Los Angeles, damit das Klappern der mechanischen Schreibmaschine seine Eltern nicht weckt. Er ist 25, Doktorand an der UCLA, Mitglied der Network Working Group, und er hat ein Problem, das nicht technisch ist, sondern sozial — die Gruppe der Studenten an UCLA, SRI, UCSB und Utah soll die Host-zu-Host-Protokolle ausarbeiten, aber niemand traut sich, „Specifications” an die Professoren zu adressieren. Das ist die berühmte Stelle in Crockers späterer Erinnerung, und die Erfindung des Formats steht und fällt mit dieser kleinen Kühnheit — Crocker setzt „Request for Comments” über die Seite, also nicht „Standard”, nicht „Spezifikation”, nicht einmal „Vorschlag”, sondern eine Anfrage. Bitte kommentiert. Das nimmt die Gruppe aus der Hierarchie heraus und etabliert in einem Federstrich den Ton, in dem das Internet sich selbst seit 57 Jahren beschreibt.

Die ersten zehn — eine kurze Karte

RFC 1 (Host Software, Crocker, 7. April 1969) skizziert die Software-Anforderungen an den IMP-Anschluss. RFC 2 (Host Software, Bill Duvall, SRI, 9. April) ist die SRI-Antwort, drei Seiten, knapp. RFC 3 (Documentation Conventions, Crocker, 9. April) ist der Meta-Eintrag — wie schreibt man eigentlich ein RFC. Die Antwort ist erstaunlich liberal — jeder Teilnehmer der Network Working Group darf, ohne Genehmigung, jederzeit ein RFC verfassen; die Verteilung erfolgt per Postversand an alle bekannten Adressen. RFC 4 (Network Timetable, Elmer Shapiro, SRI) ist eine Planungsskizze für die ersten Verbindungstests. RFC 5 (Decode-Encode Language, Jeff Rulifson, SRI, 2. Juni) ist die erste Daten-Format-Spezifikation überhaupt — eine Maschinen-unabhängige Beschreibung von Bit-Strings. RFC 8 (ARPA Network Functional Specifications, Gerhard Deloche, UCLA) und RFC 9 (Host Software, Bill Duvall, SRI, 1. Mai) bringen die Bytes auf die Leitung. RFC 10 (Documentation Conventions, Crocker, 29. Juli) ist die Konsolidierung — der Stil ist gefunden, die Distribution geregelt, die Network Working Group hat ein Gedächtnis.

Was zwischen RFC 5 und RFC 8 fehlt, sind die nicht-publizierten Einträge. RFC 6 und RFC 7 erscheinen in keinem Archiv. Jon Postel — damals noch nicht RFC-Editor, sondern Mit-Doktorand an der UCLA — wird die Lücken später im IANA-Bestand als „not issued” markieren. Dass die Reihe an dieser Stelle so offen aussieht, ist Teil des Tons; es gibt keine retroaktive Versuchung, die Geschichte glatt zu schreiben.

RFC 1 als Implementations-Programm

Crockers RFC 1 ist auf Implementations-Ebene erstaunlich konkret, obwohl die ARPANET-Hardware zu diesem Zeitpunkt noch gar nicht steht. Crocker geht davon aus, dass jeder Host eine eigene NCP-Schicht (Network Control Program) bekommt, die zwischen Anwendungs-Code und IMP-Interface vermittelt. Die IMPs (Interface Message Processors) liefert BBN in Cambridge, gebaut auf der Honeywell DDP-516, einer 16-bit-Mini mit 12 kB RAM. Das Host-IMP-Interface arbeitet seriell mit einer Maximal-Bandbreite von 100 kbps, die ARPANET-Backbone-Leitungen zwischen den IMPs laufen auf 50 kbps AT&T-Standleitungen. Die maximale Paket-Größe ist 8159 Bits, also gut 1 kB. Crocker schreibt diese Zahlen in RFC 1 nicht direkt — sie kommen aus der parallel laufenden BBN-Hardware-Dokumentation — aber er rechnet bereits mit ihnen, wenn er die Verbindungs-Aufbau-Sequenz skizziert.

Bemerkenswert für die Mai-2026-Lese-Runde war, wie früh schon das Konzept der Connection im RFC 1 erscheint. Crocker beschreibt die Host-zu-Host-Kommunikation als eine bidirektionale Sequenz von Nachrichten zwischen zwei NCP-Instanzen, identifiziert über ein Socket-Paar (Local Socket, Remote Socket). Das ist exakt die Abstraktion, die zwölf Jahre später als TCP-Connection in RFC 793 kanonisiert wird, und es ist verblüffend, wie sauber Crocker den Begriff schon im April 1969 setzt, ohne dass das Wort „Transmission Control Protocol” existiert.

Bill Duvall, RFC 9 und die SRI-Seite

RFC 9 ist die SRI-Antwort auf RFC 1. Bill Duvall arbeitet am Stanford Research Institute, im NIC (Network Information Center) unter Douglas Engelbart, und er programmiert auf einem SDS 940 mit 64 kWords RAM — das System, das Engelbart 1968 in der „Mother of All Demos” vorgeführt hatte. Duvall denkt von Anfang an in höheren Schichten — RFC 9 enthält bereits eine Skizze für ein File-Transfer-Schema und einen Remote-Login-Mechanismus, also die direkten Vorläufer von FTP und Telnet, zwei Jahre vor deren ersten Spezifikationen (FTP entsteht 1971 in RFC 114 durch Abhay Bhushan am MIT, Telnet 1972 in RFC 318).

Was Duvall in RFC 9 anlegt, ist die SRI-spezifische Sicht: das Netz dient dazu, dass entfernte Maschinen wie lokale Terminals erscheinen. Die UCLA-Sicht in RFC 1 ist eher umgekehrt — das Netz dient dazu, dass Programme über Hosts hinweg miteinander reden können. Diese beiden Sichtweisen werden sich über die nächsten Jahre verschränken und am Ende beide ihren Niederschlag im TCP/IP-Stack finden. Aber 1969 sind sie noch unterscheidbar, und die Lese-Runde im Mai 2026 hat sich daran gefreut, wie deutlich man im Original noch die zwei Schulen herauslesen kann.

Implementations-Folgen für die ersten vier Knoten

Die ersten vier ARPANET-Knoten — UCLA als Knoten 1 (Boelter Hall, Leonard Kleinrock), SRI als Knoten 2 (Menlo Park, Duvall und Engelbart), UCSB als Knoten 3 (Glen Culler), University of Utah als Knoten 4 (Robert Taylor) — implementieren die NCP-Schicht nach RFC 1 und RFC 9 auf vier unterschiedlichen Host-Systemen. UCLA fährt einen SDS Sigma 7, SRI den SDS 940, UCSB einen IBM 360/75, Utah eine PDP-10. Die NCP-Implementation muss jedes Mal von Grund auf neu geschrieben werden, weil die Maschinen architektonisch nichts gemeinsam haben. Die Tatsache, dass diese vier ungleichen Systeme im Herbst 1969 trotzdem eine gemeinsame Schicht laufen lassen, ist die eigentliche Leistung der ersten zehn RFCs — sie haben die Sprache geliefert, in der die vier Teams sich verständigen konnten, ohne dass jemand zentral „Spezifikationen” diktiert hätte.

Was die Mai-2026-Runde mitnahm

Drei Befunde aus der Lektüre, in den Notizblock geschrieben unter dem Datum 18. Mai 2026: Erstens, der RFC-Ton ist von Beginn an performativ. Crocker schreibt nicht über Bescheidenheit, er ist bescheiden, und das Format zwingt alle nachfolgenden Autoren in dieselbe Haltung. Zweitens, die Lücken (RFC 6, RFC 7) sind Teil des Archivs und werden 57 Jahre später noch sichtbar gelassen — eine kleine Lehre für jede Dokumentations-Praxis. Drittens, die ersten zehn RFCs enthalten in nuce schon den ganzen Stack: Sockets (RFC 1), Datenformate (RFC 5), Funktions-Spezifikation (RFC 8), höhere Dienste (RFC 9). Die nächsten 9.500 RFCs füllen aus, was diese ersten zehn aufgespannt haben.

Im Issue 32 nehmen wir uns RFC 11 bis RFC 30 vor — die Phase, in der das NCP konkrete Bit-Schichten bekommt. Die Lese-Runde tagt wieder montags, 20:00 Uhr, Vorlage liegt auf dem RFC-Editor-Server bereit.