Zusammenfassung

  • Abhay Bhushans frühes FTP vereinheitlichte Handlungen zwischen ungleichen Hosts, nicht deren interne Dateisysteme.
  • Eine Bestandsaufnahme der Hosts und der Workshop von 1972 trennten tragfähige Gemeinsamkeiten von weiter lokalen Konventionen wie Pfadnamen und Zugriffsregeln.
  • Die ausdrückliche Ablehnung einer nicht unterstützten Kombination war kein Mangel, sondern eine verlässliche Form von Interoperabilität.

Der entfernte Name blieb entfernt

Ein Pfadname beschreibt mehr als einen Speicherort. Er verrät, ob ein System Verzeichnisse kennt, wie es Konten einbezieht, welche Teile fehlen dürfen, wie Versionen bezeichnet werden und wer einen Zugriff erhält. Im ARPANET von 1971 gab es für diese Fragen keine selbstverständliche, gemeinsame Grammatik.

Hier liegt die eigentliche Leistung von Abhay Bhushan. Er schrieb nicht bloß eine Reihe von Befehlen, aus denen später ein allgegenwärtiges Protokoll wurde. Er bestimmte, welche Schicht zwischen sehr verschiedenen Betriebssystemen überhaupt vereinheitlicht werden konnte. Das Protokoll durfte eine Operation übermitteln und Transportmerkmale aushandeln. Es durfte den entfernten Namensraum nicht so behandeln, als gehöre er dem Netz.

Die Internet Hall of Fame führt Bhushan als Autor der ursprünglichen FTP-Spezifikation. Er arbeitete demnach von 1967 bis 1974 am Project MAC des MIT und verfasste mehr als zwanzig RFCs. Die frühen Texte machen diese Rolle greifbar: Neben dem Schreiben der Spezifikation sammelte er Anforderungen, organisierte eine offene Werkstatt und hielt fest, worüber keine Einigung zustande kam.

Ein Entwurf, der eine Erhebung verlangte

RFC 114 vom April 1971 unterschied zwischen direkter Nutzung eines entfernten Hosts und einer indirekten Nutzung durch einen vermittelnden Prozess. Dieser konnte fremde Befehle und Konventionen teilweise vor dem Menschen verbergen. Die Idee einer einheitlichen Oberfläche war damit angelegt. Bhushan behandelte das Dokument dennoch als ersten Schnitt und verwies auf eine Erhebung zu Anforderungen und Fähigkeiten der Netzwerk-Hosts.

Diese Reihenfolge schützte die Spezifikation vor falscher Universalität. Effizienz, Erweiterbarkeit, Anpassung, Fehlerbehebung und Unabhängigkeit von einer bestimmten Anwendung waren wichtige Kriterien. Ob und wie sie erreichbar waren, musste sich aber an vorhandenen Systemen zeigen. Ein elegantes Modell ersetzte keine Kenntnis ihrer Eigenheiten.

Der RFC 180 machte die Erhebung konkret. Der zuständige Unterausschuss wollte Namens- und Zugriffskonventionen damals ausdrücklich nicht standardisieren. Wer einen entfernten Host nutzte, musste dessen Regeln weiterhin kennen. Auf Bhushans Bitte sammelte Alex McKenzie Angaben über zulässige Namen, Standardwerte, Verzeichnisfunktionen, Zugriffsbeschränkungen und Dateidarstellungen.

Der Fragebogen war somit ein Bestandteil der Architektur. Er zog Annahmen ans Licht, die innerhalb eines Hosts unsichtbar wirkten, außerhalb aber zu Fehlern führten. Erst in vergleichbarer Form ließ sich entscheiden, was zum gemeinsamen Mindestumfang gehörte, was ausgehandelt werden konnte und was abgelehnt werden musste.

Fortschritt ohne vorgetäuschten Konsens

Mit RFC 309 wurden 1972 Interessierte zu einem Workshop über Daten- und Dateitransfer eingeladen. Positionspapiere waren erwünscht; eine Arbeitssitzung sollte das Protokoll anhand heutiger und erwarteter Bedürfnisse überarbeiten. Bhushan suchte keine nachträgliche Zustimmung zu einem fertigen Text. Unterschiedliche Anwendungen und Hosts sollten den Entwurf prüfen.

