Zusammenfassung

  • FEAT machte dokumentierte FTP-Erweiterungen sichtbar, ohne jeden möglicherweise wirksamen Befehl einzeln ausprobieren zu müssen; OPTS konfigurierte einen späteren Zielbefehl.
  • Eine konforme positive Liste war vollständig, ein 500- oder 502-Fehler bewies dagegen keine Abwesenheit: ältere Server konnten Vor-FEAT-Erweiterungen implementiert haben.
  • Anzeige, Optionsannahme, Authentisierung, Autorisierung, Befehlsende, Datenkanal und beobachteter Dateizustand blieben verschiedene Belege.

Die Probe war selbst schon eine Handlung

FTP wuchs über den Grundbestand von RFC 959 hinaus. Neue Befehle und Mechanismen wurden nicht gleichzeitig auf allen Servern verfügbar. Ein Client konnte eine Spezifikation kennen und trotzdem nicht wissen, ob die konkrete Gegenstelle sie umgesetzt hatte.

Der direkte Versuch lieferte womöglich eine Antwort. RFC 2389 benannte jedoch zwei Kosten: Viele Einzelversuche erzeugten unnötigen Verkehr, und ein nur zur Erkennung gesendeter Befehl konnte eine unerwünschte Wirkung haben. Die Frage nach einer Fähigkeit benutzte dieselbe Schnittstelle wie die Nutzung dieser Fähigkeit.

FEAT trennte beide Vorgänge. Der parameterlose Befehl forderte eine strukturierte Liste an. Der Server beschrieb seine Erweiterungen; der Client verglich sie mit seinem eigenen Wissen und entschied lokal. Das gemeinsame Protokoll definierte den Rahmen, während die jeweilige Erweiterung Bedeutung und Parameter ihres Eintrags festlegte.

Diese dünne Schicht war keine zentrale Freigabe. Sie machte Wissen vor einer Handlung verfügbar und ließ die eigentliche Entscheidung dort, wo Implementierung, Nutzer und gegenwärtiger Zustand bekannt waren.

Eine Leerstelle mit syntaktischer Aufgabe

Eine nicht leere Antwort begann als mehrzeilige 211--Antwort. Jede Funktionszeile musste mit genau einem Leerzeichen beginnen; 211 End schloss die Liste. Das Leerzeichen war kein Layout. Es sorgte dafür, dass eine Funktionszeile nicht als Abschluss missverstanden werden konnte.

Der Einleitungstext war frei, die folgenden Zeilen nicht. Ein Funktionslabel konnte einem Befehlsnamen entsprechen, musste es aber nicht. Parameter erhielten ihre Bedeutung aus der Spezifikation der Erweiterung. Die Reihenfolge war bedeutungslos und durfte sich zwischen zwei Anfragen ändern.

Unbekannte Labels waren ausdrücklich zulässig. Ein alter Client sollte eine spätere Erweiterung nicht als Protokollfehler behandeln. Er konnte das Unbekannte ignorieren und den gemeinsam verstandenen Teil weiterverwenden. Damit blieb Erweiterbarkeit mit älteren Implementierungen vereinbar.

FEAT selbst stand nicht in der Liste; eine andere Antwort als 500 oder 502 bewies ihre Unterstützung. OPTS stand ebenfalls nicht darin, weil jede FEAT-Implementierung es mitbringen musste. Die Liste blieb bei ihrer Aufgabe, statt jedes bereits aus der Unterhaltung ableitbare Merkmal zu wiederholen.

Vollständigkeit galt nur nach erfolgreicher Antwort

Ein Server mit FEAT musste alle ordnungsgemäß dokumentierten FTP-Erweiterungen nennen, die er über RFC 959 und RFC 2389 hinaus unterstützte. Deshalb durfte ein Client die konforme positive Liste als vollständig behandeln. Fehlte eine Erweiterung dort, war sie auf diesem Server nicht unterstützt.

Aus einem 500 oder 502 folgte das Gegenteil nicht. Diese Antworten sagten lediglich, dass der Server FEAT nicht erkannte. Erweiterungen waren schon vor der Listenfunktion verbreitet. Ein älterer Server konnte einen solchen Befehl beherrschen, ohne ihn auflisten zu können. Für diese Alt-Erweiterung musste der Client möglicherweise doch gezielt prüfen.

Auch ein Server, der FEAT verstand, aber nichts Zusätzliches implementierte, sollte zwar eine einzeilige 211-Antwort senden, durfte jedoch 500 oder 502 verwenden. Für den Client waren „keine Liste möglich“ und „Liste leer“ praktisch nicht immer unterscheidbar.

Die Beweisregel war damit absichtlich asymmetrisch. Innerhalb einer gültigen vollständigen Antwort war Abwesenheit aussagekräftig. Ohne diese Antwort blieb Abwesenheit unbekannt. Die Spezifikation machte aus historischem Schweigen keine nachträgliche Behauptung.

