General Considerations (Allgemeine Überlegungen)

Eine TELNET-Verbindung (TELNET Connection) ist eine Transmission Control Protocol (TCP, Transmission Control Protocol) Verbindung, die zum Übertragen von Daten mit eingestreuten TELNET-Steuerinformationen (Control Information) verwendet wird.

Das TELNET-Protokoll (TELNET Protocol) basiert auf drei Hauptideen: erstens dem Konzept eines "Netzwerk-Virtual-Terminals" (Network Virtual Terminal); zweitens dem Prinzip ausgehandelter Optionen (Negotiated Options); und drittens einer symmetrischen Sicht auf Terminals und Prozesse (Symmetric View).

1. Wenn eine TELNET-Verbindung erstmals hergestellt wird, wird angenommen, dass jedes Ende an einem "Netzwerk-Virtual-Terminal" (Network Virtual Terminal, NVT) beginnt und endet. Ein NVT ist ein imaginäres Gerät (Imaginary Device), das eine standardmäßige, netzwerkweite Zwischendarstellung (Intermediate Representation) eines kanonischen Terminals (Canonical Terminal) bereitstellt. Dies eliminiert die Notwendigkeit für "Server" (Server) und "Benutzer" (User) Hosts, Informationen über die Eigenschaften der Terminals des jeweils anderen und Terminalverarbeitungskonventionen zu speichern. Alle Hosts, sowohl Benutzer als auch Server, bilden ihre lokalen Geräteeigenschaften und Konventionen so ab, dass sie über das Netzwerk mit einem NVT zu arbeiten scheinen, und jeder kann eine ähnliche Abbildung durch die andere Partei annehmen. Das NVT soll ein Gleichgewicht zwischen zu restriktiv (Hosts kein ausreichend reiches Vokabular zur Abbildung in ihre lokalen Zeichensätze bereitstellen) und zu inklusiv (Benutzer mit bescheidenen Terminals bestrafen) schaffen.

   HINWEIS: Der "Benutzer"-Host ist der Host, an den das physische Terminal normalerweise angeschlossen ist, und der "Server"-Host ist der Host, der normalerweise einen Dienst bereitstellt. Als alternativer Standpunkt, auch in Terminal-zu-Terminal- oder Prozess-zu-Prozess-Kommunikationen anwendbar, ist der "Benutzer"-Host der Host, der die Kommunikation initiiert hat.

2. Das Prinzip der ausgehandelten Optionen berücksichtigt die Tatsache, dass viele Hosts zusätzliche Dienste über die in einem NVT verfügbaren hinaus bereitstellen möchten, und viele Benutzer über anspruchsvolle Terminals verfügen und elegante statt minimale Dienste wünschen. Unabhängig von, aber strukturiert innerhalb des TELNET-Protokolls befinden sich verschiedene "Optionen" (Options), die sanktioniert werden und mit der "DO, DON'T, WILL, WON'T"-Struktur (unten diskutiert) verwendet werden können, um einem Benutzer und Server zu ermöglichen, sich auf die Verwendung eines ausgefeilteren (oder vielleicht einfach anderen) Satzes von Konventionen für ihre TELNET-Verbindung zu einigen. Solche Optionen könnten das Ändern des Zeichensatzes (Character Set), des Echo-Modus (Echo Mode) usw. umfassen.

   Die Grundstrategie zum Einrichten der Verwendung von Optionen besteht darin, dass eine Partei (oder beide) eine Anfrage initiiert, dass eine Option wirksam wird. Die andere Partei kann die Anfrage dann entweder akzeptieren oder ablehnen. Wenn die Anfrage akzeptiert wird, wird die Option sofort wirksam; wenn sie abgelehnt wird, bleibt der zugehörige Aspekt der Verbindung wie für ein NVT spezifiziert. Offensichtlich kann eine Partei eine Anfrage zur Aktivierung immer ablehnen und darf niemals (must never) eine Anfrage zur Deaktivierung einer Option ablehnen, da alle Parteien bereit sein müssen, das NVT zu unterstützen.

   Die Syntax der Optionsverhandlung wurde so eingerichtet, dass wenn beide Parteien gleichzeitig eine Option anfordern, jede die Anfrage der anderen als positive Bestätigung ihrer eigenen sehen wird.

