Résumé

  • L’option TERMINAL-SPEED du RFC 1079 ne transmet une caractéristique de terminal qu’après accord mutuel et demande explicite.
  • Une réponse pouvait orienter une décision d’affichage locale, mais ne prouvait rien sur le chemin IP, TCP, le routage ou le résultat pour l’utilisateur.

Un chiffre dont la mission restait volontairement étroite

Les terminaux physiques ne se comportaient pas tous de la même manière. Les systèmes conservaient souvent la vitesse des terminaux et des modems directement raccordés afin de régler les délais d’affichage ; certains logiciels adaptaient aussi leur interface selon qu’un terminal était rapide ou lent. C’est le problème concret que vise le RFC 1079. Il ne cherche pas à sonder Internet. Il cherche à rendre accessible, dans une session Telnet, une information comparable sur le terminal.

Cette nuance empêche une dérive facile. Une chaîne telle que 9600,100 a l’apparence d’une mesure. Dans le RFC, c’est pourtant une déclaration NVT ASCII de vitesses d’émission et de réception du terminal, fournie par un pair. Elle n’est ni un test de débit, ni une observation de latence, ni un rapport de congestion, ni une promesse que les octets arriveront à la cadence annoncée. Le même nombre peut être utile pour une interface et insuffisant pour gouverner tout le reste.

L’accord n’était pas le rapport

Le RFC 854 donne à Telnet son langage général : le Network Virtual Terminal reste le socle commun, tandis que WILL, WON'T, DO et DON'T permettent d’accepter ou de refuser des conventions supplémentaires. Le RFC 1079 applique cette discipline à l’option 32.

Le défaut est WON'T TERMINAL-SPEED et DON'T TERMINAL-SPEED. L’absence d’échange est donc le point de départ. WILL indique une disposition à fournir une information plus tard ; DO une disposition à la recevoir. Aucun des deux messages ne contient une vitesse. Ils ne créent qu’une permission de discuter ultérieurement.

Après les deux messages, seul l’émetteur de DO TERMINAL-SPEED peut demander la valeur avec IAC SB TERMINAL-SPEED SEND IAC SE. Seul l’émetteur de WILL TERMINAL-SPEED peut répondre avec IAC SB TERMINAL-SPEED IS ... IAC SE. Le renseignement ne doit jamais arriver spontanément. Ainsi, une volonté n’est pas transformée en résultat, et une réponse n’acquiert pas l’autorité d’un constat indépendant.

La réponse est une paire décimale NVT ASCII, vitesse d’émission puis de réception, séparées par une virgule, sans zéro initial ni espace superflu. Cette précision rend l’analyse locale interopérable. Elle ne certifie ni le matériel représenté, ni le modem, ni le chemin entre les hôtes, ni l’expérience réelle de la personne devant l’écran.

Une suggestion d’implémentation, non une politique de réseau

Le RFC envisage un système qui ne connaît qu’un ensemble discret de vitesses. Il conseille de choisir une valeur disponible suffisamment sûre ; pour le remplissage, arrondir vers le haut peut être préférable à un manque de remplissage. Cette proposition parle de la réaction locale d’un programme à une information reçue. Elle ne commande ni la ligne, ni un routeur, ni une réservation de capacité, ni TCP.

Le logiciel peut conserver la valeur originale, noter l’arrondi choisi et modifier son affichage lors d’une demande ultérieure. Cette réversibilité est importante : le programme assume sa décision, au lieu de faire passer un attribut de terminal pour une loi sur le réseau. Le RFC 930, modèle cité par le RFC 1079, illustre la même économie pour le type de terminal : une information transmise peut nourrir un choix ultérieur sans impliquer immédiatement un changement de traitement.

Les faits que la chaîne ne décide pas

Recevoir 1200,1200 établit seulement qu’un participant Telnet a envoyé ces caractères dans la grammaire prévue. Cela ne prouve pas que le terminal est physiquement relié à cette vitesse, que le modem est synchronisé, que le chemin TCP a cette capacité, que les paquets ne sont pas perdus, que l’écran est lisible, ou qu’une opération applicative a réussi. La réponse ne nomme pas une personne, n’autorise aucune action et ne démontre pas l’usage actuel de Telnet.

Cette séparation protège contre une inflation d’inférence : un attribut local devient un nombre, le nombre devient prétendue mesure, puis la prétendue mesure devient prétexte à une politique de transport ou de service. Le RFC 1079 ne fournit aucune de ces marches. Il fournit une métadonnée de terminal, demandée, limitée et analysable. Chaque affirmation plus large exige son propre témoin et sa propre autorité.

Sources et limite de preuve

Le paquet figé comprend les RFC 1079, 854, 930 et 1123. Le RFC 1079 établit la motivation, les commandes, le défaut, la syntaxe et le conseil local. Le RFC 854 établit NVT et la négociation Telnet. Le RFC 930 sert de comparaison historique ; le RFC 1123 situe le texte parmi les références Telnet. Aucun n’établit un déploiement actuel, une implémentation nommée, la capacité d’une liaison, l’identité, l’autorisation ou le résultat d’une application.