Option Telnet Linemode

Statut du document

Le présent mémoire décrit un projet de norme pour la communauté de l'Internet. Il invite à des discussions et suggestions d'amélioration. La présente RFC spécifie un protocole en cours de normalisation par l'IAB pour la communauté de l'Internet. Prière de se référer à l'édition la plus récente des "Normes de protocole officielles de l'IAB" pour connaître l'état de normalisation et le statut de ce protocole. La distribution du présent mémoire n'est soumise à aucune restriction.

Changements par rapport à la RFC1116:

Deux nouveaux bits de mode ont été ajoutés, SOFT_TAB et LIT_ECHO. Ces bits permettent au serveur de donner des avis au client sur la façon de faire écho aux tabulations et caractères non imprimables.

Plusieurs nouvelles transpositions de caractères spéciaux ont été ajoutées pour le mouvement du curseur lorsque l'édition visuelle est prise en charge. Ce sont :

Déplacer le curseur d'un caractère gauche/droite (SLC_MCL/SLC_MCR),

Déplacer le curseur d'un mot gauche/droite (SLC_MCWL/SLC_MCWR),

Déplacer le curseur au début/fin de ligne (SLC_MCBOL/SLC_MCEOL),

Entrer mode insérer/remplacer (SLC_INSRT/SLC_OVER),

Écraser un caractère/mot à droite (SLC_ECR/SLC_EWR), et

Écraser jusqu'au début/fin de la ligne (SLC_EBOL/SLC_EEOL).

Généralités

Telnet Linemode est une façon de faire le traitement terminal des caractères du côté client de la connexion Telnet. Lorsqu'on est en Linemode avec l'édition activée pour le côté local, le trafic réseau est réduit à un couple de paquets par ligne de commande, au lieu d'un couple de paquets par caractère tapé. Cela est très utile pour les réseaux à long délai, parce que l'usager a l'heure de la réponse locale lorsqu'il tape la ligne de commande, et ne subit les délais du réseau qu'après que la commande est tapée. C'est aussi utile pour réduire les coûts sur les réseaux qui ont un tarif par paquet.

Prière d'envoyer tous commentaires à la liste de diffusion telnet-ietf@cray.com mailing list.

Table des Matières

1.   Noms et codes des commandes

2.   Signification des commandes

2.1   Fonction LINEMODE

2.2   Mode de sous-option LINEMODE

2.3   Sous option FORWARDMASK de LINEMODE

2.4   Sous option SLC de LINEMODE

2.5   Nouveaux caractères de contrôle

3.   Spécification de la valeur par défaut

4.   Motivation

5.   Règles de mise en œuvre

5.1   Interface d'utilisateur

5.2   Terminaisons de fin de ligne

5.3   Traitement de sortie

5.4   Un pilote terminal dans Telnet ?

5.5   Réglage des caractères locaux

5.6   FORWARDMASK, SLC_FORW1 et SLC_FORW2

5.7   Modes et valeurs valides et invalides

5.8   Purge des entrées et des sorties

5.9   Diagramme d'états pour SLC

5.10   Exemples de connexion

6.   Références des autres options Telnet

1.   Noms et codes des commandes

2.   Signification des commandes

2.1   Fonction LINEMODE

IAC WILL LINEMODE

Celui qui envoie cette commande DEMANDE la permission de commencer la sous négociation de l'état édition/signalisation. Elle ne devrait être envoyée que par le côté client de la connexion.

IAC WONT LINEMODE

Celui qui envoie cette commande DEMANDE que la sous négociation de l'état d'édition/signalisation ne soit pas permise.

IAC DO LINEMODE

Celui qui envoie cette commande DEMANDE que le côté distant commence la sous négociation de l'état d'édition/signalisation. Elle ne devrait être envoyée que par le côté serveur de la connexion.

IAC DONT LINEMODE

Celui qui envoie cette commande DEMANDE que le côté distant ne commence pas la sous négociation de l'état d'édition/signalisation.

2.2   Mode de sous-option LINEMODE

IAC SB LINEMODE MODE mask IAC SE

Celui qui envoie cette commande CONFIRME, ou DEMANDE la permission de commuter au mode défini par "mask".

Le "mask" est un gabarit binaire de modes divers que peut prendre la connexion. En fonctionnement normal, le côté serveur de la connexion va initier les changements de mode, et le client va confirmer les changements de mode. Les modes actuellement définis sont :

EDIT

Lorsqu'il est mis, le côté client de la connexion devrait traiter toutes les lignes d'entrée, effectuer toutes les fonctions d'édition, et n'envoyer que des lignes terminées au côté distant. Lorsqu'il n'est pas mis, le côté client ne devrait pas traiter d'entrée de l'utilisateur, et le côté serveur devrait prendre soin du traitement de tous les caractères qui ont besoin de l'être.

TRAPSIG

Lorsqu'il est mis, le côté client devrait traduire les interrupts/signals appropriés en leur équivalent Telnet. (Ce serait IP, BRK, AYT, ABORT, EOF, et SUSP.) Lorsqu'il n'est pas mis, le client devrait passer les interrupts/signals avec leurs valeurs ASCII normales.

FLOW