3. Die Symmetrie der Verhandlungssyntax kann potenziell zu nicht terminierenden Bestätigungsschleifen (Nonterminating Acknowledgment Loops) führen -- jede Partei sieht die eingehenden Befehle nicht als Bestätigungen, sondern als neue Anfragen, die bestätigt werden müssen. Um solche Schleifen zu verhindern, gelten die folgenden Regeln:

   a. Parteien dürfen nur eine Änderung des Optionsstatus anfordern; d.h. eine Partei darf nicht (may not) eine "Anfrage" senden, nur um anzukündigen, in welchem Modus sie sich befindet.

   b. Wenn eine Partei etwas erhält, das wie eine Anfrage aussieht, in einen Modus einzutreten, in dem sie sich bereits befindet, sollte die Anfrage nicht (should not) bestätigt werden. Diese Nicht-Antwort ist wesentlich, um endlose Schleifen in der Verhandlung zu verhindern. Es ist erforderlich (required), dass eine Antwort auf Anfragen zur Änderung des Modus gesendet wird -- auch wenn der Modus nicht geändert wird.

   c. Wann immer eine Partei einen Optionsbefehl an eine zweite Partei sendet, sei es als Anfrage oder als Bestätigung, und die Verwendung der Option irgendeinen Einfluss auf die Verarbeitung der von der ersten Partei an die zweite gesendeten Daten hat, dann muss (must) der Befehl an der Stelle in den Datenstrom eingefügt werden, an der gewünscht wird, dass er wirksam wird. (Es sollte beachtet werden, dass zwischen der Übertragung einer Anfrage und dem Empfang einer Bestätigung, die negativ sein kann, einige Zeit vergeht. Daher kann ein Host wünschen, Daten nach dem Anfordern einer Option zu puffern, bis er erfährt, ob die Anfrage akzeptiert oder abgelehnt wird, um die "Unsicherheitsperiode" (Uncertainty Period) vor dem Benutzer zu verbergen.)

   Optionsanfragen werden wahrscheinlich hin und her fliegen, wenn eine TELNET-Verbindung erstmals hergestellt wird, da jede Partei versucht, den bestmöglichen Dienst von der anderen Partei zu erhalten. Darüber hinaus können Optionen jedoch verwendet werden, um die Eigenschaften der Verbindung dynamisch zu ändern, um sich ändernden lokalen Bedingungen zu entsprechen. Beispielsweise verwendet das NVT, wie später erläutert wird, eine Übertragungsdisziplin, die für viele "zeilenweise" (Line at a Time) Anwendungen wie BASIC gut geeignet ist, aber schlecht für viele "zeichenweise" (Character at a Time) Anwendungen wie NLS geeignet ist. Ein Server könnte wählen, den zusätzlichen Prozessor-Overhead zu widmen, der für eine "zeichenweise" Disziplin erforderlich ist, wenn dies für den lokalen Prozess geeignet war, und würde eine entsprechende Option aushandeln. Anstatt jedoch dann dauerhaft mit dem zusätzlichen Verarbeitungs-Overhead belastet zu werden, könnte er zurück zu NVT wechseln (d.h. aushandeln), wenn die detaillierte Kontrolle nicht mehr erforderlich ist.

   Es ist möglich, dass von Prozessen initiierte Anfragen eine nicht terminierende Anfrageschleife stimulieren, wenn der Prozess auf eine Ablehnung reagiert, indem er einfach die Option erneut anfordert. Um zu verhindern, dass solche Schleifen auftreten, sollten abgelehnte Anfragen nicht (should not) wiederholt werden, bis sich etwas ändert. Operativ kann dies bedeuten, dass der Prozess ein anderes Programm ausführt, oder der Benutzer einen anderen Befehl gegeben hat, oder was auch immer im Kontext des gegebenen Prozesses und der gegebenen Option sinnvoll ist. Eine gute Faustregel ist, dass eine erneute Anfrage nur als Ergebnis nachfolgender Informationen vom anderen Ende der Verbindung oder auf Verlangen durch lokale menschliche Intervention erfolgen sollte.

   Optionsdesigner sollten sich nicht durch die etwas begrenzte Syntax, die für die Optionsverhandlung verfügbar ist, eingeschränkt fühlen. Die Absicht der einfachen Syntax ist es, Optionen einfach zu haben -- da es entsprechend einfach ist, Unwissenheit über sie zu bekennen. Wenn eine bestimmte Option eine reichhaltigere Verhandlungsstruktur erfordert als innerhalb von "DO, DON'T, WILL, WON'T" möglich, ist der richtige Ansatz, "DO, DON'T, WILL, WON'T" zu verwenden, um festzustellen, dass beide Parteien die Option verstehen, und sobald dies erreicht ist, kann eine exotischere Syntax frei verwendet werden. Zum Beispiel könnte eine Partei eine Anfrage senden, um die Zeilenlänge (Line Length) zu ändern (festzulegen). Wenn sie akzeptiert wird, kann dann eine andere Syntax verwendet werden, um tatsächlich die Zeilenlänge auszuhandeln -- eine solche "Unterverhandlung" (Sub-Negotiation) könnte Felder für minimal zulässige, maximal zulässige und gewünschte Zeilenlängen enthalten. Das wichtige Konzept ist, dass solche erweiterten Verhandlungen niemals beginnen sollten, bis eine vorherige (Standard-)Verhandlung festgestellt hat, dass beide Parteien in der Lage sind, die erweiterte Syntax zu analysieren.

   Zusammenfassend wird WILL XXX von jeder Partei gesendet, um den Wunsch (Angebot, Offer) dieser Partei anzuzeigen, mit der Ausführung der Option XXX zu beginnen, wobei DO XXX und DON'T XXX ihre positiven und negativen Bestätigungen sind; ähnlich wird DO XXX gesendet, um einen Wunsch (Anfrage, Request) anzuzeigen, dass die andere Partei (d.h. der Empfänger des DO) mit der Ausführung der Option XXX beginnt, wobei WILL XXX und WON'T XXX die positiven und negativen Bestätigungen sind. Da das NVT das ist, was übrig bleibt, wenn keine Optionen aktiviert sind, garantieren die DON'T- und WON'T-Antworten, die Verbindung in einem Zustand zu belassen, den beide Enden handhaben können. Somit können alle Hosts ihre TELNET-Prozesse so implementieren, dass sie völlig unwissend über nicht unterstützte Optionen sind und einfach eine Ablehnung an (d.h. Ablehnung von) jede Optionsanfrage zurückgeben, die nicht verstanden werden kann.

   So weit wie möglich wurde das TELNET-Protokoll Server-Benutzer-symmetrisch gemacht, sodass es die Benutzer-Benutzer- (Verknüpfung, Linking) und Server-Server- (kooperierende Prozesse, Cooperating Processes) Fälle leicht und natürlich abdeckt. Es wird gehofft, aber nicht absolut gefordert, dass Optionen diese Absicht weiter fördern. In jedem Fall wird ausdrücklich anerkannt, dass Symmetrie ein Betriebsprinzip und keine eiserne Regel ist.

   Ein Begleitdokument, "TELNET-Optionsspezifikationen" (TELNET Option Specifications), sollte (should) für Informationen über das Verfahren zur Einrichtung neuer Optionen konsultiert werden.

---