Zusammenfassung

  • Das spätere FTP legte das Übertragungsbyte auf acht Bit fest. TYPE L konnte unabhängig davon eine andere logische Bytebreite angeben, deren Grenzen über die Transportbehälter hinweg verliefen.
  • Der Empfänger durfte eine für seine Maschine passende Speicherung wählen, musste sie aber umkehrbar gestalten und dieselbe Datei bei gleichen Parametern wieder ausgeben können.
  • Image bewahrte eine fortlaufende Bitfolge; Local erklärte zusätzlich deren Einheiten. Weder ein positives Kommando noch ein Registereintrag bewies beliebige Größenunterstützung oder heutige Nutzung.

Der fünfte Behälter war geteilt

Zwei Wörter mit je 36 Bit ergeben 72 Bit. Acht Bit pro FTP-Übertragungsbyte ergeben neun Behälter. Nach vier Behältern fehlen dem ersten Wort noch vier Bit. Sie liegen in der ersten Hälfte des fünften; dessen zweite Hälfte gehört bereits zum folgenden Wort.

RFC 765 und RFC 959 verwenden genau dieses Beispiel. Es zeigt, warum eine Übertragungsgrenze keine Aussage über die logische Grenze ist. TCP kann die neun Bytes zudem beliebig auf Segmente verteilen. Keine Paketgrenze ersetzt den gespeicherten TYPE-Zustand.

Ein Vermittler kann daher jedes Übertragungsbyte unverändert kopieren und die Datei dennoch unbrauchbar machen. Richtet er nach acht Bit aus, setzt er eine neue Struktur. Fügt er nach jedem 36-Bit-Wort Nullen ein, schafft er ein anderes Format. Bitgenaue Beförderung und richtige Repräsentation sind verschiedene Beweise.

Die erste Spezifikation zeigte die Maschinenvielfalt offen

RFC 114 von 1971 enthielt weit mehr als Text und Binärdaten. Die Typentabelle nannte ASCII-Varianten, EBCDIC, SIXBIT, Dezimal-, Oktal- und Hexadezimalformen, unterschiedlich vorzeichenbehaftete Ganzzahlen sowie Gleitkommaformate für IBM 360 und PDP-10. Bei manchen Ganzzahlen konnte eine Breite zwischen einem und 255 Bit angegeben werden.

Typinformation sollte interpretiert werden. Ein Host, der einen Typ akzeptierte, konnte ihn in eine geeignete interne Darstellung überführen. Eine 36-Bit-Maschine packte sieben-, acht-, neun- oder sechsbitige Zeichen nicht zwangsläufig gleich in ihre Wörter.

Diese frühe Tabelle ist nicht die TYPE-Syntax von RFC 959. Sie belegt eine frühere Designantwort: Die gemeinsame Schnittstelle versuchte, zahlreiche Unterschiede der angeschlossenen Rechner beim Namen zu nennen. Je mehr Maschinenformen hinzukamen, desto deutlicher wurde jedoch der Preis einer solchen Aufzählung.

1972 konnte sogar die Leitung andere Bytegrößen tragen

RFC 354 trennte Darstellungstyp, Dateistruktur und Übertragungsmodus. ASCII und einige Druckdarstellungen verwendeten acht Bit. Image und Local Byte konnten eine gesondert gewählte Größe auf der Datenverbindung einsetzen.

Server mussten nicht jede mögliche Größe annehmen. Sie durften jene implementieren, die für ihr System effizient waren, sollten aber mindestens acht Bit anbieten. Schon damals bedeutete ein ausdrucksfähiges Protokoll nicht, dass jede Instanz jeden Ausdruck ausführte.

Die Local-Byte-Abbildung hing sowohl von dieser Übertragungsgröße als auch vom jeweiligen Host ab. Sie musste umkehrbar und öffentlich beschrieben sein. Der Nutzer musste Typ und Größe aufbewahren, wenn er die Datei später identisch zurückholen wollte.

Diese Freiheit vergrößerte die Zahl der Verbindungspfade. Eine Maschine konnte intern 36-Bit-Wörter verstehen, ohne eine Datenverbindung mit 36-Bit-Bytes zu unterstützen. Interne Bedeutung und Transportmechanik lagen noch auf derselben Aushandlungsfläche.

Acht Bit wurden Fahrzeugstandard, nicht Weltdefinition

RFC 765 vereinfachte das Modell. Die Übertragungseinheit auf der Datenverbindung war fortan immer acht Bit. RFC 959 beschreibt ausdrücklich zwei Bytegrößen: die logische Größe der Datei und die Größe zur Übertragung. Daneben kann das Speichersystem wiederum eine andere physische Wort- oder Blockgröße besitzen.

