Zusammenfassung

  • Das frühe Telnet reservierte die obere Hälfte des Byte-Raums für Steuersignale. Später bündelte das Protokoll die Befehlsgewalt im IAC-Präfix mit dem Wert 255, sodass die übrigen 255 Werte nicht mehr mit freistehenden Befehlscodes kollidierten.
  • Ein wörtlicher Datenwert 255 wird als IAC IAC codiert. Die ausgehandelte Binary Transmission öffnet den gesamten Acht-Bit-Datenraum, schaltet die Telnet-Steuerung jedoch nicht ab: Empfänger suchen weiterhin nach IAC und führen eingebettete Befehle aus.

Eine rote Kachel konnte anweisen, zwei wurden zu einem Datum

Man stelle sich eine Binärdatei vor, die durch ein Terminalprotokoll läuft. Das nächste Byte hat zufällig den Dezimalwert 255. Deutet der Empfänger ihn als „interpretiere das nächste Byte als Befehl“, verschluckt die Protokollsyntax einen Teil der Datei. Behandelt er ihn immer als Inhalt, übersieht er eine echte Anweisung zur Änderung einer Option. Auf der Leitung steht in beiden Fällen dieselbe Zahl.

Telnet löste die Mehrdeutigkeit mit einer kleinen Grammatik. Ein einzelnes IAC — Interpret As Command — eröffnet Steuerung. Darauf folgt ein definierter Befehlscode, gegebenenfalls ergänzt um weitere Bytes. Nur IAC gefolgt von IAC steht für ein gewöhnliches Datenbyte mit dem Wert 255. Der Sender verdoppelt; der Empfänger erkennt das Paar und entfernt die für die Rahmung benötigte Kopie.

Das ist kein allgemeines Fluchtzeichen nach dem Muster „was danach kommt, ist wörtlich“. Das zweite IAC hat an dieser Stelle eine einzige, präzise Bedeutung. Andere Werte nach IAC bleiben Telnet-Befehle oder Bestandteile der Befehlssyntax. Zwei Bytes auf dem Draht werden zu einem Byte in der Anwendung, weil beide Enden denselben Parserzustand teilen.

Die Regel gewann mehr als nur einen unbequemen Wert zurück. Daten und Steuerung blieben geordnet in einer Verbindung, ohne einen großen Teil des Acht-Bit-Alphabets dauerhaft zu opfern.

Das erste Telnet gab die Hälfte des Raums an die Steuerung

Im April 1972 beschrieb RFC 318 das offizielle ARPANET-Telnet rund um ein Network Virtual Terminal. Die Werte 0 bis 127 trugen USASCII; 128 bis 255 waren besonderen Steuersignalen zugeordnet.

Für die damalige Hauptaufgabe, unterschiedliche Textterminals zu verbinden, war diese Teilung nachvollziehbar. Ein hoher Wert konnte eindeutig eine Protokollhandlung anzeigen, während Sieben-Bit-ASCII die gemeinsame Darstellung abdeckte. Reichere Zeichensätze und beliebige Binärinhalte legten jedoch den Preis offen: Die Hälfte aller Werte stand der Anwendung nicht ohne Weiteres zur Verfügung.

RFC 318 nannte Auswege in andere Codierungen, darunter einen Transparent-Modus. Zugleich räumte das Dokument ein, dass die Bedeutung von Telnet-Signalen und sogar der Rückweg zu ASCII danach undefiniert sein konnten. Sobald sich das Datenalphabet erweiterte, war die Fähigkeit des Protokolls gefährdet, seine eigenen Kontrollen zu erkennen.

Das Problem war eine Frage der Verfassung des Protokolls. Wenn viele nackte Bytewerte Steuerbefugnis tragen, kollidiert jede Erweiterung des Datenvokabulars mit dieser Befugnis.

Ein QUOTE-Vorschlag machte die Form der Lösung sichtbar

RFC 435, eine Diskussion von Telnet-Fragen aus dem Januar 1973, erwog direktes Binär als Voreinstellung. Die Autoren schlugen ein QUOTE-Zeichen vor, nach dem das folgende Byte stets als Daten gelesen würde. Hohe Werte könnten Befehlsraum bleiben, zitierte Vorkommen aber wörtlich reisen.

Dieser Vorschlag ist nicht die spätere IAC-Regel und darf nicht rückwirkend als eingeführtes Verhalten dargestellt werden. Er zeigt dennoch den Entwurfsdruck: Telnet brauchte eine Escape-Grenze, die einen Wechsel der Dateninterpretation überstand.

