Zusammenfassung

  • RFC 1116 verlagerte die Zeilenbearbeitung und Teile der Signalbehandlung zum Client. Statt mehrerer Pakete je Tastendruck genügten ungefähr mehrere Pakete je Befehlszeile; lange Laufzeiten und paketabhängige Kosten waren nur noch beim Absenden spürbar.
  • DO/WILL, MODE_ACK und SLC_ACK schlossen jeweils andere Aushandlungen ab. Keines davon bestätigte, dass eine Anwendung die Zeile erhalten, zugelassen, ausgeführt oder mit einem Ergebnis beantwortet hatte.
  • EDIT hielt die Eingabe lokal bearbeitbar, bis ein Abschluss- oder Weiterleitungszeichen sie freigab. Der gesendete Präfix war danach lokal nicht mehr änderbar, musste aber weiterhin Transport, Telnet-Auswertung und Entscheidungen des entfernten Prozesses durchlaufen.

Die schnelle Reaktion entstand auf der nahen Seite

RFC 1116 beschrieb das Problem anhand des Paketaufwands. Zeichenweises Telnet konnte für jede Taste ungefähr ein Paketpaar erzeugen. Bei lokaler Bearbeitung sollte ein vergleichbarer Aufwand erst für eine ganze Befehlszeile anfallen. Auf einer Verbindung mit hoher Laufzeit sah ein Benutzer Buchstaben, Löschungen und Korrekturen unmittelbar und wartete erst nach Abschluss der Zeile auf das Netz. In Netzen mit Abrechnung je Paket sank zugleich der Preis, und vorgelagerte Verarbeitung bewahrte teure Großrechner davor, jedes einzelne Zeichen zu verarbeiten.

Das war mehr als Bündelung. Arbeit und Beobachtung wurden getrennt. Der Client konnte Zeichen oder ganze Zeilen löschen, bestimmte Signale abfangen und eine Eingabeeinheit bilden, ehe der Server diese Einheit überhaupt sah. Gerade weil die sichtbare Interaktion keine laufende Beobachtung des entfernten Prozesses mehr war, fühlte sich die Oberfläche schneller an.

Der Informationsdatensatz des RFC Editor bewahrt den Vorschlag vom August 1989 und seine Ablösung; der IETF-Datatracker dokumentiert seinen Statusverlauf. Im Oktober 1990 ersetzte RFC 1184 RFC 1116, ergänzte Modusbits sowie Zeichen für visuelles Editieren und behielt das Prinzip der Bearbeitung im Client bei. Die historische Aussage gilt dieser Entwicklung, nicht einer Behauptung über heutige Verbreitung.

Die Erlaubnis zur Aushandlung war noch kein Modus

Linemode erhielt die Telnet-Option 34. Die allgemeine Optionslogik aus RFC 855 trennte zwei Schritte. Zunächst erlaubten DO und WILL den Gesprächspartnern, über eine Option zu verhandeln. Erst danach wurden ihre Parameter in einer Subnegotiation festgelegt. DONT oder WONT konnten die Erlaubnis wieder zurücknehmen.

RFC 1116 begann mit WONT LINEMODE und DONT LINEMODE. Eine TCP-Verbindung, eine Telnet-Begrüßung oder die Nummer im Register sagten somit nichts darüber, ob lokales Editieren aktiv war. Selbst ein erfolgreicher DO/WILL-Austausch belegte nur die Bereitschaft, über Bearbeitung und Signalzustände zu verhandeln.

MODE beschrieb den nächsten Zustand. Üblicherweise schlug der Server eine Maske vor und der Client bestätigte sie. EDIT bestimmte, wo die Zeile bearbeitet wurde. TRAPSIG bestimmte, wo Zeichen für Interrupt, Break, Abort, Dateiende oder Suspend ausgewertet wurden. MODE_ACK brachte die beiden Telnet-Prozesse über diese Maske in Übereinstimmung. Mit der folgenden Eingabe des Benutzers oder einer Anwendung hinter dem Server hatte das ACK nichts zu tun.

Deshalb sind „Linemode akzeptiert“, „EDIT aktiv“ und „entfernter Befehl abgeschlossen“ keine immer genaueren Beschreibungen desselben Ereignisses. Sie stammen aus verschiedenen Zustandsräumen und besitzen verschiedene Beweiskraft.

Eine vollständige Zeile blieb ein lokales Objekt

Mit gesetztem EDIT bearbeitete der Client die Eingabe und sandte vollständige Zeilen. RFC 1184 benannte die gewöhnliche Grenze: Nach der lokalen Bearbeitung gaben CR LF oder andere besondere Zeichen die editierten Daten frei. Bis dahin konnte der Benutzer den Puffer ändern, ohne den entfernten Host um eine Rücknahme zu bitten.

FORWARDMASK machte die Grenze beweglich. Der Server konnte verlangen, dass der Client gepufferte Eingabe bei ausgewählten ASCII-Zeichen sofort weiterleitete. SLC_FORW1 und SLC_FORW2 stellten zwei weitere Weiterleitungszeichen bereit. Konnte ein Terminaltreiber die angeforderte Menge nicht genau darstellen, durfte der Client eine größere Menge von Steuerzeichen akzeptieren und bei jedem davon weiterleiten.

Damit blieb innerhalb der Aushandlung ein lokaler Spielraum. Nicht allein das Zeilenende konnte eine Freigabe auslösen, und die Servermaske beschrieb nicht zwingend alle wirksamen Freigabepunkte. Einen unumkehrbaren lokalen Sachverhalt hielt RFC 1184 dennoch fest: Was bereits weitergeleitet war, ließ sich nicht mehr editieren.

Lokale Unumkehrbarkeit bedeutete keine entfernte Wirksamkeit. Die Bytes mussten den Client verlassen, TCP durchlaufen, den Telnet-Empfänger erreichen, von Steuerbefehlen getrennt werden, in den angeschlossenen Prozess gelangen, dessen Syntax und Richtlinien erfüllen und schließlich eine Ausgabe erzeugen. Für keine dieser späteren Beobachtungen war der lokale Editor zuständig.

Die Bestätigung einer Zeichenzuordnung bestätigte keine Wirkung

Die Suboption Set Local Characters, kurz SLC, handelte Tripel aus Funktion, Modifikatoren und zugeordnetem ASCII-Zeichen aus. Eine Stufe bezeichnete eine nicht unterstützte, fest unterstützte, ausdrücklich gesetzte oder auf den Standard zurückgesetzte Funktion. SLC_ACK sagte, dass der Empfänger der Einstellung zustimmte.

Leicht wurde daraus mehr gelesen, als darin stand. Das ACK beendete einen Konfigurationskonflikt darüber, welches lokale Zeichen eine Funktion bezeichnete. Es bewies nicht, dass der Benutzer das Zeichen eingegeben hatte. Nach einer Eingabe belegte es weder die Ankunft des zugehörigen Telnet-Befehls noch die Unterstützung oder Vollendung der Handlung im angeschlossenen System.

RFC 1184 machte diese letzte Grenze sichtbar. ABORT und IP konnten in einem System mit nur einer Unterbrechungsmöglichkeit dieselbe Wirkung haben. Nicht unterstützte Funktionen für ABORT, EOF oder SUSP durften schlicht ignoriert werden. SLC_FLUSHIN und SLC_FLUSHOUT waren Hinweise; die Benutzeroberfläche konnte das empfohlene Löschverhalten übergehen. Der Name eines Signals bezeichnete eine Bitte im Protokollzusammenhang, keine dauerhafte Aufzeichnung eines gestoppten Prozesses oder verworfener Daten.

Echo und Flusssteuerung behielten eigene Zuständigkeiten

RFC 857 erklärt, weshalb ein Zeichen auf dem Bildschirm nur schwache Evidenz für den entfernten Rechner ist. Die Echo-Option koordiniert, ob eine Seite für die andere wiederholt. Sie regelt nicht, ob ein System für sich selbst wiederholt. Linemode konnte deshalb sofort sichtbar reagieren, obwohl vom Netzweg noch keine Antwort gekommen war.

Auch die Flusssteuerung blieb trotz der thematischen Nähe getrennt. RFC 1116 und RFC 1184 nahmen FLOW nicht in die Linemode-Maske auf, sondern verwendeten die Telnet Remote Flow Control Option aus RFC 1080. Sie erlaubte nach eigener Zustimmung, die lokale Behandlung von XON/XOFF für die Terminalausgabe umzuschalten. Das war weder Tastaturbearbeitung noch Anwendungssuspendierung, TCP-Flusssteuerung oder Staukontrolle.

Diese Aufteilung verhinderte, dass ein bequemes Statusbit das gesamte Terminal zu beschreiben vorgab. Bearbeitungsort, Echoort, Sonderzeichenzuordnung, Behandlung des Ausgabeflusses und Verhalten des entfernten Prozesses hatten jeweils eigene Autoritäten.

Die fehlende Bestätigung gehörte zur Anwendung

Das IANA-Register der Telnet-Optionen weist Nummer 34 weiterhin Linemode zu und verweist auf RFC 1184. Der Registereintrag erklärt einem Parser, wie die Nummer heißt. Er beweist weder eine aktuelle Aushandlung noch Konformität einer Implementierung oder die Ausführung eines Befehls.

RFC 854 liefert das Network Virtual Terminal und die Steuerbefehle von Telnet. Darüber lassen sich Daten und Signale zum entfernten Telnet-Prozess tragen. Linemode kann den Client effizient machen und Konfigurationszustände abgleichen. Keine der Spezifikationen verwandelt Transportbelege in Anwendungsbelege.

Ein belastbarer Nachweis hält daher die Abfolge auseinander: Clientpuffer vollständig; Präfix weitergeleitet; Bytes lokal von TCP angenommen; vom Server-Telnet ausgewertet; Zeile an den entfernten Prozess übergeben; Richtlinie erfüllt; Ausführung begonnen; Ausführung beendet; Ausgabe zurückgekehrt; Ausgabe vom Benutzer der richtigen Eingabe zugeordnet. Jede Aussage braucht eine eigene Beobachtung.

Die Lehre lautet nicht, dass lokale Oberflächen täuschen. Linemode war nützlich, weil es eine lokale Tatsache schnell erfahrbar machte. Der Fehler beginnt, wenn eine Organisation diese Tatsache unter einem Feldnamen speichert, der ein entferntes Ergebnis verspricht.

Quellen