Résumé

  • Le Telnet de 1972 réservait les valeurs 128 à 255 au contrôle. La version ultérieure concentra l’autorité des commandes dans IAC, valeur 255, afin que les 255 autres valeurs n’entrent plus en collision avec des commandes isolées.
  • Une donnée littérale de valeur 255 s’écrit IAC IAC. L’option Binary ouvre les huit bits, mais ne désactive jamais le parseur Telnet : IAC et les commandes intégrées restent actifs.

Deux occurrences sur le fil redevenaient une donnée

Un fichier binaire contient l’octet 255. Pour un récepteur Telnet, cette même valeur signifie « interpréter ce qui suit comme commande ». La traiter toujours comme contrôle mutile le fichier; la traiter toujours comme donnée rend les changements de protocole invisibles.

Telnet partage une grammaire simple. IAC seul ouvre une séquence de contrôle. IAC suivi d’un code défini exécute une commande, éventuellement complétée par d’autres octets. IAC suivi d’IAC produit une seule donnée 255. L’émetteur ajoute la copie de cadrage; le récepteur reconnaît la paire et n’en livre qu’une à l’application.

Ce n’est pas un QUOTE universel signifiant que tout octet suivant devient littéral. Le second IAC possède précisément cette signification. Les autres valeurs après IAC gardent leur rôle de commande. Le bénéfice dépasse un cas particulier : données et contrôle restent ordonnés dans la même connexion sans abandonner la moitié de l’alphabet binaire.

Le premier Telnet dépensait la moitié des valeurs

RFC 318, en avril 1972, attribuait 0 à 127 à l’USASCII et 128 à 255 aux signaux de contrôle Telnet. Le partage convenait à des terminaux textuels hétérogènes, mais compliquait les jeux de caractères plus riches et le binaire : la moitié des valeurs ne pouvait être une donnée ordinaire.

Le texte évoquait des passages vers d’autres codes, dont un mode Transparent, tout en reconnaissant que la persistance des signaux Telnet et le retour vers ASCII pouvaient rester indéfinis. En élargissant l’alphabet, on risquait de faire d’une nouvelle donnée une ancienne autorité de commande.

RFC 435, discussion de janvier 1973, envisagea un caractère QUOTE : l’octet suivant serait toujours une donnée, même dans la zone haute. Ce n’était pas encore le mécanisme IAC. La proposition révèle toutefois la contrainte : le cadrage devait survivre au changement de mode de données.

Un préfixe unique récupéra les autres valeurs

RFC 764, en 1980, définit une communication orientée octets huit bits sur une connexion TCP, où le contrôle Telnet est intercalé avec les données. RFC 854, norme de base de 1983, conserva ce modèle.

Toute commande commence par IAC, valeur 255, puis son code. WILL, WON’T, DO et DON’T ajoutent un octet d’option. D’autres codes marquent la fin d’une sous-négociation, l’absence d’opération, une interruption ou une autre fonction de base.

Le texte justifie le choix : quand les options permettent d’utiliser davantage l’espace des données, les collisions doivent rester rares. Seul IAC est doublé lorsqu’il est donnée; les 255 autres valeurs passent sans être prises pour des commandes Telnet à cause de leur nombre.

Cette transparence est étroite. Le NVT applique encore ses conventions de caractères et de lignes. Elle signifie que l’autorité de commande appartient à une séquence commençant par un point d’entrée, non à toute une région de valeurs nues.

L’ordre du flux fixait le moment du changement

RFC 854 demande qu’une commande d’option modifiant le traitement des données soit insérée à l’endroit exact où l’émetteur souhaite que la nouvelle interprétation commence. Le contrôle n’arrive pas par un canal latéral : il se trouve entre le dernier octet de l’ancien régime et le premier du nouveau.

Cette précision impose un état au parseur. TCP peut livrer IAC dans une lecture et son successeur dans la suivante; une limite de segment n’est pas une limite Telnet. Le récepteur doit attendre sans inventer un résultat. Il doit aussi décoder une seule fois : conserver les deux IAC ajoute une donnée, tandis que réduire une vraie commande comme si elle était la paire supprime le contrôle.

TCP conserve l’ordre. Telnet donne la syntaxe. Aucun des deux ne transforme spontanément le flux en messages.

La sous-négociation resta sous la garde d’IAC

RFC 855 encadre les paramètres d’une option par IAC SB et IAC SE. Même un récepteur ignorant leur structure peut rechercher la fin. Si un paramètre contient 255, il faut le doubler selon la règle générale.

Cette obligation empêche une donnée opaque de fabriquer un faux début ou une fausse fin de syntaxe. L’option maîtrise la signification de ses paramètres; la couche Telnet conserve la maîtrise du cadrage IAC. Une extension ne peut s’approprier silencieusement la valeur qui protège le flux partagé.

L’ignorance devient ainsi bornée. Le parseur de base peut franchir une option inconnue tant que l’émetteur a correctement échappé ses 255 littéraux.

Le binaire libéra huit bits, pas le contrôle

RFC 856 définit l’option Binary Transmission, numéro 0, négociée séparément dans chaque direction. Après accord, les octets qui ne sont pas précédés d’IAC sont interprétés comme données huit bits. Cependant IAC IAC reste la donnée 255 et une commande IAC valide reste une commande.

Le mode binaire ne signifie donc pas « TCP brut ». Il retire les transformations textuelles du domaine des données, mais garde l’invariant de cadrage Telnet. Sans le préfixe unique, il faudrait échapper toute la moitié haute ou renoncer aux commandes au moment où l’on en aurait encore besoin.

RFC 1123 rendit ce point obligatoire en 1989 : les options peuvent apparaître partout, donc IAC donnée doit être doublé; même en Binary, le flux doit être parcouru, les commandes obéies et les 255 littéraux doublés. Les conversions CR cessent, pas le parseur.

Une valeur identique ne crée pas un rôle identique

Le registre IANA des options Telnet répertorie notamment Binary à l’option 0. Il ne mesure pas le déploiement. Il rappelle aussi une distinction : l’option numérotée 255 appartient à l’espace des options, alors qu’IAC 255 appartient au cadrage du flux. L’égalité numérique ne fusionne pas les fonctions.

L’application choisit les données. L’émetteur Telnet encode leur 255 afin qu’il n’acquière pas par accident une autorité. Le récepteur Telnet distingue la paire de la commande. Aucune inspection centrale ni deuxième connexion n’est nécessaire.

Le coût demeure : chaque implémentation scrute le flux, chaque 255 littéral prend deux octets, un préfixe incomplet exige de la mémoire et une erreur peut désynchroniser toute la suite. Le gain demeure aussi : une instruction et une donnée peuvent partager l’ordre sans partager par accident le pouvoir.

L’octet se répétait non pour devenir deux données, mais pour que la première occurrence abandonne l’autorité de commande et que la seconde puisse rester une donnée.

Sources et limites

Le partage initial vient de RFC 318, la discussion QUOTE de RFC 435. RFC 764 et RFC 854 établissent le flux et IAC; RFC 855 la sous-négociation; RFC 856 le binaire; RFC 1123 les exigences d’hôte; le registre IANA l’espace des options. Ils ne prouvent ni déploiement actuel, ni conformité d’un produit, ni sûreté du parseur, chiffrement ou authentification.