Résumé

  • La RFC 1116 déplaçait vers le client l’édition de ligne et une partie du traitement des signaux. Le réseau ne voyait plus chaque touche, ce qui réduisait le délai ressenti et le nombre de paquets.
  • L’accord DO/WILL autorisait la sous-négociation ; MODE_ACK alignait un masque de mode ; SLC_ACK confirmait une association de caractère. Aucun de ces accusés ne portait sur l’exécution d’une commande.
  • Une fin de ligne ou un caractère de transmission rendait irréversible une partie du tampon local. Il restait encore à transporter, décoder, accepter et exécuter les données côté serveur.

La sensation de proximité venait du client

La RFC 1116 partait d’un coût visible. En Telnet caractère par caractère, quelques paquets pouvaient accompagner chaque frappe. En Linemode, quelques paquets suffisaient pour une ligne de commande. Sur un lien à forte latence, l’utilisateur retrouvait une réponse immédiate pendant la saisie et ne subissait le trajet qu’après avoir terminé. Sur un réseau facturé au paquet, l’économie était également directe.

Le déplacement ménageait aussi les ordinateurs distants. Un frontal pouvait absorber l’effacement, la réimpression et les caractères isolés au lieu d’interrompre un superordinateur pour chaque touche. Linemode était donc une décision d’architecture : le bord devenait responsable d’une partie de l’expérience.

La fiche du RFC Editor conserve la proposition d’août 1989 et son remplacement. L’IETF Datatracker en donne le contexte documentaire. La RFC 1184, publiée en octobre 1990, a rendu la RFC 1116 obsolète, ajouté des modes et des fonctions d’édition visuelle, sans effacer la séparation entre édition locale et traitement distant.

Accepter l’option n’activait pas encore l’édition

La grammaire générale de la RFC 855 impose deux temps. DO et WILL établissent que les deux parties acceptent de discuter d’une option. SB et SE encadrent ensuite les paramètres. DONT ou WONT peuvent retirer cette permission.

Pour Linemode, le défaut était précisément WONT et DONT. L’existence d’une connexion Telnet, voire la connaissance du numéro 34, ne disait donc rien du lieu effectif de l’édition. Le couple DO/WILL ouvrait la négociation ; il ne fixait pas son résultat.

Le sous-mode MODE ajoutait une autre étape. Normalement, le serveur demandait un masque et le client le confirmait. EDIT attribuait le traitement des lignes ; TRAPSIG décidait si les caractères d’interruption seraient traduits localement en commandes Telnet. MODE_ACK devait faire converger ces bits. Son objet était la configuration de deux processus Telnet, pas la ligne saisie par l’utilisateur.

Un journal sérieux ne fusionne donc pas « option admise », « EDIT actif » et « commande réussie ». Le premier est un consentement de protocole, le deuxième un état de traitement, le troisième une affirmation d’application.

« Terminée » qualifiait la ligne locale

Avec EDIT, le client conservait les caractères, appliquait les fonctions d’édition, puis transmettait la ligne achevée. Dans la RFC 1184, un terminateur local devient CR LF sur le fil. Jusqu’à ce seuil, l’utilisateur peut encore retirer ou remplacer les caractères sans demander au serveur d’annuler quoi que ce soit.

FORWARDMASK rendait le seuil plus riche. Le serveur pouvait nommer les caractères devant libérer le tampon. SLC_FORW1 et SLC_FORW2 en ajoutaient deux. Si le pilote de terminal local ne savait pas reproduire exactement le masque demandé, le client pouvait accepter tout en transmettant sur un ensemble plus large de caractères de contrôle.

L’accord ne produisait donc pas toujours une copie exacte de l’intention du serveur. Il autorisait une mise en œuvre locale compatible avec ses capacités. Une fois la partie du tampon envoyée, la RFC 1184 prévenait qu’elle n’était plus éditable.

Cette irréversibilité s’arrêtait au client. Les octets devaient encore traverser TCP, être reconnus comme données Telnet, atteindre le processus attaché, satisfaire sa syntaxe et sa politique, lancer éventuellement une opération et générer une réponse. La ligne locale n’avait aucun accès direct à ces faits.

SLC_ACK confirmait une règle de clavier

SLC associait une fonction, des modificateurs et un caractère ASCII. Le niveau déclarait la fonction absente, disponible mais immuable, assortie d’une valeur ou ramenée à une valeur par défaut. Quand une partie acceptait une proposition, elle renvoyait la même association avec SLC_ACK.

L’accusé n’était pas un reçu anticipé pour les futurs effets. Il disait que les pairs s’étaient accordés sur la manière d’interpréter une touche. Il ne disait pas que cette touche avait été frappée, que la commande Telnet correspondante avait atteint l’autre côté ni qu’un processus y avait réagi.

La RFC 1184 autorisait même l’ignorance d’ABORT, EOF ou SUSP lorsqu’un système ne fournissait pas la fonction. Les indications SLC_FLUSHIN et SLC_FLUSHOUT étaient consultatives et l’interface pouvait les outrepasser. Le nom d’une fonction et son transport ne suffisaient pas à prouver une interruption, une fin de fichier ou une purge.

L’écho et le flux ne témoignaient pas à la place du serveur

La RFC 857 sépare l’écho réalisé pour l’autre extrémité du choix d’un système d’émettre son propre écho. Un caractère visible immédiatement peut n’avoir quitté ni le clavier logique ni le client. L’affichage réactif était le bénéfice de Linemode, non un accusé de réception réseau.

Le contrôle de flux de sortie gardait aussi sa machine d’état. Les RFC 1116 et 1184 renvoyaient à l’option distincte de RFC 1080 pour décider si le processus Telnet local consommait XON et XOFF. Cette option n’était ni l’édition du clavier, ni l’arrêt d’une application, ni la fenêtre TCP, ni la congestion.

Ces frontières empêchaient un seul indicateur « terminal actif » de parler pour l’écho, le tampon, les signaux, la sortie et le processus distant.

Le résultat commençait après la frontière décrite par Linemode

Le registre IANA des options Telnet attribue toujours 34 à Linemode et cite la RFC 1184. Ce registre coordonne un code ; il n’observe aucune session et ne certifie aucun logiciel.

La RFC 854 fournit le NVT et les commandes de contrôle. Elle explique comment transporter des données et des signaux, non comment une application décide si une ligne est valide ou autorisée. La RFC 1184 ajoute d’ailleurs que les questions de sécurité ne sont pas discutées.

La chaîne de preuve doit donc rester longue : tampon achevé, préfixe transmis, octets arrivés, Telnet décodé, processus destinataire trouvé, entrée acceptée, opération commencée, résultat produit, réponse reçue et correctement rattachée. Linemode rendait les premières étapes moins coûteuses. Il ne signait pas les dernières.

Sources