Logiquement, ceci appartient au "mask". Cependant, cela se chevaucherait avec l'option Telnet TOGGLE-FLOW-CONTROL, de sorte que l'option Telnet TOGGLE-FLOW-CONTROL est utilisée à la place. Lorsque DO/WILL LINEMODE est négocié, DO/WILL TOGGLE-FLOW-CONTROL devrait aussi être négocié. Voir la RFC 1080, "Contrôle Telnet de flux à distance", pour son utilisation correcte.

ECHO

Logiquement, ceci appartient au "mask". Cependant, cela se chevaucherait avec l'option Telnet ECHO, de sorte que l'option Telnet ECHO est utilisée à la place. Le côté client ne devrait jamais négocier "WILL ECHO". Lorsque le serveur a négocié le "WILL ECHO", le client ne devrait pas faire écho aux données tapées par l'usager en retour à l'usager. Lorsque le serveur a négocié "WONT ECHO", le client est responsable de faire écho aux données tapées par l'usager en retour à l'usager. Voir la RFC 857, "Option écho Telnet" pour un exposé complet de l'utilisation de l'option Telnet ECHO.

SOFT_TAB

Lorsqu'il est mis, le côté client devrait faire l'expansion du code de tabulation horizontale (HT), USASCII 9, dans le nombre approprié d'espaces pour déplacer l'imprimante jusqu'au prochain arrêt de tabulation horizontale. Lorsqu'il n'est pas mis, le côté client devrait permettre que le code tabulation horizontale passe sans modification.

LIT_ECHO

Lorsqu'il est mis, si le côté client fait écho à un caractère non imprimable que l'usager a tapé sur l'écran d'utilisateur, le caractère devrait être en écho comme le caractère littéral. Si le bit LIT_ECHO n'est pas mis, le côté client peut alors faire écho au caractère comme il lui plaît. (De nombreux systèmes font écho aux caractères non imprimables comme une séquence de deux caractère, par exemple, il feront "^A" en écho à une valeur ASCII 1.)

Lorsque le côté client d'une connexion reçoit une commande MODE, il DOIT au moins être d'accord sur l'état des bits EDIT et TRAPSIG. Si une commande MODE est reçue avec un gabarit de mode qui est actuellement utilisé (ignorant le bit MODE_ACK), la commande MODE est ignorée. Si une commande MODE est reçue qui est différente du gabarit de mode actuel, une réponse est alors envoyée soit avec le nouveau gabarit de mode et le bit MODE_ACK mis, soit avec un sous ensemble du nouveau gabarit de mode. La seule exception est que si le serveur reçoit une commande MODE avec le bit EDIT ou le bit TRAPSIG non mis, il peut mettre les bits EDIT et TRAPSIG dans la réponse, et si le client reçoit un MODE avec les bits EDIT ou TRAPSIG mis, il peut ne pas les éliminer dans la réponse.

Lorsque une commande MODE est reçue avec le bit MODE_ACK mis, et que le mode est différent du mode actuel, le client ignorera le nouveau mode, et le serveur passera au nouveau mode. Cela assure que les deux côtés de la connexion vont se retrouver dans le même mode. Dans aucun cas une réponse n'est générée à une commande MODE qui a le bit MODE_ACK mis.

2.3   Sous option FORWARDMASK de LINEMODE

IAC SB LINEMODE DO FORWARDMASK mask0 mask1 ... mask31 IAC SE

Celui qui envoie cette commande demande que l'autre côté envoie toutes les données en mémoire tampon lorsque l'un quelconque des caractères ASCII définis par le gabarit binaire est reçu. Seul le côté de la connexion qui a envoyé DO LINEMODE (le côté serveur) peut négocier cela. Le gabarit fait jusqu'à 32 octets. Chaque octet représente 8 codes de caractères ASCII. Le bit de plus fort poids de mask0 correspond à un code ASCII de 0. Le bit de moindre poids de mask0 correspond à un code ASCII de 7. Le bit de poids fort de mask1 correspond à un code ASCII de 8. Le bit de moindre poids de mask1 correspond à un code ASCII de 15, et ainsi des suite. La liste du gabarit peut être terminée avant la fin de la liste, auquel cas, tout le reste des octets du gabarit sont supposés être remis à zéro (égaux à zéro). Lorsque le côté serveur est en mode DONT TRANSMIT-BINARY, seuls les 16 premiers octets du gabarit (codes ASCII 0 à 127) sont alors utilisés. Si un octet individuel du gabarit est égal à IAC, il doit être envoyé comme un double IAC.

IAC SB LINEMODE DONT FORWARDMASK IAC SE

Celui qui envoie cette commande demande que l'autre côté arrête d'utiliser le gabarit direct pour déterminer quand envoyer les données de la mémoire tampon.

IAC SB LINEMODE WILL FORWARDMASK IAC SE

Cette commande est envoyée en réponse à une commande DO FORWARDMASK. Elle indique que le gabarit direct sera utilisé pour déterminer quand envoyer les données de la mémoire tampon.

IAC SB LINEMODE WONT FORWARDMASK IAC SE

Cette commande est envoyée en réponse à une commande DO FORWARDMASK. Elle indique que le gabarit direct ne sera pas utilisé pour déterminer quand envoyer les données de la mémoire tampon.

2.4   Sous option SLC de LINEMODE