Zwei Wege lagen nahe. Viele Werte für Kontrolle reservieren und viele mögliche Kollisionen zitieren; oder einen einzigen ausgezeichneten Wert als Eingang zur Kontrolle festlegen, sodass nur dieser Wert als Datum einen Aufpreis kostet. Das spätere Internet Telnet entschied sich für den zweiten Weg.

IAC verdichtete die Befehlsgewalt in einem Präfix

RFC 764 vom Juni 1980 beschrieb Telnet als acht-bit-byte-orientierte Einrichtung über eine TCP-Verbindung, in der Steuerinformationen zwischen Daten stehen. Der Basisstandard RFC 854 vom Mai 1983 behielt diese Architektur bei.

Jeder Telnet-Befehl beginnt mit IAC, Wert 255, gefolgt von einem Befehlscode. Aushandlungen wie WILL, WON'T, DO und DON'T führen ein drittes Byte für die betreffende Option. Andere Codes markieren etwa das Ende einer Unteraushandlung, keine Operation, Data Mark, Unterbrechung, Ausgabeabbruch oder Zeichenlöschung.

Der Tausch ist ausdrücklich formuliert. Wenn Aushandlungen eine umfassendere Nutzung des Datenraums ermöglichen, müssen Befehlskollisionen minimiert werden. Im IAC-Entwurf muss nur IAC selbst als Datenwert verdoppelt werden; die anderen 255 Bytewerte können hinsichtlich der grundlegenden Befehlsrahmung transparent passieren.

„Transparent“ ist hier eng zu lesen. Der NVT-Modus besitzt weiterhin Zeichen- und Zeilenkonventionen; nicht jede Bedeutung bleibt unangetastet. Gemeint ist, dass andere Werte nicht allein wegen ihrer Zahl als selbstständige Telnet-Befehle gelten. Die Steuerbefugnis wanderte aus einer ganzen Region nackter Bytes hinter ein einziges Tor.

Der Befehl stand genau an der Grenze der neuen Interpretation

Weil Daten und Steuerung denselben Strom nutzen, wird Reihenfolge zum Vorteil. RFC 854 verlangt, dass ein Aushandlungsbefehl an der Stelle eingefügt wird, an der die vom Absender gewünschte neue Interpretation seiner folgenden Daten beginnen soll.

Der Empfänger erhält keine abgetrennte Kontrollmeldung über irgendeinen unbestimmten späteren Zeitpunkt. Er liest frühere Bytes im alten Zustand, stößt dazwischen auf den Befehl und behandelt spätere Bytes im neuen Zustand. Eine geordnete Unterhaltung trägt ihre Bedeutungsgrenze in sich.

Diese Grenze verpflichtet den Parser. TCP kann IAC in einem Lesevorgang liefern und das Folgebyte im nächsten; Segmentgrenzen sind keine Telnet-Datensätze. Die Implementierung muss den Zustand „Präfix gesehen, Fortsetzung offen“ behalten. Sie darf die Verdopplung genau einmal auflösen: Beide Bytes zu behalten beschädigt die Daten, ein echtes IAC-Befehlspaar als Datum zusammenzuziehen löscht Steuerung.

Der Transport bewahrt die Reihenfolge. Telnet liefert die Grammatik. Keines von beiden erzeugt automatisch Nachrichten aus einem Strom.

Die Unteraushandlung erbte dieselbe Escape-Disziplin

Manche Optionen brauchen Parameter, nicht nur Ja oder Nein. RFC 855 rahmt eine Unteraushandlung mit IAC SB, Optionscode und Parametern bis zum abschließenden IAC SE. Selbst ein Empfänger, der das Parameterformat nicht versteht, kann so das Ende finden.

Enthält ein Parameter selbst den Wert 255, gilt die allgemeine Regel: Er wird verdoppelt. Andernfalls könnte Nutzlast wie beginnende Telnet-Syntax aussehen oder zusammen mit dem nächsten Wert eine falsche Endmarke bilden.

Das ist eine kompakte Form geschichteter Zuständigkeit. Die Option bestimmt die Bedeutung ihrer Parameter, aber die Telnet-Basisschicht behält IAC in ihrer Obhut. Eine Erweiterung darf den Wert, der den gemeinsamen Strom schützt, nicht neu definieren.

Diese Grenze machte Unwissen beherrschbar. Solange der Sender ein wörtliches 255 korrekt maskiert, kann ein Basisparser selbst undurchsichtige Optionsnutzlast bis zum echten IAC SE überspringen.

Der Binärmodus öffnete acht Bits, ohne Steuerung abzuschalten

