RFC749 Option Telnet SUPDUP-OUTPUT Greenberg

Groupe de travail Réseau

Bernard Greenberg, MIT-Multics

Request for Comments : 749

18 septembre 1978

NIC 45499

Traduction Claude Brière de L’Isle



Option Telnet SUPDUP-OUTPUT



1. Nom et code de la commande


SUPDUP-OUTPUT 22


2. Signification de la commande


IAC WILL SUPDUP-OUTPUT

L’envoyeur de cette commande DEMANDE la permission de transmettre des messages au format SUPDUP-OUTPUT sur la connexion TELNET.


IAC WON'T SUPDUP-OUTPUT

L’envoyeur de cette commande DÉCLARE qu’il ne va plus envoyer de message au format SUPDUP-OUTPUT sur la connexion TELNET.


IAC DO SUPDUP-OUTPUT

L’envoyeur de cette commande accorde au receveur la permission d’envoyer des messages au format SUPDUP-OUTPUT sur la connexion TELNET.


IAC DON'T SUPDUP-OUTPUT

L’envoyeur de cette commande DEMANDE que le receveur n’envoie pas de message au format SUPDUP-OUTPUT sur la connexion TELNET.


IAC SB SUPDUP-OUTPUT 1 <paramètres du terminal> IAC SE

L’envoyeur de cette commande (qui doit être le processus utilisateur TELNET) fournit des informations décrivant les capacités du terminal du processus utilisateur.


IAC SB SUPDUP-OUTPUT 2 n TD1 TD2 .. TDn SCx SCy IAC SE

L’envoyeur de cette commande, qui doit être le processus serveur TELNET, envoie des informations explicites de contrôle d’écran à effectuer par le processus utilisateur TELNET.


3. Par défaut


WON'T SUPDUP-OUTPUT


DON'T SUPDUP-OUTPUT


C’est-à-dire que les messages au format SUPDUP-OUTPUT ne peuvent pas être transmis.


4. Motifs de l’option


Le protocole SUPDUP-OUTPUT fournit un moyen pour accéder à la prise en charge de l’affichage virtuel fourni par le protocole SUPDUP (voir la RFC734) dans le contexte d’une connexion TELNET standard. Cela permet à des programmes en mode affichage occasionnels sur des serveurs non orientés affichage de tirer parti du support d’affichage normalisé fourni par SUPDUP. Cela ne peut pas être fait avec le protocole SUPDUP standard ou l’option TELNET SUPDUP (RFC736) car ils exigent tous deux que toute communication après l’achèvement de la négociation pour l’utilisation de SUPDUP se déroule conformément au protocole de la RFC734. Cela donne au serveur la totale responsabilité de la gestion d’écran pour la durée de la connexion, que, par hypothèse, le serveur non orienté affichage ne veut pas accepter.


Les programmes utilisateurs TELNET sur les hôtes d’utilisateur orientés affichage fournissent la gestion d’écran locale en transposant la commande NVT en commandes de gestion d’écran locales ; souvent, cela implique le défilement, le traitement de fin de page, les passages à la ligne, etc. L’option SUPDUP-OUTPUT permet à un programme d’application en mode affichage chez le côté serveur de prendre explicitement en main la gestion d’écran, via le répertoire SUPDUP de contrôle d’affichage. TELNET reste en activité tout au long du processus. Le IAC IP et les autres commandes TELNET sont toujours valides.


Au moyen de l’option SUPDUP-OUTPUT, les programmes en mode affichage peuvent fonctionner sur l’hôte serveur, et contrôler explicitement l’écran de l’hôte utilisateur. Le processus TELNET utilisateur envoie une description du terminal utilisateur (comme spécifié dans la RFC734) au processus serveur TELNET comme bloc de sous négociation lorsque la négociation SUPDUP-OUTPUT a été menée à bien. Le processus serveur TELNET envoie des commandes de contrôle d’écran explicites via les blocs de sous négociation au processus utilisateur TELNET.


5. Description de l’option


Le protocole SUPDUP-OUTPUT ne peut être initialisé que par le processus serveur TELNET. Un processus serveur TELNET qui souhaite tirer parti du protocole SUPDUP-OUTPUT va initier sa négociation en envoyant IAC WILL SUPDUP-OUTPUT. Le processus utilisateur TELNET doit accepter ou refuser l’offre en envoyant IAC DO SUPDUP-OUTPUT ou IAC DON'T SUPDUP-OUTPUT.


