Groupe de travail Réseau	C. Hedrick, Rutgers University	
Request for Comments : 1372	D. Borman, Cray Research, Inc.	
RFC rendue obsolète : RFC 1080	octobre 1992	
Catégorie  : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle	

Option Telnet de contrôle de flux à distance

Statut de ce mémoire
La présente RFC spécifie un protocole sur la voie de la normalisation approuvé par l'IAB pour la communauté de l'Internet, et qui appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l'édition en cours des "normes officielles de protocoles de l'IAB" pour l'état de normalisation et le statut de ce protocole. La distribution du présent mémoire n'est soumise à aucune restriction.

 	Introduction

Le présent document spécifie une extension à la version de l'option Telnet de contrôle de flux à distance de la RFC 1080, par l'ajout des sous options RESTART-ANY et RESTART-XON.

 	1.	Noms et codes de commande

TOGGLE-FLOW-CONTROL    33
OFF                                               0
ON                                                1
RESTART-ANY                          2
RESTART-XON                          3

 	2.	Signification des commandes

IAC WILL TOGGLE-FLOW-CONTROL  : l'envoyeur veut activer et désactiver le contrôle de flux avec la commande.

IAC WONT TOGGLE-FLOW-CONTROL  : l'envoyeur refuse d'activer et désactiver le contrôle de flux. Cela n'implique rien sur si l'envoyeur utilise ou non le contrôle de flux. Simplement il ne veut pas l'activer et le désactiver en utilisant ce protocole.

IAC DO TOGGLE-FLOW-CONTROL  : l'envoyeur veut envoyer des commandes pour activer et désactiver le contrôle de flux.

IAC DONT TOGGLE-FLOW-CONTROL  : l'envoyeur refuse d'envoyer la commande d'activer et désactiver le contrôle de flux.

IAC SB TOGGLE-FLOW-CONTROL OFF IAC SE  : l'envoyeur demande au receveur de désactiver le contrôle de flux.

IAC SB TOGGLE-FLOW-CONTROL ON IAC SE  : l'envoyeur demande au receveur d'activer le contrôle de flux.

IAC SB TOGGLE-FLOW-CONTROL RESTART-ANY IAC SE  : l'envoyeur demande que quand le contrôle de flux est activé, le receveur permette que tout caractère (sauf un autre XOFF) recommence à donner des résultats.

IAC SB TOGGLE-FLOW-CONTROL RESTART-XON IAC SE  : l'envoyeur demande que quand le contrôle de flux est activé, le receveur permette seulement au caractère XON de recommencer à donner des résultats.

 	3.	Spécification par défaut

La spécification par défaut pour cette option est  :

WONT TOGGLE-FLOW-CONTROL DONT TOGGLE-FLOW-CONTROL  : ce qui signifie que les informations de contrôle de flux ne seront échangées ni dans l'une ni dans l'autre direction.

 	4.	Motivation

Le présent mémoire décrit une méthode pour basculer à distance un contrôle de flux entre un processus d'utilisateur telnet et le terminal rattaché. Seul le contrôle de flux des données transmises à partir du processus telnet au terminal est considéré. De nombreux systèmes vont aussi permettre le contrôle de flux des données du terminal au processus telnet, cependant il est rarement besoin de changer ce comportement de façon répétée durant la session.

Il y a deux façons courantes de contrôler un flux : par le matériel et par le logiciel. Le matériel de contrôle de flux utilise des signaux sur des canaux dédiés à cette fin. Le logiciel de contrôle de flux utilise un ou deux caractères spécifiques envoyés sur le même chemin que les données d'entrée normales. Le plus couramment, XOFF (contrôle S) et XON (contrôle Q) sont utilisées pour respectivement arrêter et démarrer la sortie. L'option décrite ici est utile principalement lorsque un logiciel de contrôle de flux est utilisé. (Comme les matériels de contrôle de flux ne préallouent aucun caractère, il n'y a normalement pas besoin de le désactiver.) On notera aussi que le contrôle de flux peut être généré automatiquement par le terminal quand ses mémoires tampons sont prêtes à déborder, ou manuellement par l'utilisateur, quand il ne peut pas lire les informations aussi vite qu'elles sont affichées, et que les informations non lues vont commencer à se dérouler hors de l'écran.

La principale difficulté avec le logiciel de contrôle de flux est qu'il pré alloue un ou deux caractères. Les logiciels d'hôte exigent souvent que l'utilisateur soit capable de rentrer tout caractère ASCII possible. (Certains éditeurs sont connus pour avoir XOFF et XON comme commandes d'usage courant.) Pour cette raison, les systèmes d'exploitation permettent souvent que les programmes désactivent le contrôle de flux. Lorsque il est désactivé, les caractères qui signalent normalement le contrôle de flux peuvent être lus comme des entrées normales. Dans un environnement telnet, le contrôle de flux est normalement fait par le processus d'utilisateur telnet, et non par l'ordinateur hôte. De plus, sur de nombreux systèmes d'exploitation, quand le contrôle de flux est activé, l'utilisateur peut spécifier si le caractère XOFF est le seul caractère auquel il est permis de réactiver la sortie des données, ou si la frappe de tout caractère devrait réactiver le flux de données. Donc la présente RFC définit un moyen de propager l'état du contrôle de flux de l'ordinateur hôte au processus telnet d'utilisateur.

 	5.	Description de l'option