Die Notizen in RFC 327 dokumentieren auch die Grenze dieser Verständigung. Eine Network Virtual File Image, die mehr gemeinsame Struktur hätte ausdrücken können, wurde erörtert. Es kam zu keiner Einigung, und die Idee wurde vorerst fallengelassen. Engere Ziele blieben bestehen: Datenintegrität, klare Darstellung und Interpretation von Zeichen, strukturelle Information soweit praktikabel und ein virtuelles Dateisystem als längerfristige Möglichkeit.

Zugleich traf die Runde umsetzbare Entscheidungen. Befehle sollten druckbar sein, Steuer- und Datenverbindung getrennt, grundlegende Darstellungen verpflichtend. Konnte ein Server die verlangte Dateistruktur nicht annehmen, sollte er die Anfrage zurückweisen und den Nutzer informieren. Bhushan übernahm Protokollnotiz und neuen Entwurf.

Gerade die verworfene Idee zeigt die Qualität des Verfahrens. Eine Zukunftsvorstellung wurde nicht als vorhandener Konsens ausgegeben. Der kleinere, belastbare Kern konnte eingeführt werden, ohne die ungelöste Dateisemantik zu verschleiern.

Gemeinsame Verben, lokale Substantive

RFC 171 löste den allgemeinen Datentransfer von anwendungsspezifischen Funktionen, um eine Vielzahl paralleler Mechanismen zu vermeiden. RFC 172 versprach, Unterschiede zwischen Hosts nur soweit praktisch zu verbergen, erlaubte Teilimplementierungen und vereinbarte Erweiterungen und ließ die Schreibweise des Pfadnamens standortspezifisch.

Das Protokoll vereinheitlichte damit vor allem Verben: abrufen, speichern, auflisten. Darstellung, Struktur und Übertragungsmodus ließen sich im Steuerdialog benennen. Das Substantiv, auf das der Befehl zielte, blieb jedoch in der Sprache des entfernten Hosts. Ein Trenner, ein Kontozusatz, eine Versionsnummer oder ein implizites Verzeichnis konnte dort eine eigene Bedeutung besitzen. Auch die Berechtigung zu diesem Objekt blieb lokal.

RFC 354 setzte diese begrenzte Vereinbarung in beobachtbares Verhalten um. Nicht jeder Server musste jede Darstellung, jeden Typ, Modus oder jede Bytegröße unterstützen. Er musste aber mitteilen, wenn die gewünschte Kombination nicht möglich war. Eine negative Antwort wurde dadurch zu verwertbarer Protokollinformation.

Ein präziser Fehler erlaubt dem Client, die Anfrage anzupassen. Eine stille Umwandlung kann Struktur oder Bedeutung verändern und trotzdem Erfolg melden. Sichtbare Grenzen sind deshalb nicht das Gegenteil von Kompatibilität. Sie verhindern, dass ein scheinbar erfolgreicher Austausch einen schwerer erkennbaren Schaden erzeugt.

Warum die Schnittstelle enden musste

RFC 959 zeigt 1985 ein Protokoll, das über viele Jahre gereift war. Diese spätere Fassung darf nicht rückwirkend zur Beschreibung aller Entscheidungen von 1971 und 1972 werden. Der frühe Ablauf lautet vielmehr: Entwurf, Erhebung, offene Diskussion, begrenzte Vereinbarung, Revision.

Der kleine gemeinsame Kern ermöglichte reale Nutzung, bevor die Hosts ihre internen Modelle vereinheitlicht hatten. Das verlagerte Aufwand in die Clients, die entfernte Namensregeln kennen mussten, und in die wachsende Zahl von Fähigkeiten und Erweiterungen. Ein vollständiges universelles Dateisystem hätte jedoch womöglich den Einsatz verhindert oder die Gewohnheiten mächtiger Hosts als neutrale Norm festgeschrieben.

Der Pfadname kennzeichnet den Zuständigkeitswechsel. Das Netz trägt die Operation, der Zielhost definiert das Objekt, deutet seinen Namen und kontrolliert den Zugang. Bhushans Entwurf war stark, weil er diese Grenze nicht verdeckte. Eine langlebige Schnittstelle sagt nicht nur, was überall gleich ist. Sie sagt ebenso deutlich, wo das Gemeinsame aufhört.

Quellen