Zusammenfassung

  • RFC 1096 definierte X-DISPLAY-LOCATION als Telnet-Option 35. WILL und DO erlaubten nur die spätere Erörterung; erst eine angeforderte SEND/IS-Subnegotiation übertrug den Wert.
  • Der Locator hatte die Unix-DISPLAY-Form <host>:<dispnum>[.<screennum>]. Der Telnet-Client musste lokale Kürzel wie :0 umformen, ohne damit Namen, Besitz oder Erreichbarkeit zu bestätigen.
  • Die entfernte Anwendung musste eine eigenständige X-Verbindung herstellen und die Zugriffskontrolle sowie Autorisierung des X-Servers passieren. Locator, angenommener Setup und sichtbares Fenster waren drei verschiedene Befunde.

Dem entfernten Prozess fehlte die örtliche Selbstverständlichkeit

Wer einen Telnet-Client unter X benutzte, konnte sich an einem anderen Rechner anmelden und dort ein grafisches Programm starten. Das Programm lief entfernt, sein Fenster sollte aber auf dem Arbeitsplatz des Benutzers erscheinen. Dem entfernten Prozess fehlte häufig die DISPLAY-Koordinate, die ein lokales Programm einfach aus seiner Umgebung erhielt.

RFC 1096 schloss diese Lücke im März 1989 als Proposed Standard. X Display Location erhielt den Optionscode 35; der Telnet-Server konnte den Client nach dem X-Display fragen, unter dem der Client lief. Das aktuelle IANA-Register der Telnet-Optionen führt die Zuordnung weiterhin.

Über Telnet gingen dabei keine X-Bilder und keine X-Befehle. Ein bestehender Kanal lieferte lediglich eine Koordinate, mit der später ein anderer Kanal versucht werden konnte. Die Oberfläche ließ zwei Protokolle wie einen Vorgang erscheinen; die Spezifikation hielt ihre Naht offen.

WILL und DO erlaubten das Gespräch

Der Normalzustand lautet WON’T/DON’T. Eine Anmeldung veröffentlicht nicht automatisch einen Bildschirmstandort. Im Vokabular von RFC 854 erklärt WILL die Bereitschaft, eine Option auszuführen; DO fordert oder bestätigt die Ausführung durch den Partner. Für Option 35 heißt das: später senden beziehungsweise später empfangen.

RFC 1096 begrenzt diese Zusage ausdrücklich auf die Erlaubnis einer künftigen Erörterung. RFC 855 trennt Option und Parameter in zwei Schritte: Zuerst wird die Diskussion vereinbart, dann folgt der Wert zwischen SB und SE. Mit WON’T oder DON’T kann die weitere Subnegotiation beendet werden.

Eine erfolgreiche Aushandlung beweist daher einen Telnet-Zustand. Sie beglaubigt weder den späteren Hostnamen noch den Benutzer und fragt den X-Server nicht nach dessen Regeln. Eine Adresse erfragen zu dürfen bedeutet nicht, die genannte Ressource benutzen zu dürfen.

SEND und IS bestimmten die Rollen

Nur der Absender von DO darf SEND auslösen. Nur der Absender von WILL darf mit IS antworten. Der Standort darf nicht ungefragt erscheinen. So bleiben allgemeine Bereitschaft und tatsächliche Preisgabe unterscheidbar.

Das Muster stammt aus RFC 1079, der Telnet Terminal Speed Option. RFC 1096 übernahm die angeforderte SEND/IS-Folge nahezu wörtlich. Implementierer erhielten eine bekannte Zustandsmaschine.

Die gleiche Verpackung verleiht den Inhalten aber nicht die gleiche Bedeutung. Eine Terminalgeschwindigkeit beschreibt eine Eigenschaft; der X-Locator verweist auf einen anderen Dienst. Im Beispiel liefert IS die NVT-ASCII-Zeichenfolge SRI-NIC.ARPA:0.0, insgesamt eine 22 Oktette lange Subnegotiation. Belegt ist damit die Angabe des Telnet-Partners, nicht der Zustand von X.

Aus :0 musste ein entfernter Bezug werden