La sous option Mettre des caractères locaux (SLC, Set Local Characters) utilise une liste de triplets d'octets. Le premier octet spécifie la fonction, le second octet spécifie les modificateurs de la fonction, et le troisième octet spécifie le caractère ASCII pour la fonction.

IAC SB LINEMODE SLC <liste de triplets d'octets> IAC SE

Celui qui envoie cette commande DEMANDE que la liste des triplets d'octets serve à mettre le caractère local à utiliser pour effectuer la fonction spécifiée.

Il y a quatre niveaux de réglage d'une fonction : SLC_NOSUPPORT est le plus bas, SLC_CANTCHANGE est le suivant, SLC_VALUE est au-dessus, et SLC_DEFAULT est le plus haut niveau.

Si les SLC_LEVELBITS dans le second octet sont égaux à SLC_DEFAULT, cette fonction particulière devrait alors utiliser le système par défaut de l'autre côté de la connexion.

Si les SLC_LEVELBITS dans le second octet sont égaux à SLC_VALUE, cette fonction est alors acceptée, et la valeur actuelle est spécifiée par le troisième octet.

Si les SLC_LEVELBITS dans le second octet sont égaux à SLC_CANTCHANGE, c'est alors une fonction qui est acceptée, mais la valeur pour cette fonction, spécifiée dans le troisième octet, ne peut pas être changée.

Si les SLC_LEVELBITS dans le second octet sont égaux à SLC_NOSUPPORT, cette fonction particulière n'est alors pas prise en charge et devrait être désactivée par l'autre côté.

Si c'est une réponse à une demande précédente de changer un caractère spécial, et qu'on est d'accord pour le changement, le bit SLC_ACK doit alors être mis dans le second octet.

Si le bit SLC_FLUSHIN est mis dans le second octet, chaque fois que cette fonction est envoyée, un Telnet "sync" devrait alors être envoyé en même temps pour purger le flux d'entrée.

Si le bit SLC_FLUSHOUT est mis dans le second octet, chaque fois que cette fonction est envoyée, les données de sortie devraient alors être purgées.

Seul le client peut envoyer un triplet d'octets avec le premier octet égal à zéro. Dans ce cas, le SLC_LEVELBITS peut seulement être réglé à SLC_DEFAULT ou à SLC_VALUE, et le troisième octet n'a pas d'importance. Lorsque le serveur reçoit 0 SLC_DEFAULT 0, il devrait passer à son réglage de caractères spéciaux par défaut du système, et envoyer tous ces caractères spéciaux au client. Lorsque le serveur reçoit 0 SLC_VALUE 0, il devrait simplement envoyer son jeu de caractères spéciaux courant. Noter que si le serveur ne prend pas en charge certaines des fonctions d'édition, elles devraient être envoyées comme XXX SLC_DEFAULT 0, plutôt que comme XXX SLC_NOSUPPORT 0, de sorte que le client puisse choisir d'utiliser ses propres valeurs pour ces fonctions, plutôt que d'avoir à désactiver ces fonctions bien qu'il les accepte.

Si l'un des octets dans la liste des triplets d'octets est égal à IAC, il doit être envoyé comme un double IAC.

Lorsque une connexion est établie, il est de la responsabilité du client de demander les valeurs distantes par défaut pour les caractères spéciaux, ou d'envoyer à travers la connexion ce à quoi tous les caractères spéciaux devraient être réglés.

Les valeurs de fonction peuvent être classées en deux groupes : les fonctions qui sont à traduire dans leur équivalent Telnet avant d'être envoyées à travers la connexion Telnet, et les fonctions qui sont à reconnaître et traiter localement.

D'abord, nous avons ces caractères qui sont à transposer en leurs équivalents Telnet :

SLC_SYNCH   Synchronisation. Voir la description complète dans la RFC 854, "Spécification du protocole Telnet".

SLC_BRK   Coupure. Voir la description complète dans la RFC 854, "Spécification du protocole Telnet".

SLC_IP   Processus interrompu. Voir la description complète dans la RFC 854, "Spécification du protocole Telnet".

SLC_AO   Sortie interrompue. Voir la description complète dans la RFC 854, "Spécification du protocole Telnet".

SLC_AYT   Est-tu là. Voir la description complète dans la RFC 854, "Spécification du protocole Telnet".

SLC_EOR   Fin d'enregistrement. Voir la description complète dans la RFC 885, "Option Telnet Fin d'enregistrement".

SLC_ABORT   Interrompre. Voir la description complète au paragraphe 2.5.

SLC_EOF   Fin de fichier. Voir la description complète au paragraphe 2.5.

SLC_SUSP   Suspendre. Voir la description complète au paragraphe 2.5.

Ensuite, nous avons les fonctions interprétées localement.

SLC_EC

Écraser le caractère. C'est le caractère qui est tapé pour écraser un caractère du flux entrant. Voir la description complète dans la RFC 854, "Spécification du protocole Telnet".

SLC_EL

Écraser la ligne. C'est le caractère qui est tapé pour écraser tout le contenu de la ligne d'entrée actuelle. Voir la description complète dans la RFC 854, "Spécification du protocole Telnet".

SLC_EW

Écraser le mot. C'est le caractère qui est tapé pour écraser un mot du flux d'entrée.

SLC_RP

