Zusammenfassung

  • RFC 854 machte das Terminalverhalten verhandelbar: Jedes Ende konnte eine Option anfordern, das andere durfte sie annehmen oder ablehnen.
  • Das Network Virtual Terminal blieb die gemeinsame Rückfallebene; unterschiedliche Fähigkeiten mussten den gemeinsamen Ausgangspunkt nicht auflösen.

Analyse

Eine Fernsitzung verbindet Rechner mit unterschiedlichen Tastaturen, Bildschirmen und Erwartungen an die Bedienung. Das Netz transportiert Bytes, gleicht diese lokalen Geräte aber nicht an. TELNET setzte deshalb einen gemeinsamen Ausgangspunkt und erlaubte den Enden, Abweichungen auszuhandeln.

Die dauerhafte Form erhielt das Verfahren im Mai 1983. Jon Postel und Joyce Reynolds veröffentlichten RFC 854 als Ersatz für RFC 764. TELNET wurde darin als bidirektionale, auf Acht-Bit-Bytes ausgerichtete Verbindung zwischen dem Terminalsystem eines Nutzers und einem entfernten Server beschrieben. Im Mittelpunkt stand das Network Virtual Terminal (NVT): gemeinsame Konventionen, mit denen unterschiedliche Hosts eine einfache Sitzung beginnen konnten, bevor sie speziellere Funktionen vereinbarten.

NVT war eine Untergrenze, keine Behauptung gleicher Terminals. Nach RFC 854 durfte jede Seite eine Option anfordern. Vier Befehle machten die Zuständigkeit sichtbar: DO verlangte vom Gegenüber, eine Option auszuführen; WILL sagte zu, dass der Absender sie ausführen werde. DONT und WONT nahmen diese Positionen zurück. Wurde eine Anfrage abgelehnt, blieb der betreffende Teil der Sitzung bei der NVT-Konvention. Ein Host konnte Nein sagen, ohne die Verbindung zu beenden.

Das war wichtig, weil Optionen keine globalen Schalter waren. Für jede Übertragungsrichtung konnte ein eigener Zustand gelten. Eine Seite konnte Echo akzeptieren, die andere ablehnen; eine konnte binäre Übertragung anfordern, während ihr Gegenüber beim Standard blieb. RFC 856 zur Binärübertragung, RFC 857 zur Echo-Option und RFC 858 zu Suppress Go Ahead zeigen kleine Erweiterungen rund um einen gemeinsamen Datenstrom. RFC 855 verlangte Angaben zu Befehlen, Standardwerten und Motivation und ließ Hosts Optionen entwickeln, testen oder verwerfen. RFC 880 führte TELNET-Optionen als wahlweise zu nutzende Funktionen.

Die symmetrische Aushandlung schuf Flexibilität und ein Risiko: Beide Seiten konnten eine Bestätigung als neue Anfrage missverstehen und dadurch eine Endlosschleife auslösen. RFC 854 regelte das auf Protokollebene. Ein Host sollte nur eine Zustandsänderung anfordern, nicht seinen aktuellen Modus verkünden; eine Anfrage für einen bereits aktiven Modus brauchte keine weitere Bestätigung. Gleichzeitige Anfragen konnten einander bestätigen. Das Abschalten einer Option durfte nicht verweigert werden, weil beide Seiten NVT unterstützen mussten.

So blieb die Kontrolle verteilt. Der Standard legte das gemeinsame Byte-Vokabular und die Rückfallebene fest. Jede Implementierung entschied selbst, ob sie eine optionale Funktion anbieten konnte. Interoperabilität entstand aus der ausgehandelten Schnittmenge, nicht aus der Annahme, jedes Gerät beherrsche jede Funktion.

Spätere Dokumente begrenzen die Erfolgserzählung. RFC 1123 verlangte 1989 Verhandlungsmechanismen, die Ablehnung nicht unterstützter Optionen, fortgesetzte Aushandlung während der Verbindung und NVT-Unterstützung, falls alle Verhandlungen scheiterten. Zugleich hielt der RFC anhaltende Mehrdeutigkeiten fest, darunter beim Zeilenende. RFC 1143 beschrieb 1990 eine systematischere Methode zur Verwaltung des Aushandlungszustands. Rückfallebene und Schleifenregeln halfen, beseitigten aber weder Implementierungsunterschiede noch alle Inkompatibilitäten zwischen Terminals.

Der historische Beitrag von RFC 854 war genauer als „ein Protokoll machte alle Terminals kompatibel“. Es gab unterschiedlichen Systemen ein geregeltes Verfahren, um herauszufinden, was sie gemeinsam leisten konnten. Die Basis machte Ablehnung verkraftbar, die Aushandlung ermöglichte Erweiterungen, und ihre Grenze blieb im Datenstrom erkennbar.

Quellen