Die Unix-DISPLAY-Syntax lautet <host>:<dispnum>[.<screennum>], ohne Leerzeichen oder Zusätze. Lokal können :0 oder unix:0.0 genügen, weil der Host aus dem Kontext folgt. Liest der entfernte Rechner dieselbe Abkürzung, bezeichnet „lokal“ den falschen Rechner. Deshalb muss der Telnet-Client den Wert vor der Übertragung passend ändern.

Diese Änderung übersetzt Geltungsbereich. Sie macht eine implizite Maschine explizit. RFC 1096 behauptet nicht, dass dabei der Name authentisiert, DNS geprüft, eine Route getestet, ein Port geöffnet oder der Besitz des Displays festgestellt wird.

Ein syntaktisch gültiger Locator kann veraltet oder unerreichbar sein. Ein korrekter und erreichbarer Locator kann zu einem Dienst führen, der den Client abweist. Form, Netz und Berechtigung bleiben eigene Prüfungen.

X begann mit einer zweiten Verbindung

RFC 1013 beschreibt einen X-Client mit einer eigenständigen IPC-Verbindung zum X-Server. Bei TCP gehört Display N zu Port 6000+N. Der aus Telnet gewonnene Host und die Displaynummer helfen bei der Auswahl dieses Ziels.

Der Telnet-TCP-Strom wird nicht zum X-Strom. Option 35 ist weder Tunnel noch Proxy noch Weiterleitung und trägt keine X-Anfragen. Die entfernte Anwendung eröffnet als X-Client einen neuen Weg, auf dem Namensauflösung, Routing, Filter und Listenerzustand unabhängig wirken.

Auch Fehler müssen an dieser Grenze bleiben. Ein empfangenes IS belegt die Locator-Übergabe. Ein gescheiterter TCP-Aufbau betrifft den späteren Netzpfad. Eine Setup-Ablehnung stammt aus der X-Stufe. Alles „Telnet-Fehler“ zu nennen, beseitigt die ursächliche Information.

Der X-Server behielt sein Tor

Der X-Setup enthält unter anderem den Namen eines Autorisierungsprotokolls und Autorisierungsdaten. Ein Server kann mit einer Begründung ablehnen oder akzeptieren und Informationen zu Bildschirmen, Formaten und Ressourcen liefern. Welcher Autorisierungsmechanismus gültig ist, bleibt außerhalb des X-Kernprotokolls.

RFC 1013 beschreibt außerdem eine Host-Zugriffsliste. Der X-Server kann einen Client nach seinen eigenen Bedingungen zurückweisen. Die Telnet-Aushandlung ersetzt diese Entscheidung nicht.

Das heutige IANA-Register führt X Display Location als 35 und Telnet Authentication separat als 37. Diese gegenwärtige Klassifikation verhindert, dass 35 zur Authentisierung umgedeutet wird. Sie belegt aber keine konkrete Kombination in einer Installation von 1989.

Die Nachweiskette hat klare Stufen: WILL/DO erlaubt die Subnegotiation; SEND/IS liefert einen Locator; TCP-Erfolg belegt einen erreichbaren Endpunkt; angenommener X-Setup belegt die Zulassung der Verbindung. Erst eine spätere Beobachtung kann zeigen, ob die Anwendung das beabsichtigte Fenster erzeugte.

Die Wirkung blieb hinter dem Setup

Nach der Annahme muss die Anwendung Ressourcen anlegen und Anforderungen senden. Der Server muss das richtige Fenster abbilden und nutzbar halten. Schließlich muss der Benutzer es auf dem vorgesehenen Bildschirm wahrnehmen. Die Verbindungsannahme enthält diese Aussagen nicht.

Gerade diese Begrenzung macht RFC 1096 lehrreich. Das Dokument löst die Kontextübergabe, ohne Verschlüsselung, Authentisierung, Zugriffspolitik, Weiterleitung oder Darstellung zu beanspruchen. Für jede spätere Aussage ist ein späterer Nachweis nötig.

Auch ein IANA-Eintrag ist keine Verbreitungsstatistik. Er belegt Nummer und Referenz, nicht Einsatzhäufigkeit, Hostverhalten oder Benutzererfolg. Die Quellen tragen die Geschichte des Mechanismus, nicht eine erfundene Erfolgskurve.

Der Standort konnte Telnet passieren. Über den Zugang entschied weiterhin X.

Quellen