3. Remote Login - TELNET-Protokoll
3.1 EINFÜHRUNG
Telnet ist das Standard-Internet-Anwendungsprotokoll für Remote-Login. Es bietet die Kodierungsregeln, um die Tastatur/Anzeige eines Benutzers auf einem Client-System („Benutzer") mit einem Befehlsinterpreter auf einem entfernten Serversystem zu verbinden. Eine Teilmenge des Telnet-Protokolls ist auch in andere Anwendungsprotokolle eingebettet, z. B. FTP und SMTP.
Telnet verwendet eine einzelne TCP-Verbindung, und sein normaler Datenstrom (Modus „Netzwerk-Virtual-Terminal" oder „NVT") ist 7-Bit-ASCII mit Escape-Sequenzen zur Einbettung von Steuerfunktionen. Telnet ermöglicht auch die Aushandlung vieler optionaler Modi und Funktionen.
Die primäre Telnet-Spezifikation befindet sich in RFC-854 [TELNET:1], während die Optionen in vielen anderen RFCs definiert sind; siehe Abschnitt 7 für Referenzen.
3.2 PROTOKOLL-DURCHGANG
3.2.1 Optionsaushandlung: RFC-854, S. 2-3
Jede Telnet-Implementierung muss (MUST) Mechanismen zur Optionsaushandlung und Unteraushandlung enthalten [TELNET:2].
Ein Host muss (MUST) die Regeln von RFC-854 sorgfältig befolgen, um Schleifen bei der Optionsaushandlung zu vermeiden. Ein Host muss (MUST) eine nicht unterstützte Option ablehnen (d. h. mit WONT/DONT auf DO/WILL antworten). Die Optionsaushandlung sollte (SHOULD) während der gesamten Lebensdauer einer Telnet-Verbindung weiterhin funktionieren (auch wenn alle Anfragen abgelehnt werden).
Wenn alle Optionsaushandlungen fehlschlagen, muss (MUST) eine Telnet-Implementierung standardmäßig ein NVT sein und es unterstützen.
DISKUSSION:
Auch wenn anspruchsvollere „Terminals" und unterstützende Optionsaushandlungen zur Norm werden, müssen alle Implementierungen darauf vorbereitet sein, ein NVT für jede Benutzer-Server-Kommunikation zu unterstützen.
3.2.2 Telnet Go-Ahead-Funktion: RFC-854, S. 5, und RFC-858
Auf einem Host, der niemals den Telnet-Befehl Go Ahead (GA) sendet, muss (MUST) der Telnet-Server versuchen, die Option Suppress Go Ahead auszuhandeln (d. h. „WILL Suppress Go Ahead" senden). Ein Benutzer- oder Server-Telnet muss (MUST) immer die Aushandlung der Option Suppress Go Ahead akzeptieren.
Wenn es ein Vollduplex-Terminal steuert, für das GA keine Bedeutung hat, kann (MAY) eine Benutzer-Telnet-Implementierung GA-Befehle ignorieren.
DISKUSSION:
Halbduplex-Terminals („gesperrte Tastatur") mit zeilenweiser Eingabe, für die der Go-Ahead-Mechanismus entwickelt wurde, sind weitgehend von der Bildfläche verschwunden. Es hat sich herausgestellt, dass es schwierig ist, das Senden des Go-Ahead-Signals in vielen Betriebssystemen zu implementieren, selbst in einigen Systemen, die native Halbduplex-Terminals unterstützen. Die Schwierigkeit besteht typischerweise darin, dass der Telnet-Servercode keinen Zugriff auf Informationen darüber hat, ob der Benutzerprozess blockiert und auf Eingaben von der Telnet-Verbindung wartet, d. h. er kann nicht zuverlässig bestimmen, wann ein GA-Befehl gesendet werden soll. Daher senden die meisten Telnet-Server-Hosts keine GA-Befehle.
Die Wirkung der Regeln in diesem Abschnitt besteht darin, dass jedes Ende einer Telnet-Verbindung die Verwendung von GA-Befehlen ablehnen kann.
Es gibt eine Klasse von Halbduplex-Terminals, die noch kommerziell wichtig ist: „Dateneingabeterminals", die auf Vollbild-Weise interagieren. Die Unterstützung von Dateneingabeterminals mit dem Telnet-Protokoll erfordert jedoch nicht das Go-Ahead-Signal; siehe Abschnitt 3.3.2.
3.2.3 Steuerfunktionen: RFC-854, S. 7-8
Die Liste der Telnet-Befehle wurde um EOR (End-of-Record) mit Code 239 erweitert [TELNET:9].
Sowohl Benutzer- als auch Server-Telnets können (MAY) die Steuerfunktionen EOR, EC, EL und Break unterstützen und müssen (MUST) AO, AYT, DM, IP, NOP, SB und SE unterstützen.
Ein Host muss (MUST) in der Lage sein, alle Telnet-Steuerfunktionen, die er nicht unterstützt, zu empfangen und zu ignorieren.
DISKUSSION:
Beachten Sie, dass ein Server-Telnet die Telnet-IP-Funktion (Interrupt Process) unterstützen muss, auch wenn der Server-Host eine entsprechende In-Stream-Funktion hat (z. B. Control-C in vielen Systemen). Die Telnet-IP-Funktion kann stärker sein als ein In-Stream-Interrupt-Befehl, wegen des Out-of-Band-Effekts von TCP-Urgent-Daten.
Die EOR-Steuerfunktion kann verwendet werden, um den Stream zu begrenzen. Eine wichtige Anwendung ist die Unterstützung von Dateneingabeterminals (siehe Abschnitt 3.3.2). Es gab Bedenken, dass ein Host, der nicht darauf vorbereitet war, unbekannte Telnet-Befehle korrekt zu ignorieren, abstürzen könnte, wenn er ein EOR erhielt, da EOR nicht in RFC-854 definiert worden war. Um solche Hosts zu schützen, wurde die End-of-Record-Option [TELNET:9] eingeführt; ein ordnungsgemäß implementiertes Telnet-Programm benötigt diesen Schutz jedoch nicht.
3.2.4 Telnet "Synch"-Signal: RFC-854, S. 8-10
Wenn es „dringende" TCP-Daten empfängt, muss (MUST) ein Benutzer- oder Server-Telnet alle Daten außer Telnet-Befehlen verwerfen, bis das DM (und das Ende der Dringlichkeit) erreicht ist.
Wenn es Telnet IP (Interrupt Process) sendet, sollte (SHOULD) ein Benutzer-Telnet diesem die Telnet-„Synch"-Sequenz folgen lassen, d. h. als TCP-Urgent-Daten die Sequenz „IAC IP IAC DM" senden. Der TCP-Urgent-Zeiger zeigt auf das DM-Oktett.
Wenn es einen Telnet-IP-Befehl empfängt, kann (MAY) ein Server-Telnet eine Telnet-„Synch"-Sequenz an den Benutzer zurücksenden, um den Ausgabestream zu leeren. Die Wahl sollte konsistent mit der Art und Weise sein, wie sich das Server-Betriebssystem verhält, wenn ein lokaler Benutzer einen Prozess unterbricht.
Wenn es einen Telnet-AO-Befehl empfängt, muss (MUST) ein Server-Telnet eine Telnet-„Synch"-Sequenz an den Benutzer zurücksenden, um den Ausgabestream zu leeren.
Ein Benutzer-Telnet sollte (SHOULD) die Fähigkeit haben, die Ausgabe zu leeren, wenn es ein Telnet-IP sendet; siehe auch Abschnitt 3.4.5.
DISKUSSION:
Es gibt drei mögliche Wege für ein Benutzer-Telnet, den Stream der Server-Ausgabedaten zu leeren:
(1) AO nach IP senden.
Dies veranlasst den Server-Host, ein „gepufferte-Ausgabe-leeren"-Signal an sein Betriebssystem zu senden. Das AO wird jedoch möglicherweise nicht lokal wirksam, d. h. die Terminalausgabe auf der Benutzer-Telnet-Seite wird nicht gestoppt, bis der Server-Telnet das AO empfangen und verarbeitet hat und ein „Synch" zurückgesendet hat.
(2) DO TIMING-MARK [TELNET:7] nach IP senden und alle Ausgaben lokal verwerfen, bis ein WILL/WONT TIMING-MARK vom Server-Telnet empfangen wird.
Da das DO TIMING-MARK nach dem IP am Server verarbeitet wird, sollte die Antwort darauf an der richtigen Stelle im Ausgabedatenstrom sein. Das TIMING-MARK sendet jedoch kein „gepufferte-Ausgabe-leeren"-Signal an das Server-Betriebssystem. Ob dies erforderlich ist oder nicht, hängt vom Serversystem ab.
(3) Beides tun.
Die beste Methode ist nicht ganz klar, da sie einer Reihe existierender Server-Hosts gerecht werden muss, die die Telnet-Standards auf verschiedene Weise nicht befolgen. Der sicherste Ansatz ist wahrscheinlich, eine vom Benutzer steuerbare Option bereitzustellen, um (1), (2) oder (3) auszuwählen.
3.2.5 NVT-Drucker und Tastatur: RFC-854, S. 11
Im NVT-Modus sollte (SHOULD NOT) ein Telnet keine Zeichen mit dem höchstwertigen Bit 1 senden und darf (MUST NOT) es nicht als Paritätsbit senden. Implementierungen, die das höchstwertige Bit an Anwendungen weitergeben, sollten (SHOULD) den Binärmodus aushandeln (siehe Abschnitt 3.2.6).
DISKUSSION:
Implementierer sollten sich bewusst sein, dass eine strenge Lesart von RFC-854 es einem Client oder Server, der NVT ASCII erwartet, erlaubt, Zeichen mit gesetztem höchstwertigen Bit zu ignorieren. Im Allgemeinen wird erwartet, dass der Binärmodus für die Übertragung eines erweiterten (über 7-Bit hinausgehenden) Zeichensatzes mit Telnet verwendet wird.
Es gibt jedoch Anwendungen, die tatsächlich einen 8-Bit-NVT-Modus benötigen, der derzeit nicht definiert ist, und diese bestehenden Anwendungen setzen das höchstwertige Bit während eines Teils oder der gesamten Lebensdauer der Telnet-Verbindung. Man beachte, dass der Binärmodus nicht dasselbe ist wie ein 8-Bit-NVT-Modus, da der Binärmodus die Zeilenende-Verarbeitung abschaltet. Aus diesem Grund sind die Anforderungen an das höchstwertige Bit mit SHOULD und nicht mit MUST formuliert.
RFC-854 definiert einen minimalen Satz von Eigenschaften eines „Network Virtual Terminal" oder NVT; dies soll zusätzliche Merkmale realer Terminals nicht ausschließen. Eine Telnet-Verbindung ist für alle 7-Bit-ASCII-Zeichen vollständig transparent, einschließlich beliebiger ASCII-Steuerzeichen.
Beispielsweise könnte ein Terminal Vollbildbefehle unterstützen, die als ASCII-Escape-Sequenzen kodiert sind; eine Telnet-Implementierung würde diese Sequenzen als uninterpretierte Daten weiterreichen. Ein NVT sollte daher nicht als Terminaltyp eines stark eingeschränkten Geräts verstanden werden.
3.2.6 Telnet-Befehlsstruktur: RFC-854, S. 13
Da Optionen an jedem Punkt im Datenstrom erscheinen können, muss (MUST) ein Telnet-Escape-Zeichen (bekannt als IAC mit dem Wert 255), das als Daten gesendet werden soll, verdoppelt werden.
3.2.7 Telnet-Binäroption: RFC-856
Wenn die Binäroption erfolgreich ausgehandelt wurde, sind beliebige 8-Bit-Zeichen erlaubt. Der Datenstrom muss (MUST) jedoch weiterhin nach IAC-Zeichen gescannt werden, alle eingebetteten Telnet-Befehle müssen (MUST) befolgt werden, und Datenbytes, die IAC entsprechen, müssen (MUST) verdoppelt werden. Andere Zeichenverarbeitung (z. B. Ersetzen von CR durch CR NUL oder durch CR LF) darf (MUST NOT) nicht durchgeführt werden. Insbesondere gibt es im Binärmodus keine Zeilenende-Konvention (siehe Abschnitt 3.3.1).
DISKUSSION:
Die Binäroption wird normalerweise in beiden Richtungen ausgehandelt, um die Telnet-Verbindung vom NVT-Modus in den „Binärmodus" zu überführen.
Die Sequenz IAC EOR kann verwendet werden, um Datenblöcke innerhalb eines Telnet-Stroms im Binärmodus abzugrenzen.
3.2.8 Telnet Terminal-Type-Option: RFC-1091
Die Terminal-Type-Option muss (MUST) die Terminaltyp-Namen verwenden, die offiziell im RFC für zugewiesene Nummern [INTRO:5] definiert sind, wenn sie für das jeweilige Terminal verfügbar sind. Der Empfänger einer Terminal-Type-Option muss (MUST) jedoch jeden Namen akzeptieren.
DISKUSSION:
RFC-1091 [TELNET:10] aktualisiert eine frühere Version der in RFC-930 definierten Terminal-Type-Option. Die frühere Version erlaubte es einem Server-Host, der mehrere Terminaltypen unterstützen konnte, den Typ des jeweiligen Client-Terminals zu erfahren, unter der Annahme, dass jedes physische Terminal einen inhärenten Typ besitzt. Heute ist ein „Terminal" jedoch häufig in Wirklichkeit ein Terminal-Emulationsprogramm, das in einem PC läuft und möglicherweise eine ganze Reihe von Terminaltypen emulieren kann. Daher erweitert RFC-1091 die Spezifikation, um eine allgemeinere Aushandlung des Terminaltyps zwischen Benutzer-Telnet und Server-Telnet zu ermöglichen.
3.3 SPEZIFISCHE PROBLEME
3.3.1 Telnet-Zeilenende-Konvention
Das Telnet-Protokoll definiert die Sequenz CR LF als „Zeilenende". Für Terminaleingaben entspricht dies einer Befehlsvollständigkeits- oder „Zeilenende"-Taste, die auf einem Benutzerterminal gedrückt wird; auf einem ASCII-Terminal ist dies die CR-Taste, kann aber auch als „Return" oder „Enter" bezeichnet werden.
Wenn ein Server-Telnet die Telnet-Zeilenende-Sequenz CR LF als Eingabe von einem entfernten Terminal empfängt, muss (MUST) der Effekt derselbe sein, als ob der Benutzer die „Zeilenende"-Taste auf einem lokalen Terminal gedrückt hätte. Auf Server-Hosts, die ASCII verwenden, muss insbesondere der Empfang der Telnet-Sequenz CR LF den gleichen Effekt verursachen wie ein lokaler Benutzer, der die CR-Taste auf einem lokalen Terminal drückt. Daher müssen (MUST) CR LF und CR NUL auf einem ASCII-Server-Host den gleichen Effekt haben, wenn sie als Eingabe über eine Telnet-Verbindung empfangen werden.
Ein Benutzer-Telnet muss (MUST) in der Lage sein, eine der Formen zu senden: CR LF, CR NUL und LF. Ein Benutzer-Telnet auf einem ASCII-Host sollte (SHOULD) einen vom Benutzer steuerbaren Modus haben, um entweder CR LF oder CR NUL zu senden, wenn der Benutzer die „Zeilenende"-Taste drückt, und CR LF sollte (SHOULD) der Standard sein.
Die Telnet-Zeilenende-Sequenz CR LF muss (MUST) verwendet werden, um Telnet-Daten zu senden, die nicht von einem Terminal zu einem Rechner übertragen werden (zum Beispiel, wenn ein Server-Telnet Ausgaben sendet oder wenn das Telnet-Protokoll in ein anderes Anwendungsprotokoll eingebettet ist).
DISKUSSION:
Um die Interoperabilität beliebiger Telnet-Clients und -Server zu ermöglichen, hat das Telnet-Protokoll eine Standarddarstellung für den Zeilenabschluss definiert. Da der ASCII-Zeichensatz kein explizites Zeilenende-Zeichen enthält, haben verschiedene Systeme unterschiedliche Darstellungen gewählt, zum Beispiel CR, LF und die Sequenz CR LF. Das Telnet-Protokoll hat die Sequenz CR LF als Standard für die Netzwerkübertragung gewählt.
Leider hat sich die Spezifikation des Telnet-Protokolls in RFC-854 [TELNET:1] als etwas mehrdeutig darin erwiesen, welches Zeichen ein Client an den Server senden soll, um die „Zeilenende"-Taste darzustellen. Das Ergebnis war ein erhebliches und anhaltendes Interoperabilitätsproblem, das durch verschiedene fehlerhafte Implementierungen von Benutzer- und Server-Telnet noch verschärft wurde.
Obwohl das Telnet-Protokoll auf einem vollkommen symmetrischen Modell beruht, unterscheidet sich in einer Remote-Login-Sitzung die Rolle des Benutzers am Terminal von der Rolle des Server-Hosts. Beispielsweise definiert RFC-854 die Bedeutung von CR, LF und CR LF als Serverausgabe, legt jedoch nicht fest, was ein Benutzer-Telnet senden soll, wenn der Benutzer die „Zeilenende"-Taste am Terminal drückt; genau dies ist der strittige Punkt.
Wenn der Benutzer die „Zeilenende"-Taste drückt, senden einige Benutzer-Telnet-Implementierungen CR LF, während andere CR NUL senden (basierend auf einer abweichenden Lesart desselben Satzes in RFC-854). Wie oben ausgeführt, sind diese beiden Formen für einen korrekt implementierten ASCII-Server-Host gleichwertig. Für andere Server wird ein entsprechender Modus im Benutzer-Telnet benötigt.
Die Existenz von Benutzer-Telnets, die beim Drücken von CR ausschließlich CR NUL senden, stellt Nicht-ASCII-Hosts vor ein Dilemma: Entweder behandeln sie CR NUL in der Eingabe als gleichwertig zu CR LF und schließen damit die Möglichkeit aus, ein „nacktes" CR einzugeben, oder sie verlieren die Interoperabilität vollständig.
Angenommen, ein Benutzer auf Host A meldet sich per Telnet am Server-Host B an und führt dort das Benutzer-Telnet-Programm von B aus, um sich am Server-Host C anzumelden. Idealerweise sollte die Server-/Benutzer-Telnet-Kombination auf B so transparent wie möglich sein, das heißt sich so verhalten, als wäre A direkt mit C verbunden. Insbesondere würde eine korrekte Implementierung B für Telnet-Zeilenende-Sequenzen transparent machen, mit der Ausnahme, dass CR LF in CR NUL umgewandelt werden kann und umgekehrt.
IMPLEMENTIERUNG:
Um das Telnet-Zeilenende-Problem zu verstehen, benötigt man zumindest ein grobes Modell der Beziehung zwischen Telnet und dem lokalen Betriebssystem. Der Server-Telnet-Prozess ist typischerweise als Pseudoterminal an die Terminaltreiber-Software des Betriebssystems gekoppelt. Eine vom Server-Telnet empfangene Telnet-Zeilenende-Sequenz muss denselben Effekt haben wie das Drücken der Zeilenende-Taste an einem tatsächlich lokal angeschlossenen Terminal.
Betriebssysteme, die interaktive zeichenweise arbeitende Anwendungen (zum Beispiel Editoren) unterstützen, stellen für ihre Terminal-E/A in der Regel zwei interne Modi bereit: einen formatierten Modus, in dem lokale Konventionen für Zeilenenden und andere Formatierungsregeln auf den Datenstrom angewendet wurden, und einen „Raw"-Modus, in dem die Anwendung direkten Zugriff auf jedes eingegebene Zeichen hat. Ein Server-Telnet muss so implementiert werden, dass diese Modi für das entfernte Terminal dieselbe Wirkung haben wie für ein lokales Terminal. Empfängt beispielsweise ein Server-Telnet auf einem ASCII-Host CR LF oder CR NUL, so wird im Raw-Modus das CR-Zeichen an die Anwendung weitergegeben, während im formatierten Modus die Zeilenende-Konvention des lokalen Systems verwendet wird.
3.3.2 Dateneingabeterminals
DISKUSSION:
Zusätzlich zu den zeilenorientierten und zeichenorientierten ASCII-Terminals, für die Telnet entwickelt wurde, gibt es mehrere Familien von Videoanzeige-Terminals, die manchmal als „Dateneingabeterminals" oder DETs bekannt sind. Die IBM 3270-Familie ist ein bekanntes Beispiel.
Es wurden zwei Internetprotokolle entworfen, um generische DETs zu unterstützen: SUPDUP [TELNET:16, TELNET:17] und die DET-Option [TELNET:18, TELNET:19]. Die DET-Option nutzt (Sub-)Aushandlung, um ein Dateneingabeterminal über eine Telnet-Verbindung zu betreiben. SUPDUP ist ein vollständig eigenständiges Terminalprotokoll, in das von Telnet aus durch Aushandlung gewechselt werden kann. Obwohl sowohl SUPDUP als auch die DET-Option in bestimmten Umgebungen erfolgreich eingesetzt wurden, hat keines von beiden allgemeine Akzeptanz oder weite Verbreitung gefunden.
Für die Unterstützung der IBM 3270-Familie über Telnet hat sich ein anderer Ansatz der DET-Interaktion entwickelt, wobei dieselbe Methode auf jedes DET anwendbar ist. Die Idee besteht darin, in einen „nativen DET"-Modus zu wechseln, in dem der native DET-Ein-/Ausgabestrom als Binärdaten gesendet wird. Der Telnet-Befehl EOR wird verwendet, um logische Datensätze (zum Beispiel „Bildschirme") innerhalb dieses Binärstroms abzugrenzen.
IMPLEMENTIERUNG:
Die Regeln für das Betreten und Verlassen des nativen DET-Modus lauten:
o Der Server erfährt über die Terminal-Type-Option [TELNET:10], dass der Client ein DET ist.
o Üblicherweise (aber nicht zwingend) handeln beide Seiten die EOR-Option [TELNET:9] aus.
o Beide Seiten handeln die Binäroption [TELNET:3] aus, um in den nativen DET-Modus zu wechseln.
o Wenn eine Seite das Verlassen des Binärmodus aushandelt, folgt die andere Seite, und der Modus kehrt zum normalen NVT zurück.
3.3.3 Optionsanforderungen
Jede Telnet-Implementierung muss (MUST) die Binäroption [TELNET:3] und die Suppress Go Ahead-Option [TELNET:5] unterstützen und sollte (SHOULD) die Echo- [TELNET:4], Status- [TELNET:6], End-of-Record- [TELNET:9] und Extended Options List-Optionen [TELNET:8] unterstützen.
Ein Benutzer- oder Server-Telnet sollte (SHOULD) die Window Size-Option [TELNET:12] unterstützen, wenn das lokale Betriebssystem die entsprechende Fähigkeit bereitstellt.
DISKUSSION:
Man beachte, dass die End-of-Record-Option lediglich anzeigt, dass ein Telnet ein Telnet EOR empfangen kann, ohne abzustürzen; daher sollte jedes Telnet bereit sein, die Aushandlung der End-of-Record-Option zu akzeptieren. Siehe auch die Diskussion in Abschnitt 3.2.3.
3.3.4 Optionsinitiierung
Wenn das Telnet-Protokoll in einer Client/Server-Situation verwendet wird, sollte (SHOULD) der Server die Aushandlung des erwarteten Terminalinteraktionsmodus initiieren.
DISKUSSION:
Das Telnet-Protokoll ist vollkommen symmetrisch definiert, seine Anwendung ist jedoch in der Regel asymmetrisch. Es sind Fälle bekannt, in denen Remote-Logins fehlschlugen, weil keine der beiden Seiten die Aushandlung des benötigten, vom Standard abweichenden Terminalmodus initiierte. Im Allgemeinen bestimmt der Server den bevorzugten Modus, daher muss der Server die Aushandlung initiieren. Da die Aushandlung symmetrisch ist, kann sie auch vom Benutzer initiiert werden.
Der Client (Benutzer-Telnet) sollte (SHOULD) dem Benutzer eine Möglichkeit bieten, die Initiierung der Optionsaushandlung zu aktivieren und zu deaktivieren.
DISKUSSION:
Ein Benutzer muss sich mitunter mit einem Anwendungsdienst (zum Beispiel FTP oder SMTP) verbinden, der Telnet für seinen Steuerstrom verwendet, aber keine Telnet-Optionen unterstützt. Lässt sich die Initiierung der Optionsaushandlung deaktivieren, kann das Benutzer-Telnet für diesen Zweck eingesetzt werden.
3.3.5 Telnet Linemode-Option
DISKUSSION:
Eine wichtige neue Telnet-Option, LINEMODE [TELNET:12], wurde vorgeschlagen. Die LINEMODE-Option bietet eine Standardmethode für ein Benutzer-Telnet und ein Server-Telnet, sich darauf zu einigen, dass der Client und nicht der Server die Terminal-Zeichenverarbeitung durchführt. Sobald der Client eine vollständige Textzeile zusammengestellt hat, sendet er diese Zeile (normalerweise) in einem einzigen TCP-Segment an den Server. Diese Option wird den Paket-Overhead von Telnet-Sitzungen erheblich verringern und dem Benutzer in überlasteten Netzwerken oder Netzwerken mit langer Verzögerung eine deutlich bessere Reaktionszeit bieten.
Die LINEMODE-Option erlaubt das dynamische Umschalten zwischen lokaler und entfernter Zeichenverarbeitung. Beispielsweise handelt die Telnet-Verbindung während der Ausführung eines Vollbildeditors automatisch den Wechsel in den zeichenweisen Modus aus und kehrt nach Beendigung des Editors in den Linemode zurück.
Wir erwarten, dass Hosts zum Zeitpunkt der Veröffentlichung dieses RFC die Client-Seite dieser Option implementieren sollten und die Server-Seite implementieren können. Um die Server-Seite korrekt zu implementieren, muss der Server in der Lage sein, dem lokalen System mitzuteilen, dass es keinerlei Verarbeitung der Eingabezeichen vornehmen soll, stattdessen den aktuellen Terminalzustand zu speichern und den Server-Telnet-Prozess zu benachrichtigen, wenn sich dieser Zustand ändert. Dadurch werden beispielsweise das Echo von Passwörtern und Vollbildeditoren korrekt behandelt.
3.4 TELNET/BENUTZER-SCHNITTSTELLE
3.4.1 Zeichensatz-Transparenz
Benutzer-Telnet-Implementierungen sollten (SHOULD) in der Lage sein, jedes 7-Bit-ASCII-Zeichen zu senden oder zu empfangen. Wo möglich, sollten (SHOULD) alle speziellen Zeicheninterpretationen durch das Betriebssystem des Benutzer-Hosts umgangen werden, damit diese Zeichen bequem über die Verbindung gesendet und empfangen werden können.
Ein Zeichenwert muss (MUST) als „Escape zum Befehlsmodus" reserviert werden; konventionell ermöglicht das Verdoppeln dieses Zeichens, es als Daten einzugeben. Das verwendete spezifische Zeichen sollte (SHOULD) vom Benutzer auswählbar sein.
Auf einer Verbindung im Binärmodus darf (MAY) ein Benutzer-Telnet-Programm einen Escape-Mechanismus zur Eingabe beliebiger 8-Bit-Werte bereitstellen, falls das Betriebssystem des Hosts deren direkte Eingabe über die Tastatur nicht zulässt.
IMPLEMENTIERUNG:
Die Transparenzfrage ist auf dem Server weniger dringlich, Implementierer sollten jedoch auf die Behandlung folgender Punkte achten: das Ausblenden des Paritätsbits (das von älteren, nicht konformen Clients gesendet wird), bevor die Daten ein Programm erreichen, das ausschließlich NVT ASCII erwartet, sowie die korrekte Behandlung von Programmen, die einen 8-Bit-Datenstrom anfordern.
3.4.2 Telnet-Befehle
Ein Benutzer-Telnet-Programm muss (MUST) dem Benutzer die Möglichkeit bieten, eine der Telnet-Steuerfunktionen IP, AO oder AYT einzugeben, und sollte (SHOULD) die Möglichkeit bieten, EC, EL und Break einzugeben.
3.4.3 TCP-Verbindungsfehler
Ein Benutzer-Telnet-Programm sollte (SHOULD) dem Benutzer alle TCP-Fehler melden, die von der Transportschicht gemeldet werden (siehe den Abschnitt „TCP/Anwendungsschicht-Schnittstelle" in [INTRO:1]).
3.4.4 Nicht-Standard-Telnet-Kontaktport
Ein Benutzer-Telnet-Programm sollte (SHOULD) dem Benutzer erlauben, optional eine nicht standardmäßige Kontaktportnummer am Server-Telnet-Host anzugeben.
3.4.5 Ausgabe leeren
Ein Benutzer-Telnet-Programm sollte (SHOULD) dem Benutzer die Möglichkeit geben, anzugeben, ob die Ausgabe geleert werden soll oder nicht, wenn ein IP gesendet wird; siehe Abschnitt 3.2.4.
Bei jedem Verfahren zum Leeren der Ausgabe, das dazu führt, dass das Benutzer-Telnet die Ausgabe lokal verwirft, bis ein Telnet-Signal vom Server empfangen wird, sollte (SHOULD) dem Benutzer eine Möglichkeit geboten werden, die normale Ausgabe manuell wiederherzustellen, falls der Server das erwartete Signal nicht sendet.
3.5 ZUSAMMENFASSUNG DER TELNET-ANFORDERUNGEN
| Funktionalität | Abschnitt | MUST | SHOULD | MAY | SHOULD NOT | MUST NOT |
|---|---|---|---|---|---|---|
| Optionsaushandlung | ||||||
| Optionsaushandlung implementieren | 3.2.1 | ✓ | ||||
| Aushandlungsschleifen vermeiden | 3.2.1 | ✓ | ||||
| Nicht unterstützte Optionen ablehnen | 3.2.1 | ✓ | ||||
| Aushandlung jederzeit OK | 3.2.1 | ✓ | ||||
| Standard auf NVT | 3.2.1 | ✓ | ||||
| Offiziellen Namen in Term-Type senden | 3.2.8 | ✓ | ||||
| Jeden Namen in Term-Type akzeptieren | 3.2.8 | ✓ | ||||
| Binary, Suppress-GA implementieren | 3.3.3 | ✓ | ||||
| Echo, Status, EOL, Ext-Opt-List-Optionen | 3.3.3 | ✓ | ||||
| Window-Size-Option falls geeignet | 3.3.3 | ✓ | ||||
| Server initiiert Modus-Aushandlungen | 3.3.4 | ✓ | ||||
| Steuerfunktionen | ||||||
| SE NOP DM IP AO AYT SB unterstützen | 3.2.3 | ✓ | ||||
| EOR EC EL Break unterstützen | 3.2.3 | ✓ | ||||
| Nicht unterstützte Funktionen ignorieren | 3.2.3 | ✓ | ||||
| Dringende Daten bis DM verwerfen | 3.2.4 | ✓ | ||||
| Kodierung | ||||||
| Höchstwertiges Bit im NVT nicht senden | 3.2.5 | ✓ | ||||
| Höchstwertiges Bit nicht als Parität senden | 3.2.5 | ✓ | ||||
| IAC-Byte immer verdoppeln | 3.2.6 | ✓ | ||||
| IAC im Binärmodus verdoppeln | 3.2.7 | ✓ | ||||
| Zeilenende | ||||||
| EOL am Server = lokales Zeilenende | 3.3.1 | ✓ | ||||
| ASCII-Server akzeptiert CR LF oder CR NUL | 3.3.1 | ✓ | ||||
| Benutzer kann CR LF, CR NUL, LF senden | 3.3.1 | ✓ | ||||
| ASCII-Benutzer kann CR LF/CR NUL wählen | 3.3.1 | ✓ | ||||
| Standard-Modus Benutzer ist CR LF | 3.3.1 | ✓ | ||||
| Benutzer-Telnet-Schnittstelle | ||||||
| E/A aller 7-Bit-Zeichen | 3.4.1 | ✓ | ||||
| Lokale OS-Interpretation umgehen | 3.4.1 | ✓ | ||||
| Escape-Zeichen | 3.4.1 | ✓ | ||||
| Vom Benutzer einstellbares Escape-Zeichen | 3.4.1 | ✓ | ||||
| Kann IP, AO, AYT eingeben | 3.4.2 | ✓ | ||||
| Kann EC, EL, Break eingeben | 3.4.2 | ✓ | ||||
| TCP-Fehler an Benutzer melden | 3.4.3 | ✓ | ||||
| Nicht standardmäßiger Kontaktport | 3.4.4 | ✓ | ||||
| Ausgabe-Leeren bei IP-Sendung angeben | 3.4.5 | ✓ | ||||
| Ausgabemodus manuell wiederherstellen | 3.4.5 | ✓ |