Traduction Claude Brière de L’Isle

OPTION TELNET ECHO

La présente RFC spécifie une norme pour la communauté ARPA Internet. Les hôtes sur l’ARPA sont invités à adopter et mettre en œuvre la présente norme.

1 Nom et code de la commande

2 Signification de la commande

IAC WILL ECHO

L’envoyeur de cette commande DEMANDE de commencer, ou confirme qu’il va maintenant commence à renvoyer un écho aux caractères de données qu’il reçoit sur la connexion TELNET à l’envoyeur des caractères de données.

IAC WON'T ECHO

L’envoyeur de cette commande DEMANDE d’arrêter, ou refuse de commencer, de renvoyer un écho des caractères de données qu’il reçoit sur la connexion TELNET à l’envoyeur des caractères de données.

IAC DO ECHO

L’envoyeur de cette commande DEMANDE que celui qui reçoit cette commande commence à renvoyer un écho, ou confirme qu’il est prévu que celui qui reçoit cette commande fasse écho, aux caractères de données qu’il reçoit sur la connexion TELNET à l’envoyeur.

IAC DON'T ECHO

L’envoyeur de cette commande DEMANDE au receveur de cette commande d’arrêter, ou de ne pas commencer, à faire écho aux caractères de données qu’il reçoit sur la connexion TELNET.

3 Valeur par défaut

WON'T ECHO

DON'T ECHO

Aucun renvoi d’écho n’est fait sur la connexion TELNET.

4 Motifs de l’option

Le NVT a une imprimante et un clavier qui sont nominalement interconnectés de sorte que les "échos" n’ont jamais besoin de traverser le réseau ; c’est-à-dire que le NVT fonctionne nominalement dans un mode où les caractères frappés sur le clavier sont (par divers moyens) retournés localement et imprimés sur l’imprimante. Dans des situations très interactives, il est approprié pour le processeur distant (interpréteur de langage de commande, etc.) auquel les caractères sont envoyés de contrôler la façon dont il leur est fait écho à l’imprimante. Pour la prise en charge de telles situations interactives, il est nécessaire qu’il y ait une option TELNET pour permettre aux parties aux deux extrémités de la connexion TELNET de se mettre d’accord pour que les caractères frappés sur un clavier NVT reçoivent un écho de la part de l’autre extrémité de la connexion TELNET.

5 Description de l’option

Lorsque l’option d’écho est activée, la partie à l’extrémité qui effectue l’écho est supposée retransmettre (faire écho) les caractères de données qu’elle reçoit à l’envoyeur des caractères de données. L’option n’exige pas que les caractères en écho soient exactement les caractères reçus (par exemple, un certain nombre de systèmes font écho au caractère ASCII ESC avec autre chose que le caractère ESC).Lorsque l’option d’écho n’est pas activée, le receveur des caractères de données ne devrait pas les retransmettre à l’envoyeur ; ceci, bien sûr, n’empêche pas le receveur de répondre aux caractères de données qu’il reçoit.

La connexion TELNET normale est bidirectionnelle. C’est à dire que les flux de données dans chaque direction sont indépendants sur la connexion ; et ni l’une ni l’autre, ni l’une ou l’autre, ni les deux directions ne peuvent fonctionner simultanément en mode écho. Il y a cinq modes de fonctionnement raisonnables pour faire écho sur une paire de connexion :

Aucune extrémité ne fait écho

Une extrémité fait écho pour elle-même

Une extrémité fait écho pour l’autre

Les deux extrémités font écho pour elles-mêmes

Une extrémité fait écho pour les deux extrémités

Cette option offre la capacité de décider si chaque extrémité va faire écho pour l’autre ou non. Elle ne donne cependant pas de contrôle sur le fait qu’une extrémité fasse écho ou non pour elle même ; cette décision doit être laissée à la seule discrétion des systèmes à chaque extrémité (bien qu’ils puissent utiliser les informations concernant l’état des négociation sur l’écho "distant" en prenant cette décision).

Il vaut de noter que si LES DEUX hôtes entrent dans le mode d’écho des caractères transmis par l’autre hôte, tout caractère transmis dans l’une ou l’autre direction sera renvoyé en écho de part et d’autre indéfiniment. Donc, il faut veiller dans chaque mise en œuvre à ce que si un site fait écho, l’écho ne soit pas permis en retour sur l’autre site.

Comme exposé dans la spécification du protocole TELNET, les deux parties à une connexion TELNET en full duplex supposent initialement que chaque direction de la connexion fonctionne dans le mode par défaut qui est non-écho (non-écho est ne pas utiliser cette option, et c’est la même chose que DON'T ECHO, WON'T ECHO).

Si l’une ou l’autre partie désire elle-même faire écho aux caractères de l’autre partie ou pour l’autre partie de faire écho aux à ses caractères, cette partie envoie la commande appropriée (WILL ECHO ou DO ECHO) et attend (en espérant) l’acceptation de l’option. Si la demande de faire fonctionner la connexion en mode écho est refusée, la connexion continue alors de fonctionner en mode non-écho. Si la demande de faire fonctionner la connexion en mode écho est acceptée, la connexion est mise en mode écho.

