Résumé

  • La RFC 933 a proposé l’option Telnet 27, OUTMRK, afin qu’un serveur envoie une bannière une fois et que le client la maintienne hors de la zone de l’application.
  • L’accord WILL/DO portait sur l’usage de l’option ; le texte concret recevait encore un ACK ou un NAK, puis le client gérait lui-même la géométrie de l’écran.
  • L’accusé de réception ne prouvait ni la justesse du niveau, ni l’habilitation de l’utilisateur, ni l’autorisation d’une commande, ni la persistance réelle de la bannière.

En janvier 1985, S. Silverman publie la RFC 933, Output Marking Telnet Option. Le besoin décrit est très matériel : dans certains systèmes militaires, chaque connexion Telnet correspond à un niveau de sécurité et l’écran doit en porter la mention. Or le serveur ajoutait alors cette bannière dans chaque page de données applicatives.

Cette répétition obligeait le logiciel distant à connaître la taille du terminal. Un effacement d’écran ou un déplacement du curseur pouvait aussi supprimer la mention. La proposition inverse le partage du travail : le serveur transmet le texte et sa position une fois ; le User-Telnet, au plus près du dispositif, réserve l’espace et y contraint ensuite l’affichage applicatif.

Le nom de l’option est OUTMRK, son code 27. Le registre IANA des options Telnet conserve cette affectation. Il coordonne un numéro ; il ne certifie ni la source de la bannière, ni son contenu, ni l’existence d’un déploiement.

Deux consentements, trois décisions

La première étape reprend la grammaire de la RFC 854. WILL OUTMRK offre l’envoi de données de marquage, DO OUTMRK accepte de les recevoir. WON'T et DON'T refusent, ce qui reste l’état par défaut.

Ce premier couple signifie que les deux Telnet comprennent la convention. Il n’approuve pas encore une inscription précise. Le serveur envoie ensuite IAC SB OUTMRK CNTL data IAC SE : un drapeau de placement et une chaîne ASCII. Le client répond par ACK, caractère ASCII 6, si la proposition lui convient ; sinon par NAK, caractère 21.

Après NAK, la RFC laisse au serveur le choix : proposer une donnée « plus acceptable » ou agir autrement, jusqu’à interrompre la connexion. Elle ne fait pas d’un refus une preuve automatique d’incident. De même, ACK ne vaut que pour cette proposition de marquage.

La RFC 855 éclaire la séparation : accepter de discuter une option précède l’échange de ses paramètres dans SB/SE, et chaque partie peut encore abandonner avec WON'T ou DON'T. Ici, il faut donc distinguer l’accord de capacité, l’acceptation de la bannière et la permission d’agir dans l’application.

Le poste de travail recevait une garde d’affichage

Après ACK, le client devait traduire les commandes de curseur afin que le flux de l’application reste dans sa portion de l’écran. La bannière n’était plus un paragraphe ordinaire du serveur : elle devenait un état local que le terminal devait protéger.

Le drapeau D laissait le placement au client. T et B demandaient le haut ou le bas. L et R évoquaient les côtés, mais le texte reconnaissait que leur sens précis restait à définir. L’interopérabilité du code 27 n’effaçait donc ni la diversité des terminaux ni l’inachèvement de la géométrie.

CRLF séparait les lignes. Plusieurs marques pouvaient voyager dans une même sous-négociation, séparées par le caractère ASCII Group Separator. La responsabilité finale du positionnement demeurait chez User-Telnet.

Une capture réseau peut dès lors montrer une négociation correcte et un ACK, tandis qu’un redimensionnement ultérieur, une séquence d’effacement ou un défaut d’émulateur recouvre la bannière. L’événement sur le fil et l’état visuel doivent être observés séparément.

La convention disposait aussi d’une sortie. Le serveur envoyait WON'T OUTMRK pour arrêter le marquage. Le client pouvait demander l’option par DO, puis répondre DON'T si l’échange annoncé n’était pas suivi des données attendues. La persistance n’était pas une commande irrévocable.

Un marquage n’était pas le moteur de la politique

La motivation de la RFC renvoie aux critères américains d’évaluation des systèmes de confiance. La copie officielle conservée par le NIST du DoD 5200.28-STD, publiée en décembre 1985, est postérieure à la RFC et remplace l’édition de 1983 que celle-ci citait. Elle ne permet donc pas de prétendre que RFC 933 réalisait tout le standard.

Elle montre toutefois une frontière essentielle. Le marquage lisible des sorties doit représenter leur sensibilité et les dérogations doivent être auditables. Le contrôle d’accès obligatoire figure ailleurs et décide, à partir des sujets, objets et dispositifs, quels accès sont permis. Présenter le niveau et imposer la règle sont deux fonctions liées, non une seule.

OUTMRK ne définit aucune signature, intégrité cryptographique, fraîcheur, liaison au canal, nomenclature des niveaux ou mécanisme d’authentification. Une bannière conforme à la syntaxe peut être du mauvais niveau, être attachée à la mauvaise session ou être perdue après l’ACK. Sa valeur dépend de la chaîne qui produit le niveau, génère le texte, associe la connexion et protège l’affichage.

La bannière reste utile : elle peut avertir d’un contexte inattendu et réduire le mélange de données. Mais son autorité ne vient pas de ses caractères. Elle vient de la politique et des contrôles vérifiables auxquels ces caractères renvoient.

L’économie du serveur devenait une dette du client

En n’insérant plus la bannière dans chaque page, le serveur économisait de la répétition et cessait de deviner la hauteur du terminal. Le client héritait en échange d’un actif durable : mémoriser le texte, réserver la zone, remapper le curseur, gérer plusieurs marques et conserver l’ensemble pendant les changements de taille.

Un journal disant seulement « OUTMRK activé » ne suffit pas. Il faut connaître le texte proposé, la réponse, la position, la durée d’affichage, l’autorité qui a fixé le niveau et la décision d’accès qui a suivi. Sans cette chaîne, une couleur ou une ligne familière finit par recevoir une autorité que le protocole ne lui a jamais donnée.

La leçon de la RFC 933 est donc plus vaste que son option peu connue. Porter une contrainte humaine jusqu’à une surface distante exige plusieurs gardiens. Le serveur garde la proposition, le client garde la présentation, le système de sécurité garde l’accès. Aucun accusé de réception ne fusionne ces mandats.

Sources et limites

Cette analyse repose sur la RFC 933, la RFC 854, la RFC 855, le registre IANA Telnet et l’archive officielle NIST du DoD 5200.28-STD. Ces sources établissent la proposition et sa motivation, non son déploiement, sa prise en charge actuelle, la conformité d’un produit, un rendu réel, la compréhension d’un utilisateur ou le résultat d’une session.