Réimprimer la ligne. C'est le caractère qui est tapé pour causer la réimpression de la ligne d'entrée en cours, en laissant le curseur à la fin de la ligne.

SLC_LNEXT

Prochain littéral . C'est le caractère qui est tapé pour indiquer que le prochain caractère est à prendre littéralement, aucun traitement de caractère ne devrait être effectué sur lui, et si c'est un caractère spécial qui serait normalement transposé en une option Telnet, cette transposition ne doit pas être faite.

SLC_XON

Commencer la sortie. C'est le caractère qui est envoyé pour reprendre la sortie au terminal d'usager.

SLC_XOFF

Arrêter la sortie. C'est le caractère qui est envoyé pour stopper la sortie au terminal d'usager.

SLC_FORW1

Caractère de transmission. C'est un caractère qui devrait causer la transmission immédiate de toutes les données actuellement en mémoire tampon, ainsi que ce caractère.

SLC_FORW2

Caractère de transmission. C'est un autre caractère qui est à traiter de la même manière que SLC_FORW1.

SLC_MCL

Déplace le curseur d'un caractère à gauche. Lorsque l'édition visuelle est prise en charge, c'est le caractère qui, lorsqu'il est tapé, va déplacer le curseur d'un caractère à gauche dans l'affichage.

SLC_MCR

Déplace le curseur d'un caractère à droite. Lorsque l'édition visuelle est prise en charge, c'est le caractère qui, lorsqu'il est tapé, va déplacer le curseur d'un caractère à droite dans l'affichage.

SLC_MCWL

Déplace le curseur d'un mot à gauche. Lorsque l'édition visuelle est prise en charge, c'est le caractère qui, lorsqu'il est tapé, va déplacer le curseur d'un mot à gauche dans l'affichage.

SLC_MCWR

Déplace le curseur d'un mot à droite. Lorsque l'édition visuelle est prise en charge, c'est le caractère qui, lorsqu'il est tapé, va déplacer le curseur d'un mot à droite dans l'affichage.

SLC_MCBOL

Déplace le curseur au début de la ligne. Lorsque l'édition visuelle est prise en charge, c'est le caractère qui, lorsqu'il est tapé, va déplacer le curseur au début de la ligne en cours d'édition.

SLC_MCEOL

Déplace le curseur à la fin de la ligne. Lorsque l'édition visuelle est prise en charge, c'est le caractère qui, lorsqu'il est tapé, va déplacer le curseur à la fin de la ligne en cours d'édition.

SLC_INSRT

Entrer en mode insertion. Lorsque l'édition visuelle est prise en charge, après la frappe de ce caractère, tous les caractères normaux qui sont ensuite tapés seront insérés dans l'affichage.

SLC_OVER

Entrer en mode substitution. Lorsque l'édition visuelle est prise en charge, après la frappe de ce caractère, tous les caractères normaux qui sont ensuite tapés vont se substituer à tout caractère de l'affichage actuel. Si les variables SLC_INSRT et SLC_OVER sont réglées à la même valeur, cette valeur est alors d'agir comme bascule entre mode d'insertion et mode de substitution.

SLC_ECR

Écrase le caractère à droite. Lorsque l'édition visuelle est prise en charge, c'est le caractère qui, lorsqu'il est tapé, va écraser un caractère à la droite du curseur.

SLC_EWR

Écrase le mot à droite. Lorsque l'édition visuelle est prise en charge, c'est le caractère qui, lorsqu'il est tapé, va écraser un mot à la droite du curseur.

SLC_EBOL

Écrase jusque au début de la ligne. Lorsque l'édition visuelle est prise en charge, c'est le caractère qui, lorsqu'il est tapé, va écraser tous les caractères qui sont à gauche du curseur.

SLC_EEOL

Écrase jusqu'à la fin de la ligne. Lorsque l'édition visuelle est prise en charge, c'est le caractère qui, lorsqu'il est tapé, va écraser tous les caractères à droite du curseur.

Pour SLC_EEOL, SLC_EWR, et SLC_ECR, si un système a un curseur qui n'est pas affiché entre les caractères, mais est positionné par dessus un caractère, ce caractère est supposé être à la droite du curseur. Et donc, le SLC_ECR va écraser le caractère qui est sous la position actuelle du curseur.

2.5   Nouveaux caractères de contrôle

IAC ABORT

Interrompre. Similaire à "IAC IP", mais signifie seulement d'interrompre ou terminer le processus auquel le NVT est connecté. (La spécification Telnet dit que IP peut "suspendre, interrompre, abandonner ou terminer" le processus.) Si un système n'a pas deux méthodes pour interrompre un processus, ABORT et IP devraient alors avoir le même effet.

IAC SUSP

Suspend l'exécution du processus en cours au NVT de telle façon qu'un autre processus prenne le contrôle du NVT, et le processus suspendu puisse être repris ultérieurement. Si le système qui reçoit ne prend pas cette fonctionnalité en charge, elle devrait être ignorée.

IAC EOF

Fin de fichier. Le receveur devrait notifier au processus connecté au NVT qu'une fin de fichier a été atteinte. Ceci est destiné aux systèmes qui acceptent qu'un usager ait la capacité de taper un caractère EOF au clavier.

3.   Spécification de la valeur par défaut

La spécification de la valeur par défaut pour cette option est

WONT LINEMODE