L'utilisation de l'option requiert deux phases. Dans le première, les processus telnet s'accordent pour que l'un deux fasse TOGGLE-FLOW-CONTROL. WILL et DO ne sont utilisés que dans cette première phase. En général il y aura seulement un échange de WILL et DO pour une session. Des sous négociations ne doivent pas être effectuées tant que DO et WILL n'ont pas été échangés. Il est permis à l'un et l'autre côté de désactiver l'option en envoyant un WONT ou DONT. Si cela arrive, aucune autre sous négociation ne peut être envoyée, sauf si l'option est réactivée par un autre échange de DO et WILL.

Une fois que les hôtes ont échangé un WILL et un DO, l'envoyeur du DO TOGGLE-FLOW-CONTROL est libre d'envoyer des sous négociations pour activer et désactiver le contrôle de flux dans l'autre procès, et d'envoyer des sous négociations pour des recommandations sur quand recommencer les sorties. Normalement, l'envoyeur du DO va être un hôte, et l'autre extrémité va être un processus d'utilisateur telnet, qui est connecté à un terminal. Donc le protocole est normalement asymétrique  ; cependant, il peut être utilisé dans les deux directions sans confusion si le besoin de le faire apparaissait.

Aussitôt que le DO et le WILL ont été échangés, l'envoyeur du WILL doit activer le contrôle de flux. Cela permet que le contrôle de flux commence dans un état connu. La décision de ne recommencer la sortie de résultats que quand le caractère XON est reçu ou quand un caractère quelconque est reçu, commence dans un état qui dépend du système. (Ceci est pour rester cohérent avec les plus anciennes mises en œuvre de l'option TOGGLE-FLOW-CONTROL qui ne comprennent pas les sous options RESTART-ANY et RESTART-XON.) L'envoyeur du DO devrait envoyer soit une sous option RESTART-ANY, soit une sous option RESTART-XON pour mettre les caractéristiques de redémarrage dans un état connu. Certains clients pourraient n'être pas capables de prendre en charge les deux modes de RESTART-ANY et RESTART-XON à cause de limitations du système, et choisiraient alors d'ignorer ces commandes. Il n'y a pas de moyen pour notifier cette condition au serveur, mais un client devrait tout tenter pour honorer l'état demandé par les modes RESTART-ANY et RESTART-XON. Si l'option devait être désactivée par l'échange de DONT et WONT, le contrôle de flux pourrait revenir à un état par défaut défini par la mise en œuvre. Il n'est pas sûr de supposer que le contrôle de flux va rester dans l'état demandé par la plus récente sous négociation.

Dans la plupart des mises en œuvre de logiciel de contrôle de flux, quand il est activé, les caractères XOFF et XON ne sont jamais propagés au serveur ; ils sont normalement avalés par le pilote de terminal entre le client telnet et le terminal rattaché. Dans la plupart des mises en œuvre qui prennent en charge la fonction RESTART-ANY, le caractère frappé qui réactive la sortie de résultats n'est pas avalée par le pilote de terminal, sauf si c'est le caractère XON.

Actuellement, seuls quatre codes de commandes sont définis pour les sous négociations : contrôle de flux désactivé (code  0), contrôle de flux activé (code 1), recommencer la sortie sur n'importe quel caractère (code 2) et ne commencer la sortie que sur XON (code 3). Aucun de ces codes n'exige de données supplémentaires  ; cependant il est possible que des commandes supplémentaires soient ajoutées. Donc les sous négociations qui ont des codes de commandes autres que ceux définis dans le présent document devraient être ignorées en silence.

Cette option ne traite pas le problème de permettre au côté DO de la connexion d'informer le côté WILL de quels caractères devraient être utilisés pour XON et XOFF. Cette fonctionnalité est déjà fournie par la commande LINEMODE [RFC1184].

 	6.	Exemple

Voici un exemple d'utilisation de cette option :

	Client	Serveur
	IAC DO TOGGLE-FLOW-CONTROL
IAC WILL TOGGLE-FLOW-CONTROL
[ Le serveur est maintenant libre d'envoyer des commandes pour changer le contrôle de flux. Noter que le client doit maintenant avoir activé le contrôle de flux, mais que le redémarrage sur XON seulement ou sur tout caractère est spécifique du client. ]
	IAC SB TOGGLE-FLOW-CONTROL RESTART-ANY IAC SE

[ Le client devrait maintenant passer à permettre le redémarrage de la sortie de résultats quand l'utilsateur frappe un caractère, si le client est capable de prendre en charge cette fonctionnalité. ]
	IAC SB TOGGLE-FLOW-CONTROL OFF IAC SE
	IAC SB TOGGLE-FLOW-CONTROL ON IAC SE

 	Références
[RFC1080]	C. Hedrick, "Option Telnet Contrôle de flux à distance", novembre 1988. (rendue obsolète par la RFC1372)

[RFC1184]	D. Borman, éditeur, "Option Telnet Mode de ligne", octobre 1990.

 	Remerciements

La spécification d'origine de cette option a été écrite par Charles Hedrick, et publiée comme RFC 1080. Les sous options RESTART-ANY et RESTART-XON ont été définies et ajoutées à la présente version du document par David Borman.

 	Considérations de sécurité

Les questions de sécurité ne sont pas discutées dans ce mémoire.

 	Adresses des auteurs

David Borman	Charles Hedrick	
Cray Research, Inc.	Rutgers University	
655F Lone Oak Drive	227 CORE Building	
Eagan, MN 55121	P.O. Box 879	
USA	Piscataway, NJ  08855-0879	
téléphone : (612) 452-6650	téléphone : (908) 932-3088	
mél : dab@CRAY.COM 	mél : hedrick@cs.rutgers.edu