Zusammenfassung

  • Die frühen Netzentwickler wollten eine Vielzahl getrennter Transferprotokolle vermeiden. RFC 114 prüfte, was ein Dateiprotokoll übernehmen könnte – bis hin zu execute.
  • RFC 171/172 zogen die Grenze anders: Anwendungen konnten die Transferschicht teilen, doch für entfernte Ausführung gab es in FTP kein Standardverfahren.

Wenn ein heutiger Webdienst eine Datei nicht nur annimmt, sondern auch ihre Verarbeitung startet, entscheidet ein scheinbar kleines API-Detail über konkrete Fragen: Welche Schnittstelle verspricht der Dienst? Wer ist für den Auftrag zuständig? Was geschieht, wenn die Verarbeitung scheitert? Solche Grenzen sind in verteilten Anwendungen alltäglich. Die RFCs von 1971 sind keine Vorfahren heutiger Microservices; sie dokumentieren aber einen frühen, klaren Fall derselben Architekturfrage: Was soll ein gemeinsames Netzprotokoll regeln, und was bleibt Sache der Anwendung? RFC 114 macht die Tragweite an einem Wort sichtbar. Auf retrieve und rename folgt execute – die Anfrage, ein anderer Rechner solle Arbeit erledigen. Wenige Monate später schlug RFC 171 ein gemeinsames Transferprotokoll für mehrere Anwendungen vor; RFC 172 setzte FTP darauf auf und ließ entfernte Ausführung ohne Standardverfahren. Der Vergleich betrifft die wiederkehrende Grenzziehung, nicht eine direkte Entwicklungslinie.

In RFC 114 konnte eine Datei Anweisungen, Daten oder beides enthalten. Deshalb stand execute neben Abruf und Speicherung. Es handelte sich um eine begrenzte Transaktion, nicht um eine allgemeine entfernte Shell. Die Kopfzeile trägt das Datum 16. April 1971; im Katalog des RFC Editors steht der 1. April. Der Vorschlag beschreibt Transaktionen, über die kooperierende Prozesse das Dateisystem eines anderen Hosts nutzen sollten. Die Liste reicht von Identifizieren und Abrufen über Speichern, Anhängen, Umbenennen, Löschen, Öffnen, Schließen und Suchen bis zu execute.

Das war keine allgemeine entfernte Shell. RFC 114 beschreibt, wie Eingaben übertragen, ein Programm oder Unterprogramm auf dem Serverhost ausgeführt und die Ausgaben zurückgegeben werden. Die Reichweite bleibt begrenzt: Der anfragende Prozess sollte die Konventionen für Argumente und Antworten kennen. Der Entwurf skizzierte einen kontrollierten Austausch rund um eine Programmdatei, keine universelle Kommandozeile und kein Sicherheitsmodell.

Der vorgesehene Einsatz war konkret, aber begrenzt. RFC 114 zufolge wurde das Protokoll für eine unmittelbare Implementierung auf zwei MIT-Hosts entwickelt: GE 645/Multics und PDP-10/DM/CG-ITS, möglicherweise auch auf einem Harvard-Host. Eine Zwischenfassung mit eingeschränkten Fähigkeiten wurde gerade getestet. Das belegt einen bestimmten Implementierungsversuch; es zeigt weder, dass jede aufgeführte Transaktion funktionierte, noch dass sich das Protokoll im Netz verbreitete.

Spätere Entwurfsdokumente ziehen die Grenze deutlicher. RFC 171 vom Juni 1971 schlug ein gemeinsames Data Transfer Protocol für mehrere Anwendungen vor: Dateiübertragung, entfernte Auftragseingabe, Netzpost, Grafik und entfernte Programmausführung. Das Architekturargument lautete: Eine Trennung von Transfer und Anwendungsfunktionen würde die Umsetzung flexibler machen, Komplexität verringern und der Vermehrung von Protokollen entgegenwirken.

Der begleitende RFC 172 nutzte dieses gemeinsame DTP zum Datentransport und definierte Dateioperationen als Anwendung. Hosts durften nur eine Teilmenge der Befehle unterstützen. Außerdem hieß es, FTP könne für entfernte Programmausführung erweitert werden; ein Standardverfahren wurde dafür jedoch nicht vorgeschlagen. Die Möglichkeit blieb denkbar, wurde aber keine standardmäßige FTP-Prozedur.

Das ist wichtig, denn eine Spezifikation kann eine Operation in ihren Umfang aufnehmen, ohne sie zu einem verlässlichen Dienst über verschiedene Implementierungen hinweg zu machen. Zeitgenössische Kommentare in RFC 141 erörtern lokalen Dateizugriff, Befehls-Teilmengen und mögliche lange Wartezeiten bei der Ausführung eines Auftrags. Sie zeigen Fragen der Entwickler, keine Erhebung zur Nutzung. Spätere FTP-Fassungen bilden eine Spezifikationslinie ab, beweisen aber nicht, dass RFC 114s execute verbreitet eingesetzt wurde.

Die nachhaltigere Veränderung war begrifflicher Art. Der Dateitransport und der Mechanismus für den Datentransfer konnten gemeinsam genutzt werden; was eine entfernte Anwendung mit den Daten tat, blieb eine eigene Entscheidung. Der frühe Vorschlag rückte beide Fragen zusammen, um sie gemeinsam zu untersuchen. Bis Juni machten die Dokumente die Trennung zwischen einer wiederverwendbaren Transferschnittstelle und anwendungsspezifischen Befehlen deutlicher. Entfernte Ausführung blieb eine mögliche Erweiterung, aber keine Standardaktion von FTP.

Das ist als Änderung des Spezifikationsumfangs zu lesen, nicht als Geschichte einer gefährlichen Funktion, die weit verbreitet eingeführt und später entfernt wurde. RFC 114 dokumentiert einen ambitionierten ersten Entwurf und eine begrenzte Zwischenimplementierung. RFC 171/172 dokumentieren eine klarere Aufgabenteilung. Die Texte zeigen, was ihre Autoren spezifizierten; sie belegen für sich weder Verbreitung noch Betriebssicherheit oder das Verhalten jedes Hosts.

Quellen