DONT LINEMODE

qui signifie qu'il n'y aura aucune sous négociation du mode de la connexion.

Si WILL LINEMODE est négocié, les valeurs par défaut sont :

IAC SB LINEMODE MODE 0 IAC SE

IAC SB LINEMODE WONT FORWARDMASK IAC SE

Si DO LINEMODE est négocié, les valeurs par défaut sont :

IAC SB LINEMODE MODE 0 IAC SE

IAC SB LINEMODE DONT FORWARDMASK IAC SE

Les valeurs de caractère pour SLC reviennent par défaut à SLC_NOSUPPORT.

4.   Motivation

Avec l'usage croissant de Telnet; il est devenu évident que la capacité de commander le traitement de ligne sur la machine locale et d'envoyer des lignes complètes à la machine distante est une caractéristique nécessaire dans plusieurs environnements. D'abord, dans le cas d'une connexion sur un équipement à long délai, il est très frustrant pour l'usager d'avoir à attendre plusieurs secondes l'écho de ses données. Ensuite, certains super calculateurs, par leur nature même, ne sont pas très doués pour le traitement d'entrées d'un seul caractère. Pour ces machines, il est préférable d'avoir un ordinateur frontal pour faire le traitement de caractères, et de laisser les cycles du supercalculateur disponibles pour dévorer des nombres vectorisés.

Il y avait eu des tentatives pour faire en local le travail d'édition de ligne dans les spécifications Telnet existantes. Bien sûr, la bande 4.3 BSD comportait une version de Telnet qui essayait de le faire à travers la reconnaissance de l'état des options ECHO et SUPRESS-GO-AHEAD ; d'autres mises en œuvre font cette reconnaissance avec l'option ECHO.

Il y a des problèmes avec ces deux méthodes. Utiliser seulement ECHO ne donne pas de mécanisme pour désactiver ECHO chez l'usager, et laisse le traitement local de caractère actif lorsque, par exemple, un usager tape un mot de passe.

L'usage de SUPRESS-GO-AHEAD vient de ce qu'on lit dans la RFC 858, où il est dit :

"Dans de nombreuses mise en œuvre Telnet, il serait souhaitable de coupler l'option SUPRESS-GO-AHEAD à l'option ECHO de telle sorte que quant celle –ci est activée, l'option SUPPRESS-GO-AHEAD soit activées simultanément : ces deux options auront normalement à être activées simultanément pour effectuer ce qui est communément compris comme étant l'écho caractère par caractère par l'ordinateur distant."

La lecture a contrario de ce passage signifie que sans l'option ECHO ou l'option SUPPRESS-GO-AHEAD, on est en ligne en mode temporel, ce qui implique une édition locale de ligne. Cela pose le problème évident que ce n'est pas du tout ce à quoi l'option SUPPRESS-GO-AHEAD est supposée servir.

Un autre défaut est que la spécification Telnet n'est pas assez riche pour traiter tous les caractères spéciaux que prennent en charge certains de systèmes d'exploitation courants. Par exemple, la mise en œuvre ECHO/SGA accepte deux façons d'interrompre un processus, en empruntant l'option BRK pour la seconde interruption. Certaines mises en œuvre ont pris l'option EOR pour envoyer un End-Of-File. Visiblement, c'est un détournement d'utilisation qui n'était pas prévu, et la solution correcte serait de définir de nouvelles options.

Un autre problème est que certaines mises en œuvre du mode ligne mettent en mémoire tampon jusqu'à la fin de la ligne, et envoient ensuite toute la ligne d'un coup, avec les caractères d'édition et tout le reste. Aucune édition locale de la ligne n'a été faite.

Après avoir examiné plusieurs mises en œuvre, il est devenu clair que la chose correcte à faire est ne mettre en œuvre de nouvelles options pour améliorer la spécification Telnet actuelle afin qu'elle puisse prendre en charge l'édition locale de ligne d'une façon raisonnable, fiable, et cohérente.

Trois stades sont intéressants.

1)   Édition locale de ligne et piégeage du signal local

2)   Édition de ligne à distance, piégeage du signal local

3)   Édition de ligne à distance, piégeage du signal distant

Le cas de l'édition local de ligne et du piégeage du signal distant n'est pas très intéressant, parce qu'on ne reconnaît pas les signaux, et qu'on ne peut pas les envoyer au côté distant pour qu'il reconnaisse quand la ligne est achevée. Aussi, les signaux spéciaux auront habituellement un effet sur la fonction d'édition de ligne, et si ils ne sont pas piégés localement, l'action désirée ne se produira pas.

L'édition de ligne locale signifie que tout le traitement normal de caractère de ligne de commande, comme "Écraser le caractère" et "Écraser la ligne", se fait sur le système local, et c'est seulement quand un "CR LF" (ou autre caractère spécial) est rencontré que les données éditées sont envoyées au système distant.

Le piégeage du signal signifie, par exemple, que si l'usager tape le caractère associé à la fonction IP, la fonction "IAC IP" est alors envoyée au côté distant au lieu du caractère tapé. Piégeage du signal distant signifie, par exemple, que si l'usager tape le caractère associé à la fonction IP, la fonction "IAC IP" n'est alors pas envoyée au côté distant, mais c'est plutôt le caractère tapé qui est envoyée au côté distant.