OPTS bestätigte eine Einstellung, nicht die Leistung

Erweiterungen konnten mehrere Betriebsweisen anbieten. OPTS erlaubte dem Client, einen Zielbefehl und gewünschte Optionen anzugeben. Syntax und Wirkung kamen aus dessen eigener Spezifikation.

200 bestätigte, dass Ziel und Optionen erkannt und angemessen waren. 501 stand für ein dauerhaftes Problem, solange sich der Zustand nicht änderte. 451 beschrieb eine vorübergehende Serverbedingung. Keine dieser Antworten besagte, dass der Zielbefehl bereits gelaufen war.

RFC 3659 zeigte dies mit MLST. Die Funktionszeile konnte verfügbare Dateifakten aufzählen und Standardfakten mit einem Stern markieren. OPTS MLST änderte, welche Fakten spätere MLST- und MLSD-Antworten enthielten. Manche nicht standardmäßig ausgewählten Fakten konnten teuer zu erzeugen sein und sollten nicht ohne betrieblichen Grund angefordert werden.

Der Server kann einen Fakt kennen, ihn anbieten, standardmäßig auswählen, einen Wunsch dafür annehmen und ihn bei einem passenden Dateiobjekt tatsächlich liefern. Diese Zustände in „unterstützt“ zusammenzufassen würde gerade die Steuerungsinformation beseitigen.

Eine TLS-Anzeige war noch kein TLS-Kanal

RFC 4217 verwendete FEAT für FTP über TLS. Der Server zeigte AUTH TLS, PBSZ und PROT an. Damit wurde ein möglicher Verhandlungsweg sichtbar, aber noch keine Verbindung geschützt.

Der Client musste AUTH TLS senden, der Server mit 234 annehmen, der TLS-Handshake musste gelingen, Schutzparameter mussten gesetzt, die Zertifikatsidentität geprüft und gegebenenfalls der FTP-Nutzer authentisiert werden. Ein Listeneintrag konnte weder die Identität bestätigen noch eine Dateioperation genehmigen.

RFC 7151 wiederholte die Grenze bei HOST. Die Anzeige von HOST versprach die Auswahl virtueller Hosts. Die Auswahl konnte aber die Authentisierungsumgebung wechseln, und der angegebene Name musste weiterhin zur Zertifikatsidentität passen. Eine Tür zu sehen, eine Tür auszuwählen und berechtigt einzutreten sind unterschiedliche Tatsachen.

Das Register koordinierte Namen, nicht Qualität

RFC 5797 schuf später das IANA-Register für FTP-Befehle und -Erweiterungen. Es sollte Namenskollisionen und daraus entstehende Mehrdeutigkeit verhindern. Erfasst wurden Befehl, FEAT-Code, Beschreibung, Typ, Konformitätserwartung und Referenz. Historische Namen blieben erhalten, damit sie nicht neu belegt wurden.

Die RFC stellte ausdrücklich klar, dass ein Eintrag keine „Genehmigung“ einer Erweiterung beweise. Eine dauerhaft verfügbare öffentliche Spezifikation oder eine Implementierung in allgemein erhältlichen Clients und Servern konnte als Grundlage genügen. Platzhalter reservierten Namen, waren aber nicht als echte FEAT-Ausgabe gedacht.

Das Register schützt die Zuordnung von Name und Definition. Der Server beschreibt seine lokale Implementierung. OPTS belegt eine Auswahl. Identität und Richtlinie entscheiden über die Nutzung. Der laufende Befehl und der Datenkanal liefern den Ergebnisbeleg. Eine Namenskoordination, die all diese Rollen beansprucht, würde aus ihrer technischen Notwendigkeit eine unverdiente Autorität ableiten.

Begrenzte Offenlegung statt wirkender Erkundung

RFC 2389 räumte ein, dass eine Funktionsliste Servereigenschaften offenlegt. Ohne FEAT konnte ein Beobachter Befehle einzeln testen; diese Erkundung mochte allerdings in Protokollen auffälliger sein. Der Unterschied erschien den Autoren nicht schwer genug, um auf die strukturierte Abfrage zu verzichten.

Die Wahl lautete nicht vollständige Offenheit gegen vollständige Geheimhaltung. Es ging um eine begrenzte, stabile Beschreibung, die Interoperabilität ermöglicht und unnötige Wirkversuche vermeidet. Für die Sicherheit jeder Erweiterung blieb deren eigene Spezifikation zuständig.

RFC 2389 machte damit eine bescheidene, aber folgenreiche Aussage: „Welche zusätzlichen Sprachen sprichst du?“ lässt sich vor „Wirst du diesen Auftrag für mich ausführen?“ beantworten. Die erste Antwort verbessert die Entscheidung. Den Ausgang kann nur die laufende Interaktion belegen.

Quellen