Résumé

  • La RFC 1096 créa l’option Telnet 35 pour demander puis recevoir l’emplacement d’un affichage X. WILL et DO n’autorisaient que la discussion ultérieure ; la valeur passait ensuite dans un échange SEND/IS strictement orienté.
  • L’adresse suivait la forme Unix DISPLAY <host>:<dispnum>[.<screennum>]. Le client Telnet devait convertir un raccourci local comme :0, sans que cette conversion authentifie le nom, confirme la route ou prouve la propriété de l’écran.
  • L’application distante devait encore ouvrir une connexion X distincte et satisfaire les contrôles d’accès et d’autorisation du serveur X. Recevoir une adresse, réussir le setup et produire un résultat visible sont trois constats différents.

Une coordonnée manquait au processus distant

Le geste semblait simple : se connecter par Telnet à une machine, y lancer une application X et voir sa fenêtre sur le poste d’où l’on travaillait. Mais le shell distant ne recevait pas nécessairement la coordonnée de l’affichage local. Le processus savait où il s’exécutait ; il ignorait où envoyer son interface.

La RFC 1096, Proposed Standard de mars 1989, ajouta X-DISPLAY-LOCATION aux options Telnet sous le numéro 35. Le serveur Telnet pouvait ainsi demander au client l’emplacement de l’affichage sous lequel celui-ci tournait. Le registre IANA des options Telnet conserve aujourd’hui encore cette attribution.

La solution ne transportait aucun dessin. Elle ne plaçait pas X dans le flux Telnet. Elle déplaçait une coordonnée afin qu’un programme situé ailleurs puisse tenter un nouveau raccordement. L’unité ressentie par l’utilisateur reposait donc sur une couture, pas sur une session unique.

WILL et DO ne donnaient le droit que de parler

Par défaut, les états sont WON’T et DON’T : aucune annonce n’est implicite. Selon le vocabulaire de la RFC 854, WILL exprime la disposition à fournir ultérieurement l’emplacement et DO la disposition à le recevoir. Les formes négatives refusent ces rôles.

La RFC 1096 insiste sur la portée de cet accord. WILL et DO ne servent qu’à obtenir et accorder la permission de discuter l’option par la suite. C’est la construction en deux temps de la RFC 855 : négocier d’abord la possibilité d’un paramètre, puis transmettre ce paramètre entre SB et SE. WON’T ou DON’T peuvent encore fermer la discussion.

Cet accord est une preuve d’état entre deux implémentations Telnet. Il ne dit rien de la validité matérielle de l’écran, de son propriétaire ni de la politique du serveur X. La permission de recevoir une adresse ne vaut pas permission d’entrer à cette adresse.

SEND posait la question, IS répondait

Une fois l’option négociée, la valeur ne peut toujours pas être envoyée librement. Seul l’émetteur de DO peut demander SEND ; seul l’émetteur de WILL peut répondre IS. Le fournisseur ne doit pas annoncer spontanément son emplacement.

Cette discipline reprend celle de la RFC 1079 pour la vitesse du terminal. Le modèle demandé-répondu était déjà compris : un accord général précède la livraison d’une chaîne d’état. Sa réutilisation évitait une nouvelle machine d’états.

L’analogie s’arrête toutefois à l’enveloppe. Une vitesse décrit un terminal ; une adresse X désigne un autre service, avec une route et une politique propres. Dans l’exemple de la RFC 1096, IS transporte SRI-NIC.ARPA:0.0 en NVT ASCII, pour une sous-commande de 22 octets. Ce reçu atteste une déclaration bien formée du pair Telnet, rien de plus.

Modifier :0, c’était traduire une portée

La syntaxe est <host>:<dispnum>[.<screennum>], sans espace ni caractère parasite. Sur la station locale, :0 ou unix:0.0 suffit souvent : la machine est implicite. Du point de vue du serveur distant, le même mot « local » désignerait une autre machine. Le client Telnet doit donc adapter la valeur avant de l’envoyer.

Ce travail est une traduction de contexte. Le client rend explicite ce que l’environnement local permettait d’omettre. La RFC ne transforme pas pour autant le client en autorité de certification. Elle ne lui demande ni d’authentifier le nom, ni de tester le DNS, la route ou le port, ni de démontrer que l’utilisateur contrôle l’affichage.

Une chaîne valide peut être périmée ou inaccessible. Une chaîne exacte peut mener à un serveur qui refuse la connexion. Le format rend la tentative possible ; il n’en garantit pas le résultat.

Le second chemin appartenait au protocole X

La RFC 1013 décrit un client X ouvrant sa propre connexion IPC vers le serveur X. Sur TCP, l’affichage N correspond au port 6000+N. Le processus distant peut déduire cette destination de la valeur reçue, puis tenter le raccordement.

Le flux Telnet ne devient jamais cette connexion. L’option 35 n’est ni tunnel, ni mandataire, ni mécanisme de transfert ; elle ne porte pas les requêtes X. Si IS arrive mais que la connexion suivante échoue, le premier échange a tout de même réussi. Il faut alors examiner résolution, routage, filtrage, écoute ou état du serveur X.

Cette décomposition empêche également une confusion de sécurité. Rendre un nom local utilisable depuis le réseau peut élargir la surface d’adressage. La RFC 1096 décrit ce passage, mais laisse la décision d’accepter un client distant au système qui possède la ressource.

X conservait sa propre porte

La phase de setup X contient notamment le nom d’un protocole d’autorisation et ses données. Un serveur peut refuser et donner une raison ; s’il accepte, il renvoie des informations sur ses formats, écrans et ressources. La RFC 1013 laisse le choix du mécanisme d’autorisation valide hors du cœur du protocole.

Elle définit en outre une liste de contrôle d’accès par hôte. Le serveur peut donc refuser selon des conditions qui ne proviennent pas de Telnet. DO/WILL autorise l’échange de l’adresse ; la décision X autorise, ou non, une connexion X séparée.

Le registre actuel distingue aussi X Display Location, option 35, de Telnet Authentication, option 37. Cette séparation contemporaine éclaire la fonction de 35 sans autoriser un récit rétroactif sur les combinaisons déployées en 1989.

La chaîne de preuves est graduée. WILL/DO établit le droit de sous-négocier. SEND/IS établit la remise d’une chaîne. Une connexion TCP établit un chemin vers un écouteur. Le setup accepté établit une admission par X. Aucun de ces constats ne démontre que l’application a créé la fenêtre attendue.

La fenêtre restait une conséquence à observer

Après l’admission, l’application doit encore créer ses ressources, envoyer ses requêtes et faire afficher une fenêtre exploitable. L’utilisateur doit la voir sur le bon écran. L’acceptation du setup est une preuve forte mais intermédiaire.

La leçon dépasse cette petite option. Les systèmes distribués annoncent souvent leurs succès trop tôt : une adresse reçue devient « service disponible », un handshake devient « opération réussie », un code retour devient « résultat pour l’utilisateur ». Chaque promotion demande pourtant un constat nouveau.

Le registre IANA n’est pas davantage un recensement d’usage. Il prouve le numéro et la référence normative, non l’adoption, la politique d’un hôte ou l’expérience d’une personne. Les sources permettent d’écrire l’histoire du mécanisme, pas d’inventer son marché.

La RFC 1096 reste ainsi un exemple de sobriété architecturale. Telnet pouvait transmettre le contexte nécessaire à X sans s’approprier le contrôle de X. L’adresse traversait la session ; l’autorité restait au point d’arrivée.

Sources