5.   Règles de mise en œuvre

Il est prévu que toute mise en œuvre qui prend en charge l'option Telnet LINEMODE prendra en charge la totalité de cette spécification.

5.1   Interface d'utilisateur

Normalement, l'interface d'usager toute entière est laissé à la disposition de la mise en œuvre. Cependant, il y a des fonctionnalités que l'usager devrait être capable de spécifier sur le côté client de la connexion. Durant une session Telnet, le côté client devrait permettre qu'un mécanisme donne l' l'usager des commandes sur le processus Telnet local. Ces commandes devraient au moins permettre à l'usager de :

1)   Changer le mode de la connexion. L'usager devrait être capable d'essayer d'activer et désactiver EDIT, FLOW, TRAPSIG, et ECHO. Le serveur peut refuser de changer l'état des bits EDIT et TRAPSIG.

2)   Importer ou exporter SLC. L'usager devrait être capable de dire au processus local Telnet si il veut utiliser les définitions locales, en cours ou par défaut des caractères spéciaux.

3)   Envoi manuel des options. L'usager devrait être capable de dire au processus Telnet local d'envoyer explicitement toute option Telnet (comme IP, ABORT, AYT, etc.).

5.2   Terminaisons de fin de ligne

Lorsque LINEMODE est désactivé, et en mode EDIT, lorsque on tape une terminaison de ligne normale du côté client du système d'exploitation, la ligne devrait être transmise avec "CR LF" comme terminaison de ligne. Lorsque le mode EDIT est désactivé, un retour chariot devrait être envoyé comme "CR NUL", un saut à la ligne devrait être envoyé comme LF, et toute autre touche qui ne peut pas être transposé en un caractère ASCII, mais signifie que la ligne est terminée (comme une touche DOIT ou ENTER), devrait être envoyée comme "CR LF".

5.3   Traitement de sortie

Sans considération du mode qui a été négocié, le côté serveur est chargé de tout le traitement de sortie. Précisément, il devrait envoyer "CR LF" lorsque il veut la fonction "nouvelle ligne", "CR NUL" quand il veut juste un retour chariot, et "LF" quand il veut juste un saut de ligne.

5.4   Un pilote terminal dans Telnet ?

Les mises en œuvre conformes n'ont pas besoin de faire elles-mêmes toute l'édition de ligne. Il n'y a rien de mal à laisser le pilote terminal du système a prendre en main l'édition de ligne, et qu'il passe à l'application Telnet la ligne terminée et éditée, qui est alors envoyée au système distant.

5.5   Réglage des caractères locaux

Lors du développement de la présente RFC, l'idée originelle était que les deux côtés de la connexion utiliseraient leur propres valeurs par défaut pour les caractères spéciaux, même si ils n'étaient pas les mêmes des deux côtés de la connexion. Cependant si on utilise ce schéma, ce que voit l'usager est que ce sont les caractères spéciaux locaux qui sont utilisés, et les réglages de caractères distant n'ont pas d'importance. Il a donc été décidé que le côté client de la connexion devrait avoir le contrôle du réglage des caractères.

Lorsque LINEMODE est négocié, le client doit exporter les réglages de caractères locaux au serveur, ou envoyer une demande (SLC 0 SLC_DEFAULT 0) pour importer les caractères spéciaux du serveur. L'action usuelle serait qu'un client fonctionnant avec un ordinateur disposant de toutes ses capacités exporte les caractères spéciaux, et un client fonctionnant avec un système dépourvu de valeurs par défaut locales (comme certains serveurs terminaux) importe les caractères spéciaux.

Lorsqu'une commande SLC est reçue, l'action devrait être :

1)   L'ignorer si elle est la même que le réglage actuel.

2)   Si les SLC_LEVELBITS sont les mêmes que les bits de niveau actuels mais la valeur différente, et si le bit SLC_ACK est mis, aucune réponse n'est générée. Du côté serveur, la commande est ignorée, et du côté client, on passe à la nouvelle valeur. Cela fait en sorte que si une demande de changer le même caractère est générée à la fois par le serveur et par le client, ils vont tous deux se mettre sur la valeur demandée par le client.

3)   Si il y a accord sur le nouveau réglage, on passe à celui-ci et on répond par la même valeur, mais avec le bit SLC_ACK mis.

4)   Si il n'y a pas accord, on envoie une réponse avec ce qu'on pense que devrait être la valeur. Le bit SLC_ACK N'EST PAS mis dans ce cas. On ne peut marquer son désaccord avec une valeur qu'en envoyant une valeur différente de niveau inférieur.

Si le système distant n'accepte pas certains des caractères d'édition de la ligne, mais que le frontal les accepte, le frontal peut utiliser les définitions locales de ces caractères lorsqu'on est en mode ligne. Dans ce cas, le serveur devrait envoyer "SLC xxx SLC_DEFAULT 0" en réponse à une demande "SLC 0 SLC_DEFAULT 0", et simplement accuser réception quelle que soit le valeur à laquelle le client demande de régler la fonction.

Le caractère SLC_FORW2 ne devrait être utilisé que si SLC_FORW1 est déjà utilisé.

5.6   FORWARDMASK, SLC_FORW1 et SLC_FORW2

