Résumé

  • La RFC 1041 avait conçu l’option unique 3270-REGIME. La RFC 1576 constate qu’elle fut très peu implémentée et documente la pratique installée : Terminal-Type, Binary et EOR négociés séparément.
  • Ce trio suffisait à reconnaître un mode de présentation et à délimiter les blocs 3270. Il ne nommait pas l’unité logique, n’exposait pas le BIND SNA et ne ramenait pas de réponse positive ou négative sur le traitement.
  • TN3270E ajouta ensuite ces informations comme fonctions distinctes et facultatives. Leur négociation ne constituait toujours ni une authentification, ni une preuve d’action humaine ou métier.

La façade fonctionnait avant que sa frontière soit écrite

Le terminal 3270 ne ressemblait pas au terminal virtuel de Telnet. Ses échanges étaient structurés par blocs et utilisaient EBCDIC. Pour transporter ce régime sur une connexion TCP, il fallait donc convenir de la représentation des octets, reconnaître le modèle de terminal et savoir où finissait chaque commande complète.

La RFC 1041 proposa en 1988 de réunir ces décisions sous l’option 29, 3270-REGIME. Le client aurait transmis une liste ordonnée de régimes, le serveur en aurait choisi un, et cet accord aurait entraîné l’usage du binaire et du séparateur IAC EOR. Une liste vide permettait de revenir au mode NVT ASCII.

Le texte définissait même le passage d’un monde à l’autre. Le client devait cesser d’accepter des données de l’utilisateur pendant la négociation. Le serveur devait épuiser les données en attente avant d’annoncer le nouveau régime. Le moment d’envoi ou de réception de la réponse déterminait quand chaque côté changeait d’interpréteur. Le vidage des files pouvait être nécessaire. La RFC savait qu’un même octet change de sens si l’étiquette de régime est appliquée trop tôt.

Six ans plus tard, la RFC 1576 dressa un constat plus prosaïque : très peu de développeurs et de fournisseurs avaient adopté cette option. Sa fiche officielle classe le document de janvier 1994 comme Informational. Elle n’effectue pas un recensement universel ; « très peu » ne signifie pas « aucun ». Mais la réalité installée exigeait une description différente.

Le régime réel tenait sur trois accords

TN3270 traditionnel réemployait des briques existantes. Terminal-Type permettait au serveur de demander les émulations disponibles et au client d’en annoncer une. Binary Transmission autorisait les octets sur huit bits. End of Record fournissait la séquence qui fermait le bloc. La spécification Telnet restait le cadre commun.

Aucune de ces options ne signifiait isolément TN3270. Leur composition le faisait. L’ordre de négociation n’était pas déterminant selon la RFC 1576 ; le régime devenait utilisable quand le type 3270 approprié, Binary et EOR étaient tous en place. Si le serveur retirait ensuite Binary ou EOR, le client devait traiter les données suivantes comme du NVT ASCII.

Cette convention était efficace parce qu’elle promettait peu. Binary protégeait la forme des octets. EOR indiquait la fin d’un message. Terminal-Type annonçait une émulation. Le serveur restait libre de raccorder cette façade à une application centrale par SNA ou par une autre méthode.

Le type annoncé n’était pas l’identité logique

Terminal-Type organisait une négociation asymétrique. Le serveur questionnait ; le client répondait et pouvait parcourir plusieurs possibilités. L’annonce d’un type pouvait obliger le client à changer d’émulation, sous réserve des autres prérequis. Sa réception n’imposait toutefois aucun changement immédiat au traitement du serveur.

Un nom comme celui d’un modèle 3278 décrivait donc un format d’affichage et une taille d’écran. Il n’identifiait pas le matériel réel, l’utilisateur ou la Logical Unit située derrière la passerelle. Même le suffixe -E, destiné à signaler la capacité de traiter des structured fields, recevait des interprétations variables chez les serveurs.

Dans un réseau SNA, un terminal entretenait normalement une session avec l’application et une autre avec le System Services Control Point. Le client TN3270 ne voyait qu’une connexion Telnet. Il n’avait aucun moyen défini de demander un nom de dispositif précis ou d’apprendre le LU name attribué par un serveur connecté en SNA. La RFC 1576 qualifie l’adresse IP du client de chose la plus proche d’un LU name. La proximité ne crée pas l’équivalence : l’adresse situe l’extrémité IP, tandis que le LU name désigne une ressource logique dont l’application centrale peut dépendre.

EOR fermait le bloc, pas l’enquête

Le flux 3270 n’offrait pas de longueur extérieure pour chaque commande. IAC EOR disait donc au récepteur : le bloc est complet, l’analyse peut commencer. C’est un reçu de structure important. Ce n’est pas un reçu de traitement.

