Résumé

  • Le RFC 1043 décrit l’implémentation DODIIS, en 1988, de l’option TELNET Data Entry Terminal. Ses auteurs soulignent qu’une frappe en mode écho peut produire un datagramme vers l’hôte, puis un autre en retour.
  • Le terminal DET édite localement les champs accessibles d’un formulaire. Application et terminal négocient leurs fonctions communes, se passent la main avec GO-AHEAD et peuvent renvoyer seulement les champs « modifiés », catégorie qui inclut aussi certains champs marqués par l’application.

Deux voyages pour une seule lettre

L’introduction du RFC 1043 donne une mesure intuitive du gaspillage : une touche expédie un datagramme avec des en-têtes TCP/IP et son unique caractère ; le serveur renvoie un datagramme comparable pour l’écho. La Defense Intelligence Agency cherchait alors un accès plein écran aux applications sur un réseau à commutation de paquets. Le document déclarait des réalisations sur IAS, MVS, OS86 et UNIX, avec des développements pour VM et VMS. Des machines différentes devaient présenter à leurs usagers un formulaire cohérent. Faire approuver chaque touche par un hôte lointain était une drôle de manière de remplir une case.

L’option Data Entry Terminal figurait déjà dans le RFC 732. RFC 1043 répondait à un problème venu ensuite : plusieurs organismes de la communauté DODIIS avaient développé leurs propres implémentations, et leur interopérabilité inquiétait. Un terminal rapide avec lui-même, incompréhensible pour son voisin, promet surtout du travail supplémentaire au service d’assistance. Les auteurs ont donc fixé les règles communes, les fonctions minimales et la manière dont chaque extrémité négocie les capacités supplémentaires.

Le modèle était celui d’un appareil demi-duplex orienté formulaires. Un écran rectangulaire contenait des données protégées et des champs ouverts ; le clavier modifiait ces derniers sur le terminal. Des touches de fonction et la sélection de champs offraient d’autres réponses possibles. L’écran par défaut comptait 80 caractères sur 24 lignes, et les hôtes utilisateurs devaient pouvoir gérer de 24 à 48 lignes. L’application construisait les champs avec leurs positions, tailles, attributs et contenus. Une fois le formulaire prêt, elle envoyait GO-AHEAD, signal qui libérait le clavier. L’usager remplissait, validait ou pressait une touche autorisée ; le terminal renvoyait ses données et son propre GO-AHEAD. Chacun parlait à son tour, comme si le curseur passait d’une main à l’autre.

Cette discipline commençait avant le premier formulaire. DET était l’option TELNET numéro 20, négociée dans les deux directions au moyen de DO et WILL. Faute d’accord, l’état par défaut restait WONT DET -- DONT DET, et la connexion continuait en mode de terminal virtuel TELNET ordinaire. Le RFC demandait de refuser ou de terminer Echo, Suppress Go-Ahead et Binary lorsque DET était accepté, car ces options entraient en conflit avec ses règles. Une vieille habitude d’écho laissée active aurait parlé par-dessus le nouveau tour de parole.

L’accord sur DET ne donnait pas carte blanche à toutes ses fonctions. Quatre sous-commandes de « facilities » couvraient l’édition, l’effacement, la transmission et le format. Le terminal indiquait ses possibilités ; l’application, ses souhaits. L’intersection logique de leurs cartes définissait les fonctions permises pendant la session. Pour l’intensité de l’affichage, on prenait le niveau le plus bas annoncé. Une fonction facultative exigeait l’accord préalable, et l’un ou l’autre côté pouvait ensuite la retirer. Les bits réservés devaient partir à zéro, afin qu’une future extension ne soit pas acceptée par inadvertance.

Le texte demandait même de se souvenir de qui avait engagé la négociation : deux ordinateurs polis à l’excès peuvent répondre indéfiniment à leurs propres réponses.

Le retour du formulaire révélait l’économie recherchée. L’application pouvait demander l’écran entier, les champs non protégés ou les champs modifiés, par TRANSMIT-SCREEN, TRANSMIT-UNPROTECTED ou TRANSMIT-MODIFIED. En l’absence de demande explicite, les attributs Modified et Protection déjà négociés déterminaient une réponse par défaut aussi petite que le permettait le contrat. Le formulaire demeurait à l’écran pendant que l’application préparait une nouvelle étape. Les frappes restaient proches de l’usager jusqu’au moment de renvoyer des champs.

Le mot « modifié » cachait un piège. Avec TRANSMIT-MODIFIED, le terminal devait rendre les champs portant l’attribut Modified aussi bien que ceux effectivement changés par l’usager. Un champ revenu dans la réponse témoignait donc d’une règle de formulaire, parfois d’une intervention humaine. Le serveur avait besoin de connaître ce contrat avant de raconter ce que la personne avait fait. Le RFC plaça cette distinction dans un encadré d’avertissement : une petite lampe laissée au futur enquêteur.

Enfin, le minimum DET, utilisable sans négociation supplémentaire, ne suffisait pas aux formulaires DODIIS. Les hôtes utilisateurs devaient prendre en charge les sous-commandes prescrites et les attributs que leur matériel offrait ou que le logiciel pouvait aisément émuler. Les hôtes serveurs prenaient en charge ce que leurs applications réclamaient. Un tableau précisait qui envoyait, qui recevait, et quelles fonctions étaient conseillées. L’interopérabilité naissait de ce partage explicite, avec des terminaux qui gardaient leurs différences.

RFC 1043 a remplacé une rafale de petits échos par une conversation autour d’un formulaire. On édite localement, on convient des capacités, on renvoie les champs appropriés. La ligne devenait plus calme parce que les deux machines avaient appris à se mettre d’accord avant que l’usager n’appuie sur une touche.