TYPE L verlangt einen zweiten, dezimalen Parameter. Es gibt keinen Standardwert. Ohne die Breite kennt der Empfänger zwar die empfangenen Oktette, aber nicht die beabsichtigten Einheiten innerhalb der Folge.

Logische Bytes werden lückenlos gepackt und ignorieren die Grenzen der Übertragungsbytes. Die Vereinheitlichung der Leitung beseitigte also nicht neun-, 18- oder 36-Bit-Einheiten. Sie verlagerte deren Verpackung zu den Endpunkten.

Das war eine begrenzte Standardisierung. Jeder Beteiligte musste acht Bit transportieren können; nicht jeder musste sein Dateisystem oder seine CPU so organisieren. Das gemeinsame Minimum wurde kleiner, während lokale Systeme ihre eigene Geometrie behielten.

Eine Breite ist noch kein Zahlenformat

L 36 sagt, wo eine Einheit endet. Es sagt nicht, ob diese Einheit eine Ganzzahl, Gleitkommazahl, Maschineninstruktion oder ein anderes Objekt ist. Vorzeichen, Exponent, interne Reihenfolge und Anwendungsbedeutung entstehen nicht aus der Zahl 36.

Die Grenze ist dennoch entscheidend. Eine andere Spezifikation oder ein Programm kann nur dann zuverlässig interpretieren, wenn die 36-Bit-Gruppen erhalten sind. FTP standardisierte somit einen Teil der Voraussetzungen für Bedeutung, ohne die Bedeutung selbst zu zentralisieren.

Diese Zurückhaltung schützt auch vor falschen Erfolgsaussagen. Ein Server kann TYPE L 36 akzeptieren und die Bits korrekt speichern, obwohl keine lokale Anwendung ihren Inhalt versteht. Umgekehrt kann eine Anwendung das Format kennen, während der FTP-Server den Parameter ablehnt.

Auffüllung durfte nur die letzte Lücke schließen

Wenn die gesamte logische Folge nicht genau in ein Übertragungsbyte passt, erlauben RFC 765 und RFC 959 notwendige Auffüllung am Ende. Zwischen den logischen Einheiten darf nicht aus Bequemlichkeit auf acht Bit gerundet werden.

Der Ort macht die Nullen unterscheidbar. In der Mitte können sie echte Daten sein. Am Ende einer Datei oder eines Datensatzes lassen sich Rest und aktive Breite zusammen auswerten. Deshalb ist eine Nullfolge im Mitschnitt allein kein Beweis für Padding.

Ein Gateway, das nach jeder 36-Bit-Einheit vier Nullbits einfügt, verbessert nicht bloß die Ausrichtung. Es ändert den Strom, bevor der berechtigte Interpret ihn verarbeitet. Späteres Entfernen ist ohne zusätzliche, nicht im ursprünglichen FTP enthaltene Regeln möglicherweise unmöglich.

Der Empfänger durfte einen größeren Schrank wählen

RFC 959 beschreibt einen 32-Bit-Host, der 36-Bit-Einheiten empfängt. Er kann jede Einheit in einem 64-Bit-Doppelwort speichern, um sie lokal gut bearbeiten zu können. Die ungenutzten Bits dieses Behälters gehören zum Speicherlayout, nicht zur übertragenen Datei.

Diese lokale Wahl steht unter einer harten Bedingung: Die Transformation muss umkehrbar sein. Bei Speicherung und Abruf mit denselben Parametern muss eine identische Datei zurückkommen. Implementierer sollten ihre Abbildung veröffentlichen.

Die Bedingung „dieselben Parameter“ begrenzt den Anspruch. Wer mit TYPE L 36 speichert und mit TYPE L 8 abruft, besitzt keine allgemeine Identitätsgarantie. Ein Archiv, das nur die 64-Bit-Behälter bewahrt, aber Breite und Abbildungsregel löscht, kann später Inhalt und lokalen Leerraum nicht sicher auseinanderhalten.

Image und Local konnten gleich wirken, ohne dasselbe zu behaupten

Image behandelt die Datei als fortlaufende Bits, die in achtbitige Übertragungsbytes gepackt werden. Das Ziel muss die Kontinuität bewahren. Falls sein Speicher eine Ausrichtung verlangt, dürfen identifizierbare Nullbits nur am Ende der Datei oder des Datensatzes hinzukommen.