La RFC 1576 énumère précisément l’absence du mécanisme de réponses SNA. Une réponse positive aurait indiqué que les données reçues précédemment avaient été traitées. Une réponse négative aurait pu signaler une commande invalide ou une panne mécanique du côté client. TN3270 traditionnel supposait plutôt que les données étaient traitées ou ignorées, sans transmettre cette différence.

La chaîne doit rester ouverte : segment TCP reçu, octets reconstruits, EOR observé, commande acceptée par l’émulateur, affichage ou impression produits, réponse de l’application et effet humain ne sont pas un seul événement.

Un NOP Telnet ou Timing Mark pouvait tester la présence de la session. Le NOP n’appelait aucune réponse applicative ; la disparition anormale du client pouvait se révéler par une erreur d’envoi TCP. Cette observation n’établissait ni la santé de l’application, ni la présence d’une personne devant l’écran.

ATTN et SYSREQ révélaient la traduction locale

ATTN devait souvent interrompre le traitement en cours. Beaucoup de clients l’associaient à Telnet BREAK, puis le serveur traduisait cette commande vers l’environnement SNA. Un serveur représentant un dispositif non-SNA pouvait l’ignorer.

SYSREQ était encore moins uniforme. Certains serveurs lisaient Telnet Interrupt Process ; d’autres attendaient une touche Test Request. Dans SNA, l’action pouvait basculer entre la session applicative et la session SSCP. Comme le format SSCP n’arrivait pas directement au client, le serveur devait le convertir, l’absorber ou ne pas offrir la fonction.

Une touche enfoncée, une commande Telnet émise, une traduction de passerelle, un événement SNA et une application interrompue réclamaient ainsi des traces distinctes. Le premier geste n’avait pas autorité pour prouver les suivants.

TN3270E remit des noms sur les faits manquants

Les RFC 1646 et RFC 1647 décrivirent rapidement des extensions. La RFC 2355, dont la fiche RFC Editor conserve le statut Standards Track de 1998, les rassembla dans TN3270E.

Le nouveau dispositif séparait deux négociations. La première portait sur le type et, éventuellement, sur une ressource ou un nom de dispositif demandé. Le serveur pouvait accepter et retourner le nom attribué, ou refuser avec une raison : nom inconnu, dispositif déjà utilisé, incohérence entre type et nom. Ensuite seulement venait la liste des fonctions.

BIND-IMAGE pouvait informer le client de l’ouverture et de la fermeture de la session SNA avec l’application. RESPONSES ajoutait un en-tête, une politique de réponse et un numéro de séquence afin de rattacher le verdict au bon bloc. SYSREQ et les fonctions d’imprimante demeuraient séparés. La liste négociée pouvait être vide ; ce cas s’appelait basic TN3270E.

Le silence gardait plusieurs sens. Un message pouvait demander aucune réponse, une réponse seulement en cas d’erreur ou une réponse systématique. Sans RESPONSES, le numéro de séquence ne prouvait rien. Sans BIND-IMAGE, l’option TN3270E ne révélait pas magiquement le BIND. Et si un pair refusait TN3270E, le mode traditionnel restait possible.

La RFC 2355 indique enfin que ces extensions n’ajoutaient aucune sécurité au Telnet ordinaire. L’autorisation d’utiliser un nom de dispositif restait une question d’authentification et de politique, indépendante de l’attribution technique.

Le code qui tourne ne possède pas toute la réalité

La chronologie ne distribue pas une médaille entre texte et pratique. RFC 1041 proposait une transition nette, mais n’avait pas acquis l’adoption attendue. TN3270 traditionnel réduisait le coût de compatibilité, mais omettait des reçus. TN3270E rendit ces reçus négociables sans prétendre effacer les installations plus anciennes.

L’essai de Heng Lu sur la primauté du code qui tourne impose d’observer ce que les systèmes faisaient réellement. Son texte sur la spécification minimale et les décisions locales aide à comprendre la valeur du trio : une petite grammaire commune, des choix laissés aux extrémités. Sa réflexion sur les couches de réalité interdit toutefois de confondre émulation, session, identité et résultat. Cette lecture est éditoriale et rétrospective ; elle n’attribue pas ces formulations aux auteurs des RFC.

Trois options ont rendu le terminal utilisable. Chacune doit rester dans son périmètre : le type décrit une présentation, Binary préserve des octets, EOR ferme un bloc. Le LU, le BIND, le traitement, l’interruption et l’effet final attendent leurs propres preuves.

Sources