Résumé

  • La RFC 1921 logeait trois flux adressés dans une connexion Telnet : écran, imprimante et impression de copie d’écran. Chaque adresse ne pouvait porter qu’une requête non soldée.
  • Une seconde requête prématurée était supprimée. La réponse PROTOCOL-VIOLATION correspondante ne partait qu’après la réponse à la première requête, afin que l’ordre continue d’identifier les opérations.
  • EOR, le type de terminal et les codes ACK, BUSY, PURGED ou READY bornaient le protocole ; ils ne prouvaient ni l’identité de l’utilisateur, ni le résultat de l’application hôte, ni une feuille imprimée.

Trois guichets derrière une seule porte

La RFC 1921, publiée en mars 1996 avec le statut Informational, décrivait TNVIP, un profil Telnet destiné à l’émulation des terminaux VIP de Bull. Ces appareils fonctionnaient par blocs et pouvaient associer un écran à une imprimante. Le serveur jouait souvent le rôle de passerelle vers un Terminal Manager DSA.

Une connexion TCP ne suffisait donc pas à décrire ce qui se passait. TNVIP commençait chaque message par un en-tête de deux octets. Le premier désignait le guichet : 0x60 pour l’écran, 0x68 pour l’imprimante, 0x69 pour la copie d’écran imprimée. Le second portait la commande et, dans ses deux bits de poids faible, la nature du mouvement.

Une indication n’attendait pas de réponse. Une requête ouvrait une attente. Une réponse la fermait. Une réponse-requête fermait positivement l’affaire courante tout en en ouvrant une autre dans l’autre sens. Le protocole n’avait pas un unique état « terminal occupé » : il maintenait trois conversations locales sur le même transport.

Le numéro absent fut remplacé par une règle d’ordre

TNVIP ne joignait pas d’identifiant de transaction général. Il imposait plutôt une condition : aucune nouvelle requête ne pouvait être envoyée sur une adresse tant que la précédente n’avait pas reçu sa réponse.

Si cette condition était violée, le récepteur supprimait la seconde requête. Pourtant, il ne répondait pas immédiatement. Il devait d’abord envoyer la réponse due à la première, puis signaler PROTOCOL-VIOLATION pour la seconde. L’avis d’infraction était retardé afin de ne pas se faire passer pour le résultat de l’opération encore pendante.

Cette séquence conserve une qualité rare : elle dit que les données ont été perdues, sans inventer une file d’attente. BUSY ou PROTOCOL-VIOLATION ne signifie pas « votre travail attend ». L’émetteur doit décider s’il convient de reconstruire et de renvoyer l’opération après avoir identifié le résultat initial.

Le contraste avec LDAP est utile. LDAP a permis à plusieurs opérations de s’entrelacer et leur a donné des Message IDs. TNVIP a économisé ce marquage en limitant le parallélisme par adresse. Les deux architectures répondent au même besoin d’association, mais ne possèdent ni le même état partagé ni le même régime de concurrence.

Le modèle annoncé n’était pas une identité certifiée

Avant l’échange TNVIP, le client et le serveur devaient négocier avec succès Terminal-Type et l’option End-of-Record. Le type indiquait un modèle VIP pris en charge. Il pouvait ajouter @Mailbox-name, nom d’un point d’accès particulier côté serveur ; sans suffixe, un accès générique restait possible. Dans une passerelle DSA, ce nom était limité à douze caractères et les minuscules étaient traitées comme des majuscules.

Ce routage logique n’authentifiait rien. Un client pouvait annoncer une forme de terminal et demander un Mailbox ; le serveur pouvait reconnaître la syntaxe. Cela ne démontrait ni la présence de l’appareil physique, ni le droit de la personne à utiliser ce point d’accès. La section de sécurité de la RFC déclarait que ces questions n’étaient pas traitées et renvoyait à de futurs mécanismes d’authentification.

L’option Binary Transmission n’était nécessaire que si l’émulation exigeait huit bits de données. Suppress-Go-Ahead pouvait supprimer l’usage du signal Telnet GA lorsque le tour DSA ou le jeton de session n’en dépendait pas. RFC 856 et RFC 858 expliquent ces outils. Ils règlent la lecture des octets et l’invitation à émettre, pas l’autorisation d’un acteur.

Une bordure de message n’était pas un résultat

Les terminaux VIP construisaient un bloc avant de l’envoyer. TNVIP utilisait donc IAC EOR à la fin de chaque message. RFC 885 fournit cette option au-dessus du Telnet de RFC 854.

Une limite de bloc permet au récepteur de savoir quels octets appartiennent ensemble. Elle ne dit pas si l’écran les a traités, si le tampon de l’imprimante les a acceptés ou si l’application DSA a obtenu un résultat. C’est précisément pour cela que TNVIP avait besoin de réponses applicatives distinctes.

