Résumé

  • Le RFC 2066 exigeait ACCEPTED même lorsque le récepteur employait déjà un jeu demandé : le silence ne pouvait plus faire office d'acceptation.
  • Deux CHARSET REQUEST simultanés n'étaient pas traités symétriquement : le serveur rejetait la demande du client, tandis que le client devait répondre à celle du serveur.
  • Le reçu fixait l'encodage du texte suivant. Il ne prouvait ni la conformité des octets, ni la qualité de la traduction, ni le traitement applicatif, ni l'identité ou la sécurité de la session.

Un terminal Telnet propose deux jeux de caractères, puis n'entend plus rien. Le pair utilise peut-être déjà l'un d'eux et croit devoir rester silencieux. La demande a peut-être disparu. Ou le logiciel ne comprend pas correctement la sous-négociation. Pour l'émetteur, ces trois réalités produisent le même dossier : aucune réponse.

Publié comme protocole expérimental en janvier 1997, le RFC 2066 refusa de faire de cette ambiguïté un état partagé. Il définit l'option Telnet 42, CHARSET, afin que client et serveur puissent nommer l'encodage du texte et, facultativement, échanger des tables de traduction. Son choix décisif ne fut pas la variété des alphabets, mais l'obligation de clore la transition par un message observable.

La règle anti-boucle de base ne suffisait pas

Le RFC 854 organisait la négociation des options avec DO, DON'T, WILL et WON'T. La syntaxe était symétrique : deux demandes simultanées pouvaient chacune servir d'acquittement positif à l'autre. Cette élégance risquait aussi de produire des boucles sans fin. Une apparente demande pour un mode déjà actif ne devait pas être acquittée, tandis qu'une véritable demande de changement exigeait une réponse.

Le RFC 855 séparait ensuite l'accord de principe et la discussion des paramètres. Les parties acceptaient d'abord de parler d'une option par DO/WILL, puis échangeaient les valeurs entre IAC SB et IAC SE. DO CHARSET et WILL CHARSET ouvraient donc le droit de négocier ; ils ne déterminaient pas encore l'encodage du prochain octet de texte.

Le RFC 2066 interdit d'appliquer mécaniquement le silence à la demande de jeu de caractères. Si le récepteur envoyait et attendait déjà le texte dans l'un des jeux proposés, il devait répondre ACCEPTED et ne pouvait ignorer le message. Le texte donne la raison : la détermination. L'émetteur ne devait pas attendre un délai pour déduire un résultat. Comme ACCEPTED n'appelait aucune nouvelle réponse, l'explicitation ne relançait pas la boucle.

Une liste ordonnée n'était pas une injonction

Seule une partie ayant reçu DO CHARSET et envoyé WILL CHARSET, dans n'importe quel ordre, pouvait émettre CHARSET REQUEST. La liste comportait un ou plusieurs noms classés par préférence. Sauf préfixe privé X-, le nom devait être enregistré auprès de l'IANA. Le récepteur conservait son propre jugement de capacité et de préférence.

Quatre sorties bornaient l'échange : confirmer un jeu déjà utilisé ; accepter un autre jeu pris dans la liste ; envoyer une table si cette possibilité avait été offerte ; ou répondre REJECTED si aucun choix n'était supporté. ACCEPTED nommait un élément proposé. REJECTED confirmait la réception mais refusait toute la liste pour ce tour.

Les deux messages terminaient la sous-négociation. L'un rendait obligatoire l'encodage choisi pour le texte ultérieur ; l'autre empêchait les choix proposés d'entrer en vigueur. Aucun ne constituait un diagnostic général, et un refus n'interdisait pas une nouvelle proposition.

La collision avait besoin d'un perdant désigné

Si les deux parties autorisées envoyaient CHARSET REQUEST avant de recevoir celle de l'autre, la symétrie devenait un blocage. Une nouvelle demande n'était pas une réponse valable à la demande en cours. Chacune pouvait alors attendre la conclusion de sa propre proposition tout en détenant celle du pair.

Le RFC 2066 trancha par le rôle. Le serveur devait rejeter la demande du client ; le client devait répondre à celle du serveur. Une proposition était close, l'autre pouvait aboutir à ACCEPTED, REJECTED ou à une table. Cette règle n'accordait pas au serveur une préférence supérieure. Elle faisait calculer aux deux programmes la même transition à partir de rôles stables.

Le dialogue pouvait reprendre après un refus. Un serveur souhaitant que le client adopte le jeu de son application pouvait refuser la première liste et faire sa propre demande. Si le client la refusait, le serveur pouvait revenir à un jeu antérieurement offert. Chaque tour gardait toutefois son reçu final : la préférence évoluait, pas la frontière de preuve.

Le reçu marquait une frontière dans les octets

Après ACCEPTED, le texte suivant devait employer le jeu choisi. Pendant la sous-négociation, les données devaient être mises en attente et libérées après sa terminaison. L'acquittement séparait donc les octets encore régis par l'ancien accord de ceux régis par le nouveau.

La portée demeurait précise. La traduction concernait le texte, jamais les commandes Telnet, et ne s'appliquait qu'en mode BINARY. Sinon, les données restaient en NVT ASCII. Pour les terminaux en mode bloc, le RFC conseillait End of Record afin de garder une limite de registre visible. Choisir un alphabet ne remplaçait pas les autres contrats Telnet.

Les tables disposaient elles aussi de fins observables : TTABLE-ACK validait la réception, TTABLE-NAK demandait une retransmission, puis des échecs répétés devaient conduire à TTABLE-REJECTED ou CHARSET REJECTED plutôt qu'à un va-et-vient infini.

La force du reçu venait de sa petite portée

Une trace ACCEPTED permet d'affirmer que le pair a reçu telle demande et choisi l'un de ses noms pour le texte ultérieur. Elle ne montre pas que les octets ont respecté ce nom, que la table était exacte, que l'application a compris ou que l'utilisateur a terminé son travail. REJECTED établit réception et refus de ce tour, non une incapacité éternelle.

Le protocole n'ajoutait aucune aura de sécurité. La section Security Considerations indique seulement que les questions de sécurité ne sont pas discutées. Négocier un encodage n'authentifie pas les extrémités, n'autorise pas l'application, ne chiffre pas le flux et n'en garantit pas l'intégrité.

Le RFC était expérimental et l'IANA conserve aujourd'hui le numéro 42 pour CHARSET. Cela établit une publication et une attribution, pas le nombre de mises en œuvre. Relu par le cadre ultérieur de spécification initiale minimale de Lu Heng, ce contrat ressemble à une mince couche commune : conditions d'émission, réponses finales, point de transition et règle de conflit vérifiables localement. C'est une interprétation éditoriale tardive. Le constat historique plus étroit reste solide : lorsque le silence possède plusieurs significations, il faut transformer le reçu manquant en message de protocole.

Sources