Si le processus utilisateur TELNET est d’accord pour prendre en charge l’option SUPDUP-OUTPUT, il doit faire suivre immédiatement l’envoi de IAC DO SUPDUP-OUTPUT par une description du terminal de l’utilisateur. Ces informations sont décrites dans la RFC734 comme les "paramètres du terminal". Elles sont à envoyer comme une série d’octets de six bits, un octet par octet de données TELNET de huit bits. Ces mots peuvent contenir ou non la vitesse de ligne facultative et les paramètres de capacités graphiques décrits par la RFC747 ; les six premiers octets spécifient le compte de mots de 36 bits à suivre, comme décrit par la RFC 734.


Le bloc de paramètres du terminal sera envoyé comme une sous négociation de l’option SUPDUP-OUTPUT:


IAC SB SUPDUP-OUTPUT 1 octet1 octet2 ... octetn IAC SE


L’octet de "1" est un code de commande, pour la compatibilité avec les futures extensions. À réception du bloc de paramètres du terminal du processus utilisateur TELNET, le processus serveur TELNET peut envoyer des blocs SUPDUP-OUTPUT comme décrit ci-dessous.


Le processus serveur TELNET peut spécifier un contrôle explicite de l’écran de l’hôte utilisateur par l’envoi de blocs de sous négociation de l’option SUPDUP-OUTPUT. Le format d’un tel bloc, en octets de données TELNET de huit bits, est :


IAC SB SUPDUP-OUTPUT 2 N TD1 TD2 TD3 ... TDn SCx SCy IAC SE


L’octet de "2" est un code de commande, pour la compatibilité avec de futures extensions. Les octets TDm sont les "%TDCODE" et les caractères d’impression du résultat SUPDUP de la RFC734. N est un octet qui contient un compte du nombre de TDm dans cette transmission. N peut être zéro, et ne peut pas être supérieur à 254 (en décimal). SCx et SCy sont deux octets qui spécifient les coordonnées (respectivement) horizontales et verticales prévues pour le curseur de l’écran de l’hôte utilisateur après que ce dernier a interprété tous les %TDCODE dans cette transmission.


Le motif de la spécification de position d’écran SCx SCy est de permettre aux hôtes qui fonctionnent avec le système d’exploitation ITS, qui va transmettre les TDCODE directement dans le système de sortie local, pour attester de la position d’écran "au niveau du programme principal" sans aucune interprétation de la séquence TDCODE transmise par le programme utilisateur TELNET.


Le processus utilisateur TELNET doit gérer la position du curseur local par rapport aux commandes et au résultat standard TELNET NVT, et aux transmissions de SUPDUP OUTPUT. Le processus utilisateur TELNET peut supposer que le processus serveur TELNET gère les deux résultats NVT et SUPDUP-OUTPUT de façon intégrée.


L’option SUPDUP-OUTPUT ne prend pas position sur la façon d’envoyer le résultat ; cela peut être négocié via d’autres options. Par défaut, on utilisera l’entrée NVT. Les commandes de gestion d’écran d’utilisateur à serveur de la RFC734 NE SONT PAS implicitement traitées par IAC WILL SUPDUP-OUTPUT.


En l’absence de la transmission de blocs de sous négociation SUPDUP-OUTPUT, une connexion TELNET qui fonctionne avec l’option SUPDUP-OUTPUT activée ne peut pas se distinguer d’une connexion TELNET normale. Donc, IAC WON'T SUPDUP-OUTPUT est tout à fait facultatif, et, si il est reçu par le processus d’utilisateur TELNET, ne devrait être utilisé que pour provoquer un diagnostic si des blocs de sous négociation SUPDUP-OUTPUT sont ultérieurement reçus. Si on en reçoit, le processus utilisateur TELNET devrait répondre avec un IAC DON'T SUPDUP OUTPUT.


À cause de la nature facultative de IAC WON'T SUPDUP-OUTPUT, le processus utilisateur TELNET devrait être prêt à envoyer un bloc de sous négociation de paramètres de terminal à chaque fois qu’est reçu IAC WILL SUPDUP-OUTPUT, c’est-à-dire, même si le processus utilisateur TELNET croit que SUPDUP-OUTPUT est activé.


Le code %TDORS (réinitialisation de sortie) ne peut pas être envoyé dans une transmission SUPDUP-OUTPUT. Le programme d’utilisateur TELNET peut supposer qu’aucun octet d’un bloc de sous négociation ne sera 255 (en décimal).


Aucune séquence TDCODE multi-octets (par exemple, %TDMOV, %TDILP) ne peut être partagée entre des blocs de sous négociation SUPDUP-OUTPUT.


Références


[RFC0734] M. Crispin, "Protocole SUPDUP", octobre 1977. (Historique)


[RFC0736] M. Crispin, "Option Telnet SUPDUP", octobre 1977.


[RFC0747] M. Crispin, "Extensions récentes au protocole SUPDUP", mars 1978.


page - 3 -