Après qu’une connexion ait été passée en mode écho, l’une ou l’autre partie peut demander à revenir en mode non-écho en envoyant la commande DON'T ECHO ou WON'T ECHO appropriée (ce que l’autre partie doit confirmer alors en permettant que la connexion fonctionne en mode non-écho). De même que chaque direction de la connexion TELNET peut être mise indépendamment en mode d’écho distant, chaque direction de la connexion TELNET doit être retirée séparément du mode d’écho distant.

Les mises en œuvre de l’option écho, comme les mises en œuvre de toutes les autres options TELNET, doivent suivre les règles de prévention des boucles données dans la section Considérations générales de la spécification du protocole TELNET. Également, pour que les passages de mode écho à non-écho et réciproquement puissent s’effectuer avec le minimum de confusion (double écho momentané, etc.), les changements de mode de fonctionnement devraient se faire à des horaires précisément coordonnés avec la réception et la transmission des demandes et réponses d’écho. Par exemple, si une partie répond à un DO ECHO par un WILL ECHO, tous les caractères de données reçus après le DO ECHO devraient avoir un écho et le WILL ECHO devrait immédiatement précéder le premier des caractères dont il est fait écho.

L’option d’écho seule ne sera normalement pas suffisante pour effectuer ce qui est généralement compris comme l’écho des caractères frappés sur le clavier du terminal de l’ordinateur distant -- l’option SUPPRESS-GO AHEAD devra normalement être invoquée en conjonction avec l’option ECHO pour effectuer l’écho à distance caractère par caractère.

6 Exemple de mise en œuvre de l’option

Ce qui suit est une description d’une mise en œuvre possible pour un système d’utilisateur simple appelé "UHOST".

Cette mise en œuvre pourrait être que pour chaque terminal d’utilisateur, le système UHOST conserverait trois bits d’état : si le terminal fait écho pour lui-même (UHOST ECHO toujours) ou non (mode ECHO possible), si l’utilisateur (humain) préfère fonctionner en mode ECHO ou en mode non-ECHO, et si la connexion de ce terminal au serveur est en mode ECHO ou non-ECHO. Nous appellerons ces trois bits P(hysique), D(ésiré), et A(ctuel).

Lorsqu’un terminal appelle le système UHOST, le bit P est réglé de la façon appropriée, le bit D est mis à la même valeur, et le bit A est réglé à non-ECHO. Le bit P et le bit D peuvent être établis manuellement par des commandes directes si l’utilisateur le désire. Par exemple, un utilisateur à Hawaii sur un terminal "full-duplex", choisirait de ne pas fonctionner en mode ECHO, sans considération pour la préférence d’un serveur continental. Il devrait amener UHOST à changer son bit D de ECHO à non-ECHO.

Lorsqu’une connexion est ouverte de terminal UHOST vers un serveur, le système UHOST enverrait au serveur une commande DO ECHO si le MIN (avec non-ECHO inférieur à ECHO) des bits P et D est différent du bit A. Si une commande WON'T ECHO ou WILL ECHO arrive du serveur, le système UHOST va régler le bit A au MIN de la demande reçue, le bit P, et le bit D. Si cela change l’état du bit A, le système UHOST va envoyer l’accusé de réception approprié ; si cela ne le change pas, le système UHOST enverra alors le refus approprié si ne pas changer signifie qu’il doit refuser la demande (c’est-à-dire, le MIN des bits P et D était inférieur à la demande A reçue).

Si, lorsqu’une connexion est ouverte, l’utilisateur du terminal UHOST change le bit P ou le bit D, UHOST va répéter l’essai ci-dessus et envoyer un DO ECHO ou un DON'T ECHO, si nécessaire. Lorsque la connexion est close, le système UHOST va remettre le bit A pour indiquer la mise en écho de UHOST.

Bien que la mise en œuvre de UHOST n’implique pas l’envoi des commandes DO ECHO ou DON'T ECHO au serveur sauf lorsque la connexion est ouverte pour que l’utilisateur change explicitement son mode d’écho, de plus gros hôtes pourraient invoquer de tels changements de mode assez fréquemment. Par exemple, alors qu’un système ligne par ligne est en fonction, le serveur pourrait tenter de mettre l’utilisateur en mode d’écho local en envoyant la commande WON'T ECHO à l’utilisateur ; mais lorsqu’un système caractère par caractère fonctionne, le serveur pourrait tenter d’invoquer l’écho distant pour l’utilisateur en envoyant la commande WILL ECHO à l’utilisateur. De plus, alors que le système UHOST n’enverra jamais une commande WILL ECHO et va seulement envoyer un WON'T ECHO pour refuser une commande DO ECHO envoyée par un serveur, un hôte de serveur pourrait souvent envoyer les commandes WILL et WON'T ECHO.