La RFC recommandait aussi de placer les commandes Telnet entre les messages TNVIP. Une commande insérée à l’intérieur d’un bloc pouvait être appliquée immédiatement ou après le traitement du message, selon l’implémentation. EOR bornait les octets ; il ne fixait pas à lui seul l’ordre entre contrôle Telnet et opération TNVIP.

Le code de réponse empruntait son sens au flux

ACK n’était pas une médaille universelle. Sur le flux écran, il pouvait confirmer que les données précédentes avaient été bien traitées, ou accuser réception d’une demande de passage en mode LOCAL. BUSY sur ce même flux disait que les données avaient été supprimées parce que le terminal était local.

Sur le flux imprimante, BUSY avait une autre cause : la requête précédente n’était pas terminée et les nouvelles données étaient supprimées. READY répondait à une interrogation d’état de l’imprimante, non à un envoi de données. Les autres réponses conservaient leurs propres contours : ERROR, ABORTED, PURGED, NOT-AVAILABLE, UNKNOWN-COMMAND et PROTOCOL-VIOLATION.

Le protocole traitait même différemment l’inconnu selon sa forme. Une indication inconnue pouvait être éliminée sans réponse ; une requête inconnue avait ouvert une attente et appelait donc un résultat explicite. Un journal qui ne conserve que le mot final perd l’adresse, la question en cours et la raison de l’échec.

Le mode LOCAL fermait deux flux, pas le monde

Avant d’entrer en mode LOCAL pour des tests ou une configuration sur place, le client envoyait une requête LOCAL-STATE. Après l’avoir acquittée, le serveur devait suspendre ses flux d’écran et d’imprimante jusqu’à une indication ONLINE-STATE.

Si des données descendantes arrivaient malgré tout, le client les supprimait. Une requête d’écran pouvait recevoir BUSY. Le TCP fonctionnait, le message avait une bonne adresse et un EOR valide, mais la politique locale prescrivait sa disparition.

Le mode n’interdisait pas tout échange. Les messages partant de l’écran client, ainsi que ceux d’autres adresses, restaient possibles. La bonne unité d’observation n’était donc ni la machine entière ni la connexion entière : c’était la direction et le flux concernés par la transition d’état.

Imprimer la copie exigeait deux décisions

L’imprimante pouvait être partagée et administrée par le serveur. Lorsqu’un utilisateur souhaitait imprimer une copie de l’écran, le client envoyait COPY-REQ sur le troisième flux. Le serveur pouvait répondre LOCAL-COPY.

Ce message était à la fois réponse et requête. Il accordait l’autorisation de commencer, puis attendait un résultat : ACK, ERROR, BUSY, ABORTED, PURGED ou NOT-AVAILABLE. Une permission n’était pas une impression. Un retour de protocole n’était pas une observation de la feuille. La RFC organisait la coordination d’un périphérique ; elle ne plaçait aucun témoin humain au bout du papier.

L’article existant sur la RFC 1318 s’arrête plus bas, aux signaux physiques Power, Online, Busy, PaperOut et Fault d’une interface parallèle. Le présent mécanisme porte sur l’admission et l’ordre des requêtes à distance. Les deux sujets touchent une imprimante, mais ils n’observent ni la même surface ni le même événement.

Une purge tardive ne réécrivait pas le passé

Chaque flux prévoyait une indication de purge. Tant que la requête n’avait pas encore été acquittée, le récepteur tentait d’en interrompre le traitement et renvoyait PURGED. Après la réponse, la purge était ignorée et supprimée.

L’autorité d’annuler expirait donc avec le reçu. Cette règle empêchait un message tardif de transformer rétroactivement un succès ou un échec déjà annoncé. Elle ne garantissait pas que toute conséquence physique pouvait être annulée : si le périphérique ou l’application avait déjà agi, une preuve et un remède extérieurs au protocole restaient nécessaires.

La doctrine ultérieure de Running-Code Primacy permet de lire cette frontière sans l’attribuer aux auteurs : le document définit un état déterministe, l’implémentation l’exécute, le périphérique produit éventuellement un effet. Publication, exécution et résultat ne sont pas trois noms du même fait.

Ce que les documents ne racontent pas

RFC 1091 explique Terminal-Type ; RFC 1576 décrit les pratiques TN3270, sujet déjà traité sous un autre angle. Avec RFC 1921, ces textes établissent des formats et des transitions. Ils ne mesurent aucune adoption, ne certifient aucun produit Bull et ne décrivent aucun incident réel.

Ils ne prouvent pas davantage qu’un Mailbox avait le bon utilisateur, qu’un ACK atteignait une application métier ou qu’une page avait été imprimée. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption sert ici de règle de lecture contemporaine : rendre le noyau commun minimal et vérifiable, puis laisser l’état du périphérique et la décision future à ceux qui peuvent réellement les observer.

TNVIP obtint ainsi de la clarté non en affirmant davantage, mais en refusant qu’une réponse puisse appartenir à deux requêtes. Le second dossier disparut ; son erreur dut attendre ; le registre resta lisible.