Local transportiert ebenfalls fortlaufend, erklärt aber eine logische Einheit. Diese zusätzliche Aussage legitimiert eine hostabhängige, umkehrbare Anordnung pro Einheit. In bestimmten Maschinenkonstellationen entsteht dasselbe Ergebnis wie bei Image.

RFC 1123 erläutert: Auf einer Achtbitmaschine ist TYPE L 8 äquivalent zu Image. Zwischen zwei m-Bit-Wortmaschinen sollte TYPE L m denselben Effekt haben. Daraus folgt nicht, dass ein Empfänger bei Image eine beliebige m-Grenze erfinden darf. Ergebnisgleichheit ersetzt keine fehlende Deklaration.

Die Pflichtbasis war schmal

RFC 1123 verlangt Unterstützung für TYPE I und TYPE L 8. Eine Maschine mit m-Bit-Wörtern, wobei m kein Vielfaches von acht ist, darf zusätzlich TYPE L m anbieten.

Die Norm fordert damit eine gemeinsame Achtbitbasis und erlaubt native Ergänzungen. Sie fordert nicht, dass jeder Server jede Dezimalzahl akzeptiert. Eine Ablehnung von L 36 belegt eine Darstellungsgrenze in dieser Sitzung, keinen Netzfehler, Plattenmangel oder beschädigten Inhalt.

Der Client kann Image wählen, vorab in ein gemeinsam verstandenes Format konvertieren oder abbrechen. Eine stille Ersetzung durch L 8 beseitigt zwar den negativen Reply, aber auch die deklarierte 36-Bit-Absicht.

Typ, Struktur und Modus blieben getrennte Achsen

FTP behandelte Darstellung, Dateistruktur und Übertragungsmodus unabhängig. Eine logische Breite bestimmt weder Datensatzgrenzen noch Seitenindizes, Stream-, Block- oder Kompressionsmodus. Sie sagt auch nicht, welche Speichergarantie ein erfolgreicher Abschluss besitzt.

Der veröffentlichte Beitrag über FTP-Restartmarker behandelte, warum ein Marker keine einfache Byteposition sein musste: Der Empfänger kann Transformationszustand benötigen. TYPE L liefert eine Eingangsgröße für diese Transformation. Der Marker liefert den Wiederaufnahmepunkt. Keiner ersetzt den anderen.

ALLO zählte eine Einheit, definierte sie aber nicht

ALLO konnte erwarteten Speicher in logischen Bytes angeben. Die aktive Darstellung lieferte diese Einheit. Die Allokationsanweisung selbst schuf keine 36-Bit-Grenze, und eine positive Antwort bewies nicht zwingend eine physische Reservierung.

Darum ist der ALLO-Artikel nur benachbart. Er untersucht, ob eine Mengenangabe Ressourcen band. Dieser Beitrag untersucht, was gezählt wurde und wie die Einheit über eine Achtbitleitung erhalten blieb. Richtige Repräsentation und ausreichende Kapazität können unabhängig voneinander scheitern.

Das Register kennt TYPE, nicht die Fähigkeiten eines Hosts

Das IANA-Register der FTP-Kommandos und -Erweiterungen führt TYPE als Representation-Type-Kommando und verweist auf die Spezifikation. Es stabilisiert Name und Referenz.

Es nennt nicht die akzeptierten Breiten eines Servers, dessen lokales Speicherverfahren oder gegenwärtige Nutzung. Dafür braucht es Implementierungsdaten, die konkrete Sitzungsantwort, einen Abruf mit gleichen Parametern und gegebenenfalls den Anwendungstest. Registrierung ist Syntaxevidenz, kein Betriebsnachweis.

Die Leitung definierte weniger, die Endpunkte mussten mehr erinnern

FTP bewegte sich von einem großen Typenkatalog über variable Verbindungsbytes zu einer festen Achtbitbeförderung mit optionaler logischer Breite. Die gemeinsame Schicht musste weniger Maschinenwissen tragen, ohne die Unterschiede der Maschinen zu leugnen.

Je bescheidener die Leitung, desto wichtiger wurde die Provenienz am Rand. Bitfolge, Typ, logische Größe, Struktur und Transformationsversion bilden zusammen den wiederherstellbaren Gegenstand. Neun intakte Oktette sind nicht automatisch neun logische Bytes.

Quellen und Grenzen

Die Grundlage bilden RFC 114, RFC 354, RFC 765, RFC 959, RFC 1123 und das IANA-Register. Sie beschreiben historische und normative Regeln, nicht heutige Verbreitung, Produktverhalten, physische Plattenbelegung oder die Anwendungssemantik eines 36-Bit-Werts.