Pour aider à faire face à la quantité de travail nécessaire à la mise en œuvre du côté client, deux méthodes de réglage des caractères de transmission sont fournies. SLC_FORW1 et SLC_FORW2 permettent le réglage de deux caractères supplémentaires sur lesquels transmettre les données d'entrée en mémoire tampon. Comme beaucoup de pilotes de terminaux ont la capacité de régler un ou plusieurs délimiteurs de ligne, il est très facile de prendre cela en charge sans avoir à mettre en œuvre à travers le pilote de terminal local, plutôt que de mettre un pilote de terminal dans Telnet. Si le pilote de terminal local a des fonctionnalités qui se transposent facilement dans le FORWARDMASK (gabarit de transmission), il peut alors être aussi facilement pris en charge. Si le pilote local de terminal ne le prend pas en charge, il faudra alors plus de travail pour prendre FORWARDMASK en charge.

Noter aussi que le côté client est obligé de transmettre les données lorsqu'il voit un caractère SLC_FORW1, SLC_FORW2, ou FORWARDMASK, ou lorsqu'il rencontre toute terminaison de ligne normale ou signal spécial. Le côté client a aussi toute liberté de transmettre sur d'autres caractères de son choix. Par exemple, si le côté serveur envoie un FORWARDMASK qui demande l'envoi des données sur les vingt premiers caractères de contrôle (codes ASCII 1 à 024), et si le côté client ne peut pas obtenir de son pilote terminal local de transmettre juste sur les vingt premiers caractères de contrôle, mais qu'il peut obtenir due le pilote terminal local transmette sur tout caractère de contrôle (codes ASCII 1 à 039), le côté client pourrait alors légitimement accepter le FORWARDMASK, et transmettre sur tout caractère de contrôle. En mode EDIT, on devrait prendre soin de ne pas transmettre au hasard, car une fois que les données sont transmises, aucune autre tâche d'édition ne peut être faite sur la partie de la ligne transmise. Le seul moment (autre que le moment normal) où les données devraient être transmises en mode EDIT serait si une seule ligne d'entrée était trop longue pour être traitée localement.

5.7   Modes et valeurs valides et invalides

À aucun moment "DO LINEMODE" ne devrait être négocié dans les deux directions de la connexion Telnet. Le côté qui fait le "DO LINEMODE" est considéré comme étant le côté serveur, et le côté qui fait "WILL LINEMODE" est le côté client.

À aucun moment "SB LINEMODE DO/DONT FORWARDMASK" ne devrait être envoyé à moins que "DO LINEMODE" n'ait été précédemment négocié. À aucun moment "SB LINEMODE WILL/WONT FORWARDMASK" ne devrait être envoyé à moins que "WILL LINEMODE" n'ait été précédemment négocié.

Si une commande ABORT, EOF ou SUSP est reçue et si le système ne prend pas en charge cette fonctionnalité, elle peut être simplement ignorée.

5.8   Purge des entrées et des sorties

Lorsqu'une commande IP, BRK ou ABORT est envoyée, il est généralement souhaitable d'être capable de purger le flux entrant, et de purger la sortie vers l'usager jusqu'à ce que la commande IP, BRK, ou ABORT soit traitée. Les bits SLC_FLUSHIN et SLC_FLUSHOUT sont utilisés pour indiquer l'action qui devrait être effectuée. Ces bits seulement des conseils, mais devraient être honorés si possible. La méthode standard pour traiter le SLC_FLUSHIN est d'utiliser le signal Telnet "Synch", et le SLC_FLUSHOUT est traité en utilisant l'option TIMING-MARK. Si tous les deux sont à envoyer, le IAC DM est envoyé avant le DO TIMING-MARK. Et donc, l'envoyeur va transmettre "IAC XXX IAC DM IAC DO TIMING-MARK", où XXX peut être IP, BRK ou ABORT, ou tout autre caractère spécial. L'IAC DM est envoyé comme données TCP urgentes avec le DM comme dernier (ou seul) octet de données ; cela est utilisé pour purger le flux d'entrée. Le "IAC DO TIMING-MARK" est utilisé pour dire quand arrêter de purger la sortie ; une fois qu'il est envoyé, toutes les données sont éliminées jusqu'à réception d'un "IAC WILL TIMING-MARK" ou d'un "IAC WONT TIMING-MARK".

Comme les bits SLC_FLUSHIN et SLC_FLUSHOUT sont seulement des indications, l'interface d'utilisateur devrait fournir une méthode permettant à l'usager d'outrepasser l'envoi (ou le non envoi) de "Synch" et TIMING-MARK, mais l'action par défaut devrait être de les envoyer conformément aux bits SLC_FLUSHIN et SLC_FLUSHOUT.

Chaque fois qu'un IAC AO est reçu, un Synch doit être retourné. Chaque fois qu'un Synch est traité (par le passage de la connexion TCP en mode Urgent) toutes les données doivent être éliminées (mais pas les commandes Telnet !) jusqu'à ce qu'on trouve un IAC DM, et que la connexion sorte du mode Urgent. Voir une description complète du signal Synch dans la RFC 854, "Spécification du protocole Telnet".

5.9   Diagramme d'états pour SLC

SPC0   Réglage initial pour un caractère spécial

SPC1   Un changement de caractère spécial < SPC0

SPC-A   Réglage de tous les caractères spéciaux en cours

