Zusammenfassung

  • RFC 1073 ließ den Client Breite und Höhe in Zeichen gemeinsam melden und nach einer lokalen Größenänderung erneut senden. Der Server konnte NAWS annehmen, die Werte ignorieren oder spätere Meldungen wieder untersagen.
  • DO/WILL erlaubte die Optionssprache; die vier Datenoktette waren eine Aussage des Clients. Aktualisierter Terminalzustand, Benachrichtigung des Kindprozesses, neue Anwendungsformatierung und menschliche Sichtbarkeit blieben getrennte Tatsachen.

Das Network Virtual Terminal des Telnet-Grundprotokolls hatte absichtlich keine festgelegte Druckbreite und Seitenlänge. Diese schmale gemeinsame Grundlage verband unterschiedliche Rechner. Mit grafischen Workstations entstand jedoch ein bewegliches lokales Objekt: Ein Telnet-Client lief in einem Fenster, dessen Rechteck sich mitten in der Sitzung ändern konnte.

RFC 1073 vergab Optionscode 31 an NAWS, Negotiate About Window Size. Die entscheidende Neuerung war nicht bloß ein 16-Bit-Wertebereich. Sie ordnete die Kontrolle richtig zu. Der Client beherrschte die Größe seines Fensters vollständig und teilte den aktuellen Stand mit. Der Server behielt die Entscheidung, ob er die Option zuließ und wie er die Werte lokal verwendete.

Zustimmung war noch keine Größenänderung

Ein Server konnte DO NAWS senden, ein bereiter Client mit WILL NAWS antworten. DON'T und WON'T ermöglichten die Ablehnung. Nach dem Rahmen aus RFC 855 öffnete dieser Austausch erst die Tür für eine reichere Subnegotiation. Er transportierte noch nicht die eigentlichen Optionsdaten.

DO/WILL belegt deshalb eine Erlaubnislage, nicht das Vorliegen einer Geometrie. Der Empfang einer NAWS-Nachricht belegt Daten am Telnet-Parser, aber weder Speicherung noch ioctl, Prozesssignal oder Neuformatierung. Wer die erste Beobachtung als Gesamtergebnis bezeichnet, überspringt mehrere lokale Eigentümer.

Die Subnegotiation enthielt zwei Oktette Breite und zwei Oktette Höhe in Internet-Reihenfolge. Die Einheit waren Zeichen, nicht Pixel; jede Achse reichte bis 65.535. Da Telnet 255 als IAC reserviert, musste ein Datenwert 255 verdoppelt werden. Die vier logischen Oktette entstanden also erst nach korrekter Rahmenerkennung und Entschärfung.

Null bedeutete nicht ein Fenster ohne Zeilen oder Spalten. Der Client lieferte die betreffende Achse nicht. Der Server durfte eine betriebssystemspezifische Annahme wählen und dafür vielleicht separat erhaltene Terminaltyp-Information nutzen. Das Protokoll bewahrte Unwissen. Eine wörtliche Nullgröße hätte daraus falsche Genauigkeit gemacht.

Der zweite Bericht quittierte den ersten nicht

Das Beispiel der RFC beginnt bei 80 × 24 und wechselt später auf 80 × 64. Der Client wiederholt DO/WILL nicht. Nach der lokalen Änderung sendet er innerhalb der bereits zugelassenen Option eine neue Generation seines Zustands.

Diese zweite Meldung bestätigt nicht, dass der Server die erste angewandt hatte. NAWS definiert auch keine Erfolgsmeldung des entfernten Programms. Fensterverwaltung, Client, Server-Terminalzustand und Anwendung können zeitweise verschiedene Generationen besitzen. „Die aktuelle Größe“ ist ohne Akteur und Zeitpunkt keine eindeutige Aussage.

RFC 1073 nennt die Information ausdrücklich beratend. Ein Server konnte die Option annehmen und die Werte dennoch nicht benutzen. Manche Betriebssysteme konnten die Größe während einer Sitzung nicht aktualisieren. Der Server durfte nach anfänglicher Zustimmung DON'T NAWS senden und weitere Subnegotiationen stoppen, ohne eine Verhandlungsschleife zu erzeugen. Das lokale Fenster konnte sich weiter ändern; nur der entfernte Berichtskanal schloss sich.

Diese Asymmetrie war beabsichtigt. Der Client besaß die Geometrie, der Server die Reaktion.

Das Vorgängermodell verteilte Macht in die falsche Richtung

NAOL und NAOP behandelten zuvor Zeilenbreite und Seitengröße getrennt. RFC 1073 hielt ihre Semantik für grafische Fenster ungeeignet: Sie waren bidirektional, konnten Serverkontrolle über Clientabmessungen nahelegen, begrenzten jede Achse auf 253 und waren laut damaligem Material wenig gebräuchlich.

NAWS schickte beide Achsen gemeinsam, weil Fenster meist als Rechteck verändert werden. Vor allem ersetzte es ein Aushandeln der lokalen Größe durch eine Zustandsmitteilung. Der Server konnte Berichte anfordern, das Clientfenster über NAWS aber nicht verstellen.

Eine Angabe wie 300 × 24 bezeichnete ein Zeichenraster. Sie bewies weder physische Bildschirmbreite noch Pixelzahl oder Skalierung. Dafür wären Schrift, Dichte und Darstellung nötig, die nicht Teil der Nachricht waren.

Typ, Geschwindigkeit und Geometrie blieben eigenständige Fakten

RFC 930 definierte TERMINAL-TYPE als serverseitige Anfrage mit Clientantwort. Der Empfang eines Namens erforderte keine sofortige Verarbeitungsänderung. RFC 1091 erlaubte später das Durchlaufen mehrerer Emulationsmodi, weiterhin auf Anfrage des Servers. Typ war Auswahlkontext, keine Messung des aktuellen Fensters.

RFC 1079 legte Optionscode 32 für Terminalgeschwindigkeit fest. Nach Zustimmung forderte eine Seite eine ASCII-Zeichenfolge mit Sende- und Empfangsrate an; die andere durfte sie nicht spontan senden. Nicht unterstützte Werte konnten in eine sichere Richtung gerundet werden. NAWS dagegen erlaubte dem Client nach Zustimmung, jede lokale Größenänderung selbständig als zwei binäre Achsen zu melden.

Ein Terminaltyp konnte bei einer Nullachse eine Voreinstellung stützen, war aber keine Geometriemessung. Geschwindigkeit konnte Padding oder Bedienung beeinflussen, war aber keine Spaltenzahl. Die getrennten Optionen hielten Herkunft und Gültigkeitsdauer der Aussagen sichtbar.

Das IANA-Verzeichnis der Telnet-Optionen ordnet 31 NAWS und 32 TERMINAL-SPEED zu. Diese Registrierung belegt Nummer und Referenz, nicht heutige Implementierung, Produktkonformität oder Nutzung in einer konkreten Sitzung.

Vier Oktette trafen auf mehrere lokale Entscheidungen

Die Implementierungsskizze der RFC beschreibt eine Kette. Das Fenstersystem informiert den Telnet-Client. Unter 4.3BSD kann der Client SIGWINCH auffangen. Er sendet NAWS. Der Server kann den Terminalzustand per ioctl ändern und anschließend seinem Kindprozess, wahrscheinlich einer Shell, ein Signal geben.

Jedes „kann“ gehört zu einer anderen Komponente. Ein korrektes NAWS garantiert kein erfolgreiches ioctl. Ein neuer Terminalzustand garantiert kein Prozesssignal. Ein Signal garantiert keine rechtzeitige Verarbeitung durch die Anwendung. Gut umbrochene Ausgabe beweist noch nicht, dass ein Mensch sie gesehen hat.

Bei fehlerhaftem Umbruch müssen lokales Resize-Ereignis, Rohdaten, 255-Entschärfung, gespeicherte Servergeometrie, Kindprozesssignal und von der Anwendung gelesene Generation verglichen werden. Ein einziges „Resize erfolgreich“ verdeckt den Ort der Abweichung.

Quellen und Grenzen

RFC 1073 dokumentiert einen Vorschlag von 1988 und eine damalige Nutzung in Carnegie-Mellon, keine allgemeine Verbreitung. RFC 854 und 855 liefern den Telnet-Rahmen. RFC 930, 1079 und 1091 beschreiben benachbarte Attribute, ohne NAWS-Anwendung zu beweisen. Auch die IANA-Registrierung ist kein Verkehrs- oder Produktnachweis.

Eine direkte Abstammung zu SSH-Pseudoterminals, responsiven Webseiten oder Remote-Desktop-Systemen ist nicht belegt und für die historische Aussage unnötig. NAWS machte einen veränderlichen lokalen Zustand transportierbar, ohne die Meldung in einen Befehl zu verwandeln.