Beliebige Binärdaten waren die entscheidende Probe. RFC 856 definiert Option 0, Binary Transmission. Sie wird für jede Richtung getrennt ausgehandelt: Eine Seite kann dem Empfang von Acht-Bit-Binärdaten zustimmen, während die Gegenrichtung bei ihrer bisherigen Interpretation bleibt.

Nach der Aktivierung gelten Bytes, denen kein IAC vorausgeht, als Acht-Bit-Binärdaten. Dennoch bedeutet IAC IAC weiterhin den Datenwert 255, und IAC vor einem wirksamen Telnet-Befehl bleibt ein Befehl. Binary verändert die Behandlung der Daten; es macht den gesamten TCP-Strom für Telnet nicht undurchsichtig.

Hier zahlt sich das Präfix aus. Trügen noch alle Werte von 128 bis 255 Steuerbedeutung, müsste der Binärmodus die Hälfte des Alphabets maskieren oder Befehle aufgeben. Eine einzige Eingangszahl lässt fast alle Binärwerte direkt reisen und erhält Optionswechsel in derselben Verbindung.

Binary ist daher nicht „rohes TCP nach der Aushandlung“. Es ist eine Datenkonvention unter einer fortbestehenden Telnet-Rahmungsregel.

Host-Anforderungen machten die Ausnahme unvergesslich

Im Oktober 1989 erhob RFC 1123 das Verhalten zur ausdrücklichen Host-Anforderung. Da Telnet-Optionen überall im Datenstrom auftreten dürfen, muss ein als Datum gesendetes IAC verdoppelt werden. Auch nach erfolgreicher Binary-Aushandlung suchen Empfänger weiter nach IAC, befolgen eingebettete Befehle und verlangen die Verdopplung des Datenwerts 255.

Andere Umformungen entfallen. Im Binary-Modus dürfen die üblichen Wagenrücklauf-Ersetzungen und Zeilenende-Konventionen nicht angewandt werden. Der Kontrast verhindert eine verbreitete Abkürzung: „binär“ darf Textnormalisierung abschalten, nicht den Telnet-Parser.

Das heutige IANA-Register der Telnet-Optionen führt den Optionsraum und seine Referenzen, darunter Binary Transmission als Option 0. Es ist keine Erhebung gegenwärtiger Nutzung. Es zeigt außerdem eine Ebenentrennung: Eine Option mit Nummer 255 ist nicht dasselbe wie das IAC-Byte mit Wert 255 im Datenstrom. Gleiche Zahlen verschmelzen keine Protokollrollen.

Ein wiederholtes Byte bewahrte eine geordnete Unterhaltung

Die IAC-Verdopplung wirkt wie ein Leitungsdetail, trennt aber drei Zuständigkeiten. Die Anwendung wählt Daten und darf 255 enthalten. Der Telnet-Sender codiert den Wert so, dass er nicht versehentlich Befehlsbedeutung erhält. Der Empfänger besitzt den Parser, der die verdoppelte Darstellung von einer wirklichen Anweisung unterscheidet.

Kein zentraler Dienst muss die Sitzung prüfen, kein zweiter Kanal Befehle transportieren. Die gemeinsame Schicht setzt eine kleine unveränderliche Regel, die jede Option und jeder Datenmodus respektiert. Erweiterungen dürfen Echo, Terminaltyp, Zeicheninterpretation oder Datensatzgrenzen ändern, nicht aber IAC stillschweigend an sich ziehen.

Die Kosten bleiben: Jede Implementierung scannt; jedes wörtliche 255 braucht ein zusätzliches Leitungsbyte; unvollständige Präfixe verlangen Zustand; fehlerhaftes Escaping kann jede spätere Interpretation verschieben. Auch der Gewinn bleibt: Daten und Kontrolle entwickeln sich zusammen, ohne dass ein Datenwert irrtümlich Autorität bekommt.

Das Byte musste sich nicht wiederholen, um mächtiger zu werden. Die erste Ausführung übernahm die Befehlsgrenze, damit die zweite Daten bleiben konnte.

Quellen und Grenzen

Der frühe Halbraum-Entwurf stammt aus RFC 318, die QUOTE-Diskussion aus RFC 435. RFC 764 und RFC 854 belegen den durchmischten Strom und die IAC-Grammatik. RFC 855 regelt das Escaping in Unteraushandlungen, RFC 856 das Binary-Verhalten, RFC 1123 die Host-Anforderungen und das IANA-Register den Optionsraum. Daraus folgen weder aktuelle Verbreitung noch Produktkonformität, Parsersicherheit, Verschlüsselung, Authentisierung oder ein gemeinsames Einführungsdatum aller Hosts.