VAL   niveau SLC_VALUE

DEF    niveau SLC_DEFAULT

Niveaux : DEFAULT, VALUE, CANT_CHANGE, NOSUPPORT

Fanions : ACK

5.10   Exemples de connexion

Dans ces exemples, les noms symboliques sont utilisés plutôt que les valeurs réelles, pou les rendre lisibles. Lorsque deux noms symboliques ou plus sont joints par un |, cela signifie que la valeur réelle sera le "ou" logique des valeurs des noms symboliques. Pour la clarté de l'exposé, pour ces exemples les séquences d'IAC et IAC SB de tête, et les séquence d'IAC SE de queue ont été omises. Le SLC_prefix a aussi été laissé de côté là où il aurait normalement dû survenir.

[ La sous négociation peut maintenant se traiter dans les deux directions. Le client envoie la liste des caractères spéciaux. ]

LINEMODE SLC SYNCH DEFAULT 0 IP

VALUE|FLUSHIN|FLUSHOUT 3 AO

VALUE 15 AYT DEFAULT 0 ABORT

VALUE|FLUSHIN|FLUSHOUT 28 EOF

VALUE 4 SUSP VALUE|FLUSHIN 26 EC

VALUE 127 EL VALUE 21 EW VALUE

23 RP VALUE 18 LNEXT VALUE 22

XON VALUE 17 XOFF VALUE 19

[ Maintenant que linemode est activé, le serveur établit le mode initial, et accuse réception des caractères spéciaux. ]

[ Le client obtient le mode et accuse réception des caractères spéciaux, du mode et de tous caractères spéciaux que change le serveur. ]

[ Désactiver l'écho chez l'usager. ]

[ Réactiver l'écho chez l'usager. ]

[ L'usager fait quelques affaires, et ensuite lance une application qui veut utiliser le mode d'un seul caractère, en faisant son propre écho des caractères, mais garde le piégeage de signal activé. ]

[ L'application se termine ]  

[ L'application se termine ]

[ L'usager change son écraser caractère en ^H. ]

[ L'usager décide de revenir aux caractères spéciaux du côté client originel. ]

[ L'usager décide d'importer les caractères spéciaux par défaut du côté distant. ]

[ Comme ce sont les mêmes que le réglage local actuel, aucune réponse n'est générée. ]

[ Le prochain exemple est celui de l'abandon d'un éditeur qui voulait laisser le côté client faire l'écho et la mise en mémoire tampon des caractères, mais ne voulait pas qu'il fasse d'édition de ligne, et que la transmission des données ne soit faite que sur un caractère de contrôle. Noter que nous avons fait précéder tous les 0377 dans le gabarit de transmission d'un IAC. ]

[ L'application arrive en fin d'exécution, et ensuite les choses sont remises à l'état précédent. ]

6.   Références des autres options Telnet

Ci-après est une liste de RFC pour diverses options Telnet qui devraient être prises en charge avec LINEMODE.

1.   J. Postel et J. Reynolds, " Spécification du protocole TELNET", RFC 854, ISI, mai 1983.

2.   J. Postel et J. Reynolds, "Spécifications des options Telnet", RFC 855, ISI, mai 1983.

3.   J. Postel et J. Reynolds, "Transmission Telnet binaire ", STD 27, RFC 856, mai 1983.

4.   J. Postel et J. Reynolds, "Option Telnet ECHO", RFC 857, ISI, mai 1983.

5.   J. Postel et J. Reynolds, "Option Telnet SUPRESS GO AHEAD",RFC 858, ISI, mai 1983.

6.   J. Postel et J. Reynolds, "Option Telnet TIMING MARK", RFC 860, ISI, mai 1983.

7.   J. VanBokkelen, "Option Telnet Type de terminal", RFC 1091, FTP Software, Inc., février 1989.

8.   D. Waitzman, "Option Telnet Taille de fenêtre", RFC 1073, BBN STC, octobre 1988.

9.   C. Hedrick, "Option Telnet Contrôle de flux à distance", RFC 1080, Rutgers University, novembre, 1988.

10.   C. Hedrick, "Option Telnet Vitesse du terminal", RFC 1079, Rutgers University, décembre 1988.

Ci-après figurent des RFC qui ne sont pas nécessairement prises en charge par LINEMODE, mais qui amélioreront toute mise en œuvre de Telnet.

11.   J. Postel et J. Reynolds, "Option Telnet État", STD 30, RFC 859, USC/ISI, mai 1983.

12.   J. Postel, "Option Telnet Fin d'enregistrement", RFC 885, USC/Information Sciences Institute, décembre 1983.

13.   S. Silverman, "Option Telnet Marquage de sortie", RFC 933, MITRE, janvier 1985.

14.   G. Marcy, "Option Telnet Localisation d'affichage X", RFC 1096, Carnegie Mellon University, mars 1989.

Considérations pour la sécurité

Les questions de sécurité ne sont pas abordées dans le présent mémoire.

Adresse de l'auteur

David A. Borman

Cray Research Inc.

655F Lone Oak Drive

Eagan, MN 55123

Téléphone : (612) 452-6650

mél : dab@CRAY.COM

Adresse de la liste de difusion du groupe de travail Telnet de l'IETF : telnet-ietf@CRAY.COM