3. Vorgeschlagene Telnet-Konventionen
3A.
Der Server-Standort soll anfänglich davon ausgehen, dass das Echo von einem Prozess des Benutzer-Standorts ausgeführt wird, bis ausdrücklich etwas anderes angewiesen wird. Kann der Benutzer-Standort zeichenweise senden, so kann der Benutzer nach dem Aufbau von Verbindung und Anmeldung durch einen Befehl an den Server-Standort auf die Echo-Ausgabe durch den Server-Standort (server-site-echo) umschalten und anschließend (für den Server-Standort unsichtbar) seinem lokalen Telnet befehlen, ebenfalls seinen Echo-Modus zu ändern.
3B.
Der Server-Prozess soll davon ausgehen, dass er denselben Zeichensatz empfängt, den die „direkt" an ihn angeschlossenen Terminals erzeugen können. (Wir empfehlen mindestens 128 Zeichen ASCII.) Das Telnet des Benutzers muss möglicherweise Zwei-Zeichen-Folgen erkennen, um sowohl die Erzeugung von Groß- und Kleinschreibungscodes als auch der Steuercodes zu ermöglichen. Wir empfehlen, dass der Benutzer bei Ein-Case-Terminals entweder Groß- oder Kleinschreibung als Standardfall einstellen und ein Umschaltzeichen (case shift character) festlegen kann. Der Benutzer sollte außerdem ein Zeichen festlegen können, das anzeigt, dass das unmittelbar danach angeschlagene Zeichen in den entsprechenden Steuerzeichencode umzuwandeln ist. Letztere Konvention ermöglicht es, dass direkt am Terminal erzeugte Steuercodes vom System des Benutzers erkannt werden und somit ein Escape zum Benutzersystem möglich wird. Eine Konvention zu schaffen, die es allen Steuercodes erlaubt, in das Netz zu gelangen, und die Ausgabe des Netzes vor dem Eintritt in den Server-Prozess in den Server-Monitor einspeisen zu lassen, bietet einen einfachen Mechanismus, um ein Escape zu vielen bestehenden Systemen zu erzeugen. (Bei manchen Systemen ist das Problem komplizierter als dies, und wir besprechen es weiter unten.)
3C.
Wir empfehlen, dass Netzstandards für die Bedeutung der lokalen Echos von HT, VT und FF festgelegt werden, oder dass eine Konvention dafür geschaffen wird, die Bedeutung dieser Zeichen an den Server-Prozess zu übermitteln. Das NLS(NIC) muss beispielsweise die Position des Druckkopfes verfolgen und wird in Ermangelung solcher Konventionen diese Zeichencodes in Leerzeichen und Zeilenvorschübe umwandeln. Das bedeutet, dass das Erscheinungsbild der Seite bei der Ausgabe von dem bei der Eingabe abweichen kann. Es wäre für den Benutzer hilfreich, wenn seine Seite bei der Ausgabe so formatiert werden könnte, wie sie bei der Eingabe aussah.
3D.
LF-Zeichen würden so behandelt, als wären sie durch Betätigen der Zeilenvorschubtaste an einem „direkt" mit dem Serversystem verbundenen Terminal erzeugt worden.
3E.
Das Wagenrücklaufzeichen (CR) kann eine Quelle erheblicher Schwierigkeiten sein. So können beispielsweise bei der Eingabe verschiedene Systeme oder dasselbe System zu unterschiedlichen Zeiten unterschiedliche Codes an das Terminal und den Benutzerprozess ausgeben (Echo) und übertragen. Manche Monitorsysteme geben nichts, nur ein CR oder ein CRLF als Echo zurück. Manche Systeme übertragen ein CR, ein CRLF oder einen Zeilenendcode (end of line, EOL) an den Benutzerprozess. Der Benutzerprozess kann das Echo steuern oder ergänzen. Angesichts der Kombinationen, die an jedem Ende der Netzwerkverbindung und im Verhältnis zueinander bestehen können, kann Verwirrung entstehen, wenn wir nicht die Definition aus 2A und die Implementierungskonvention aus 2E annehmen. Diese Annahmen implizieren, dass beim Anschlagen eines CR ein CR über das Netz gesendet wird. Wenn das Monitorsystem des Benutzers oder die Terminal-Steuerhardware ein CR in ein CRLF oder EOL umwandelt, muss das Telnet-Programm es wieder in ein CR zurückwandeln. Erreicht das CR den Server-Monitor, wird es für den Server-Prozess ordnungsgemäß behandelt.
Wenn das Echo vom Serversystem ausgeführt wird, werden die richtigen Codes ausgegeben. Das Telnet des Benutzers kann bei Empfang eines CRLF dieses mit den passenden Nullzeichen (null) auffüllen, um die Timing-Anforderungen der Wagenbewegung eines bestimmten Terminals zu bewältigen.
Wenn das Echo vom Benutzersystem ausgeführt wird, wäre es ideal, wenn das Telnet oder System des Benutzers dieselbe Echo-Konvention wie das Serversystem verwendete. Das bedeutet, dass das Telnet entweder eine Tabelle der Echo-Konventionen für die verschiedenen Systeme, mit denen es sich verbinden kann, vorhalten oder diese Information vom Serversystem bzw. Server-Prozess beziehen können muss, oder umgekehrt.
Für ein anfängliches Telnet-Protokoll ist dies wahrscheinlich nicht erforderlich. Das Benutzersystem kann als Standardverhalten auf jedes empfangene CR ein CRLF als Echo zurückgeben. Für alle uns bekannten Situationen und für das NIC dürfte dieser Standard zufriedenstellend sein.
3F.
Für die Kommunikation von zeichen- und zeilenweise arbeitenden Systemen muss der Telnet-Prozess möglicherweise ein Zeichen erkennen (vom Benutzer zuweisbar), das wir Stromende (end of stream, EOS) nennen. Dieses Zeichen soll die in der folgenden Diskussion definierte Funktion haben. Wichtig ist die Unterscheidung zwischen dem Stromende (end-of-stream) als Netzwerkfunktion und dem Zeilenende (end-of-line) als Funktion des Benutzer- oder Serversystems. Betrachten wir zunächst zeilenweise arbeitende Systeme. Wir haben mit zeilenweise arbeitenden Systemen wenig Erfahrung, daher wird das Folgende weiterer Untersuchung und Klärung bedürfen. Nach unserem Verständnis erkennen zeilenweise arbeitende Systeme ein Zeichen wie CR oder ein Unterbrechungssignal als den Code, der den Benutzerprozess aufweckt und die Übertragung der Textzeile an ihn veranlasst. Aus Sicht des NLS(NIC) ist es wichtig, dass der Benutzer in geeigneten Fällen Textzeilen eingeben kann, die jeweils mit einem CR enden, und zu anderen Zeiten Text eingeben kann, der nicht mit einem CR endet. (Eine Aussage für das NLS(NIC) ist eine Zeichenkette „beliebiger" Länge und muss keine CRs enthalten; bei der Ausgabe wird die Zeile für den Benutzer an seiner (vom Benutzer definierbaren) Seitengrenze umbrochen.)
Als Beispiel für das Erforderliche betrachten wir den Fall, in dem das System des Benutzers CR als Zeilenende erkennt. In diesem Fall würde das Telnet beim Empfang eines CR aufgeweckt. Wir würden empfehlen, dass in diesem Fall der CR-Code wörtlich in den Telnet-Ausgabepuffer eingegeben wird. Wenn einem CR ein EOS-Zeichen vorangeht, sollte das CR nicht in den Telnet-Ausgabepuffer gestellt werden. Die Übertragung durch das Netz kann entweder beim Empfang eines EOS oder automatisch erfolgen, wenn sich der Telnet-Ausgabepuffer füllt. Die Übertragung von zeilenweise arbeitenden Systemen an zeichenweise arbeitende Systeme könnte das unbequeme Anschlagen von drei Tasten erfordern, um ein Zeichen durch das Netz zu bekommen.
Betrachten wir nun die Übertragung von einem zeichenweise arbeitenden System an ein Server-System, das zeilenweise arbeitet. Ein ähnliches Problem wie das zu beschreibende besteht auch zwischen zeilenweise arbeitenden Systemen. Angesichts der Definition eines vom CR verschiedenen EOS-Zeichens kann eine Zeile gepuffert werden, bis das EOS empfangen wird, und dann ohne das EOS gesendet werden. Woher weiß das bedienende System, dass eine Zeile gesendet wurde? Ein Weg wäre, dass das bedienende NCP die Nachrichtengrenzen erkennt. Diese Konvention würde ein Designziel verletzen. Ein anderer Weg wäre, dass das Telnet des Benutzers sein NCP auffordert, einen INS-Befehl zu senden. Das Senden von Steuerbefehlen vom INS-Typ könnte in das Netz Wettlaufsituationen (race conditions) einführen und sollte untersucht werden, bevor ihre Verwendung mit einem Telnet-Prozess festgelegt wird. Da einige der uns bekannten zeilenweise arbeitenden Systeme über Spezialhardware verfügen, die das Zeilenendsignal erkennt, brauchen wir eine Möglichkeit, mittels softwaregesteuerter Signalen mit dieser Hardware kompatibel zu bleiben. Wir überlassen dieses Problem der weiteren Untersuchung durch die NWG-Untergruppe.
3G.
Wir kehren nun zum Problem des Unterbrechens oder Escapens im entfernten Serversystem zurück. In Systemen, die die Eingabetastatur nicht sperren, während eine Ausgabe läuft, scheinen die oben skizzierten Mechanismen und Konventionen angemessen, es sei denn, das Escape-Signal ist ein besonderes Unterbrechungssignal (break signal). Letzterer Fall erfordert mehr Untersuchung. In Systemen, die während laufender Ausgabe keine Eingabe zulassen, muss man möglicherweise mit den Folgen einer solchen Terminal-Disziplin leben und darauf gefasst sein zu warten, bis die Ausgabe stoppt, bevor ein Escape-Code gesendet werden kann. Wenn die Tastatur gesperrt ist und ein Escape-Unterbrechungssignal an das System des Benutzers gesendet werden kann, kann es verhindern, dass die Ausgabe zum Terminal gelangt; man muss jedoch darauf gefasst sein, sie vom Server-Standort weiter zu empfangen, bis der Benutzer seinen Telnet-Prozess anweisen kann, ein Unterbrechungs- oder Escape-Signal an den Server-Standort zu senden. Auch dies ist ein Problem für weitere Untersuchung.
Das Online-System des Network Information Center arbeitet auf einem zeichenweise arbeitenden Monitorsystem, und die in diesem Papier festgelegten Konventionen reichen für den Zugriff darauf aus. Diese Konventionen sind in Anhang A zusammengefasst.