Zusammenfassung
- RFC 884 gab der Telnet-Option
TERMINAL-TYPEim Dezember 1983 die Nummer 24.DOundWILLeröffneten den Austausch; erstSENDfragte nach dem Namen,ISübermittelte ihn. - Ein Terminal konnte zuerst eine genaue, dann eine allgemeinere Bezeichnung nennen. Die Wiederholung des letzten Namens beendete die Liste. RFC 930 verlangte 1985 eine klare Reihenfolge von Frage und Antwort, nachdem gleichzeitige Nachrichten einander in die Quere kommen konnten.
Ein Bildschirmmenü ist eine feine Sache, bis es auf dem falschen Gerät landet. Auf einem Terminal bewegt eine Steuerfolge den Cursor. Ein anderes zeigt stattdessen rätselhafte Zeichen. Eine Fernschreibmaschine sieht der ganzen Anstrengung auf Papier zu. Der Host kann die Tastatur des Benutzers längst hören und trotzdem nicht wissen, wie er auf dessen Gerät eine Zeile an die gewünschte Stelle setzt.
Telnet besaß dafür zunächst eine gemeinsame Grundlage: das Network Virtual Terminal. Diese gedachte Maschine erlaubte allen Beteiligten, eine Sitzung zu beginnen, bevor sie die Eigenheiten des realen Gegenübers kannten. Wer mehr als den gemeinsamen Nenner wollte, brauchte zusätzliche Angaben. Marvin Solomon und Edward Wimmers formulierten in RFC 884 eine Möglichkeit, das Gerät am anderen Ende vorzustellen.
Die Option bekam den Code 24 und begann mit DON'T und WON'T: kein Austausch des Typs. Der Host konnte DO senden, die Gegenseite WILL erwidern. Damit waren beide zu einem späteren Gespräch bereit; der Typ war noch nicht genannt. Erst das Unterkommando SEND, Nummer 1, forderte den Namen an. IS, Nummer 0, brachte eine Zeichenkette in NVT ASCII zurück. Das Beispiel des RFC lautet IBM-3278-2. Groß- und Kleinschreibung spielten beim Vergleich keine Rolle.
Die Namensliste las sich wie ein Rundgang durch ein damaliges Rechenzentrum: IBM-Anzeigen, unter TOPS20 verbreitete Geräte und Unix-Terminals, darunter DEC-VT100 und TELETYPE-33. Ein gemeinsames Netzwerk verband höchst ungleiche Schreibtische. Der Typname konnte an einen lokalen Treiber gehen, der geeignete Ausgaben für Cursor oder Farben auswählte. Das Dokument nannte auch die Kombination mit der Telnet-Option BINARY. Das Wissen über den Namen lag beim Protokoll; die passende Darstellung musste die Hostsoftware liefern.
Besonders menschlich wurde die Angelegenheit bei der Rechtschreibung. Solomon und Wimmers stellten IBM3278-2 und IBM-3278/2 als mögliche Quelle der Verwirrung nebeneinander. Für einen unverstandenen Typnamen gab es keine eigene negative Bestätigung. Ein Gerät mit genauer und allgemeiner Bezeichnung konnte daher bei wiederholten SEND-Anfragen Schritt für Schritt allgemeinere Namen nennen. Am Ende wiederholte es den letzten Eintrag. Traf dieselbe Antwort zweimal hintereinander ein, sollte der Host aufhören zu fragen. Der Computer bekam damit eine kodierte Form von: „Unter welchem Namen kennt man Sie sonst noch?“
Auch UNKNOWN war vorgesehen, wenn eine brauchbare Bezeichnung fehlte. Der empfangene Name war ein Hinweis für die lokale Verarbeitung. Ein Host, der die Zeichenkette verstand, konnte seine Ausgabe auf das Gerät zuschneiden. Ein anderer konnte bei seiner schlichten Darstellung bleiben oder eine zusammenhängende Option wie BINARY ablehnen. Die Antwort enthielt weder einen Cursorbefehl noch ein fertiges Bildschirmprogramm.
Die Fassung von 1983 erlaubte einen Gesprächsteilnehmer mit etwas zu viel Eifer. Nach DO und WILL durfte die Terminalseite ein IS unaufgefordert senden. Die Autoren rechneten bei einer gleichzeitig eintreffenden Anfrage höchstens mit doppelter Information. RFC 930 korrigierte diese Annahme im Januar 1985. Kreuzen sich ein spontanes IS und ein SEND, lässt sich die nächste Antwort womöglich als zweiter Name statt als Antwort auf die Frage lesen. Seit der Änderung folgt IS nur auf SEND.
Der RFC 1091 machte 1989 aus der Folge von Namen auch einen Weg, zwischen mehreren Emulationsarten zu wechseln. RFC 884 erzählte noch die kleinere Geschichte: Ein entfernter Rechner wollte sich auf den Bildschirm eines Menschen einstellen. Also fragte er, wie das Gerät heißt, und ließ sich nötigenfalls einen zweiten Namen geben.
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten





