Résumé

  • La RFC 1073 donnait au client la maîtrise de la taille de sa fenêtre et lui permettait d’annoncer ensemble largeur et hauteur, puis de recommencer après chaque changement. Le serveur gardait le droit d’accepter l’option, d’ignorer les valeurs ou d’interdire les mises à jour suivantes.
  • L’accord DO/WILL, le message NAWS, l’état du pseudo-terminal, le signal adressé au processus enfant et la mise en page de l’application formaient autant de preuves distinctes. Une taille en caractères n’attestait ni des pixels, ni de l’identité, ni de ce que l’utilisateur avait vu.

Le point de départ de Telnet était volontairement pauvre : le terminal virtuel de réseau ne fixait ni largeur d’imprimante ni longueur de page. Cette abstraction permettait à des machines dissemblables de dialoguer, mais elle laissait les applications plein écran sans indication fiable lorsque le terminal prenait la forme d’une fenêtre graphique redimensionnable.

La RFC 1073 introduisit NAWS, Negotiate About Window Size, sous le code 31. Son innovation décisive ne résidait pas seulement dans deux nombres sur seize bits. Elle corrigeait l’attribution du pouvoir : le client contrôlait entièrement sa fenêtre locale et en déclarait l’état courant ; le serveur décidait s’il voulait recevoir cette déclaration et ce qu’il en ferait.

L’accord ouvrait la conversation, pas la fenêtre

Le serveur pouvait proposer DO NAWS et le client répondre WILL NAWS. DON'T et WON'T permettaient le refus. Selon la méthode documentée par la RFC 855, cette négociation préalable établissait seulement que les deux extrémités comprenaient l’option. Les données détaillées venaient ensuite dans une sous-négociation.

Il faut donc résister à une lecture trop généreuse. Voir DO puis WILL ne prouve pas qu’un seul octet de géométrie a suivi. Cela ne prouve pas davantage que le serveur a mis à jour son état, qu’un processus en a été averti ou que l’affichage s’est adapté.

Le client envoyait ensuite IAC SB NAWS, deux octets de largeur, deux de hauteur, puis IAC SE. Les axes étaient exprimés en caractères, dans l’ordre Internet. Chacun pouvait aller jusqu’à 65 535. Si l’un des quatre octets valait 255, il devait être doublé afin de ne pas être confondu avec l’octet de commande IAC. Avant d’interpréter la géométrie, le récepteur devait donc avoir correctement reconnu et déséchappé la trame.

Une valeur nulle ne décrivait pas une fenêtre sans dimension. Elle signifiait que le client ne communiquait pas cet axe. Le serveur devait alors choisir une hypothèse propre à son système, éventuellement à partir du type de terminal reçu par ailleurs. Le zéro conservait une inconnue ; le convertir en mesure littérale aurait effacé l’information la plus importante.

Le deuxième état n’acquittait pas le premier

Après l’accord initial, un client pouvait envoyer spontanément une nouvelle sous-négociation lorsque sa fenêtre changeait. L’exemple de la RFC passe de 80 × 24 à 80 × 64 au cours de la même connexion. Le premier message n’était pas une commande persistante, et le second n’était pas un accusé de traitement. C’étaient deux déclarations successives d’un état local.

Cette propriété crée une chronologie qu’un diagnostic doit préserver. La fenêtre peut changer à l’instant A, les quatre octets parvenir au serveur à l’instant B, l’état du terminal distant être modifié à l’instant C et l’application reformater sa sortie à l’instant D. Entre ces points, deux parties du système peuvent sincèrement détenir des tailles différentes.

La RFC qualifie expressément les valeurs de consultatives. Le serveur peut accepter NAWS sans les utiliser. Certains systèmes d’exploitation de l’époque ne savaient pas actualiser la taille pendant une session. Le serveur pouvait alors envoyer DON'T NAWS après un accord initial et interdire les annonces ultérieures sans provoquer de boucle de négociation. La fenêtre locale continuait d’exister et de changer ; seule sa représentation distante cessait d’être alimentée.

L’ancien modèle attribuait le contrôle au mauvais endroit

Les options NAOL et NAOP avaient tenté de négocier séparément largeur de ligne et longueur de page. La RFC 1073 les jugeait mal adaptées : bidirectionnelles, elles pouvaient laisser entendre que le serveur commandait la géométrie du client ; elles limitaient chaque axe à 253 et étaient peu utilisées selon les références contemporaines.

NAWS envoyait les deux axes ensemble, parce qu’une fenêtre change généralement dans ses deux dimensions. Mais surtout, il abandonnait la fiction d’une taille négociée entre deux propriétaires égaux. Le client informait ; le serveur réagissait. Une valeur de 300 × 24 dans l’exemple ne décrivait ni la largeur physique d’un écran ni le nombre de pixels, seulement une grille de caractères annoncée.

Cette asymétrie n’affaiblissait pas Telnet. Elle rendait l’interface honnête. Un protocole peut rester symétrique pour accorder une option tout en étant asymétrique sur la provenance du fait transporté.

Géométrie, type et vitesse ne formaient pas un profil unique

La RFC 930 organisait une autre conversation : le serveur demandait un type de terminal et le client répondait. Elle précisait déjà que recevoir ce type n’impliquait pas de changement immédiat de traitement. La RFC 1091 permit ensuite de parcourir plusieurs modes d’émulation, toujours à la demande du serveur.

La RFC 1079, option 32, traitait la vitesse. Après permission, le demandeur sollicitait une chaîne ASCII contenant les débits d’émission et de réception ; l’autre extrémité ne l’envoyait pas spontanément. Une valeur non prise en charge pouvait être arrondie prudemment. NAWS, au contraire, autorisait le client à annoncer de lui-même chaque nouvelle géométrie sous forme de deux axes binaires.

Un type pouvait aider à choisir une largeur lorsque NAWS envoyait zéro. Il ne mesurait pas la fenêtre courante. Une vitesse pouvait guider le remplissage ou une interface ; elle ne décrivait pas le nombre de colonnes. Ces informations restaient utiles parce que leur autorité ne débordait pas leur champ.

Le registre IANA des options Telnet associe encore le code 31 à NAWS et le 32 à TERMINAL-SPEED. Cette inscription établit un nom et une référence documentaire. Elle ne démontre ni un déploiement actuel, ni la conformité d’un logiciel, ni l’usage de l’option dans une session donnée.

Quatre octets traversaient plusieurs autorités locales

La note d’implémentation de la RFC suit une chaîne très concrète. Un environnement graphique avertit le client de la nouvelle fenêtre. Sous 4.3BSD, le processus Telnet peut recevoir SIGWINCH. Il envoie NAWS. Le serveur peut appliquer un ioctl à son terminal, puis peut signaler le changement à son processus enfant, probablement un shell.

Chaque « peut » désigne un propriétaire différent : gestionnaire de fenêtres, client Telnet, parseur, couche terminal du serveur, processus enfant, application. Une trace prise à une frontière ne certifie pas la suivante. Même un signal livré ne prouve pas que l’application l’a traité avant sa prochaine sortie. Une sortie correctement découpée ne prouve pas qu’elle a été visible pour une personne.

Cette séparation fournit une meilleure méthode d’enquête qu’un indicateur global. En cas de lignes mal coupées, il faut comparer l’événement de redimensionnement, la sous-négociation brute, son déséchappement, la taille mémorisée, le signal au processus et la géométrie effectivement consultée par l’application.

Sources et limites

La RFC 1073 décrit une option proposée en 1988 et mentionne un usage contemporain à Carnegie-Mellon ; elle ne mesure pas son adoption générale. Les RFC 854 et 855 donnent le cadre de Telnet. Les RFC 930, 1079 et 1091 documentent des informations voisines, sans prouver l’application de NAWS. Aucun de ces textes n’établit une filiation directe avec les pseudo-terminaux SSH, les interfaces web adaptatives ou un produit moderne.

La leçon historique tient dans la modestie de la preuve. NAWS rendait la géométrie transportable sans transformer une déclaration du client en ordre pour le serveur. La fenêtre appartenait à l’un ; la réaction appartenait à l’autre.