3. Remote Login - Protocole TELNET
3.1 INTRODUCTION
Telnet est le protocole d'application Internet standard pour la connexion à distance. Il fournit les règles d'encodage pour relier le clavier/affichage d'un utilisateur sur un système client (« utilisateur ») avec un interpréteur de commandes sur un système serveur distant. Un sous-ensemble du protocole Telnet est également incorporé dans d'autres protocoles d'application, par exemple FTP et SMTP.
Telnet utilise une seule connexion TCP, et son flux de données normal (mode « terminal virtuel réseau » ou « NVT ») est ASCII 7 bits avec des séquences d'échappement pour intégrer les fonctions de contrôle. Telnet permet également la négociation de nombreux modes et fonctions optionnels.
La spécification Telnet primaire se trouve dans RFC-854 [TELNET:1], tandis que les options sont définies dans de nombreux autres RFC ; voir Section 7 pour les références.
3.2 PARCOURS DU PROTOCOLE
3.2.1 Négociation d'options : RFC-854, pp. 2-3
Chaque implémentation Telnet doit (MUST) inclure la mécanique de négociation et de sous-négociation d'options [TELNET:2].
Un hôte doit (MUST) suivre attentivement les règles de RFC-854 pour éviter les boucles de négociation d'options. Un hôte doit (MUST) refuser (c'est-à-dire répondre WONT/DONT à un DO/WILL) une option non supportée. La négociation d'options devrait (SHOULD) continuer à fonctionner (même si toutes les demandes sont refusées) pendant toute la durée de vie d'une connexion Telnet.
Si toutes les négociations d'options échouent, une implémentation Telnet doit (MUST) par défaut être et supporter un NVT.
DISCUSSION :
Même si des « terminaux » plus sophistiqués et la prise en charge des négociations d'options deviennent la norme, toutes les implémentations doivent être préparées à supporter un NVT pour toute communication utilisateur-serveur.
3.2.2 Fonction Go-Ahead de Telnet : RFC-854, p. 5, et RFC-858
Sur un hôte qui n'envoie jamais la commande Telnet Go Ahead (GA), le serveur Telnet doit (MUST) tenter de négocier l'option Suppress Go Ahead (c'est-à-dire envoyer « WILL Suppress Go Ahead »). Un Telnet utilisateur ou serveur doit (MUST) toujours accepter la négociation de l'option Suppress Go Ahead.
Lorsqu'il pilote un terminal full-duplex pour lequel GA n'a aucune signification, une implémentation Telnet utilisateur peut (MAY) ignorer les commandes GA.
DISCUSSION :
Les terminaux half-duplex (« clavier verrouillé ») ligne par ligne pour lesquels le mécanisme Go-Ahead a été conçu ont largement disparu de la scène. Il s'est avéré difficile d'implémenter l'envoi du signal Go-Ahead dans de nombreux systèmes d'exploitation, même certains systèmes qui supportent des terminaux half-duplex natifs. La difficulté est généralement que le code du serveur Telnet n'a pas accès aux informations indiquant si le processus utilisateur est bloqué en attente d'entrée depuis la connexion Telnet, c'est-à-dire qu'il ne peut pas déterminer de manière fiable quand envoyer une commande GA. Par conséquent, la plupart des hôtes serveurs Telnet n'envoient pas de commandes GA.
L'effet des règles de cette section est de permettre à l'une ou l'autre extrémité d'une connexion Telnet de mettre son veto à l'utilisation des commandes GA.
Il existe une classe de terminaux half-duplex qui est encore commercialement importante : les « terminaux de saisie de données », qui interagissent de manière plein écran. Cependant, le support des terminaux de saisie de données utilisant le protocole Telnet ne nécessite pas le signal Go Ahead ; voir Section 3.3.2.
3.2.3 Fonctions de contrôle : RFC-854, pp. 7-8
La liste des commandes Telnet a été étendue pour inclure EOR (End-of-Record), avec le code 239 [TELNET:9].
Les Telnets utilisateur et serveur peuvent (MAY) supporter les fonctions de contrôle EOR, EC, EL et Break, et doivent (MUST) supporter AO, AYT, DM, IP, NOP, SB et SE.
Un hôte doit (MUST) être capable de recevoir et d'ignorer toute fonction de contrôle Telnet qu'il ne supporte pas.
DISCUSSION :
Notez qu'un serveur Telnet est requis pour supporter la fonction Telnet IP (Interrupt Process), même si l'hôte serveur dispose d'une fonction équivalente dans le flux (par exemple, Control-C dans de nombreux systèmes). La fonction Telnet IP peut être plus forte qu'une commande d'interruption dans le flux, en raison de l'effet hors bande des données urgentes TCP.
La fonction de contrôle EOR peut être utilisée pour délimiter le flux. Une application importante est le support des terminaux de saisie de données (voir Section 3.3.2). Il y avait une préoccupation que puisque EOR n'avait pas été défini dans RFC-854, un hôte qui n'était pas préparé à ignorer correctement les commandes Telnet inconnues pourrait planter s'il recevait un EOR. Pour protéger de tels hôtes, l'option End-of-Record [TELNET:9] a été introduite ; cependant, un programme Telnet correctement implémenté n'aura pas besoin de cette protection.
3.2.4 Signal "Synch" de Telnet : RFC-854, pp. 8-10
Lorsqu'il reçoit des données TCP « urgentes », un Telnet utilisateur ou serveur doit (MUST) jeter toutes les données sauf les commandes Telnet jusqu'à ce que le DM (et la fin de l'urgent) soit atteint.
Lorsqu'il envoie Telnet IP (Interrupt Process), un Telnet utilisateur devrait (SHOULD) le suivre par la séquence « Synch » de Telnet, c'est-à-dire envoyer comme données TCP urgentes la séquence « IAC IP IAC DM ». Le pointeur urgent TCP pointe vers l'octet DM.
Lorsqu'il reçoit une commande Telnet IP, un serveur Telnet peut (MAY) renvoyer une séquence « Synch » de Telnet à l'utilisateur, pour vider le flux de sortie. Le choix devrait être cohérent avec la façon dont le système d'exploitation serveur se comporte lorsqu'un utilisateur local interrompt un processus.
Lorsqu'il reçoit une commande Telnet AO, un serveur Telnet doit (MUST) renvoyer une séquence « Synch » de Telnet à l'utilisateur, pour vider le flux de sortie.
Un Telnet utilisateur devrait (SHOULD) avoir la capacité de vider la sortie lorsqu'il envoie un Telnet IP ; voir aussi Section 3.4.5.
DISCUSSION :
Il existe trois façons possibles pour un Telnet utilisateur de vider le flux de données de sortie du serveur :
(1) Envoyer AO après IP.
Cela amènera l'hôte serveur à envoyer un signal « vider la sortie tamponnée » à son système d'exploitation. Cependant, l'AO peut ne pas prendre effet localement, c'est-à-dire arrêter la sortie du terminal côté Telnet utilisateur, jusqu'à ce que le serveur Telnet ait reçu et traité l'AO et ait renvoyé un « Synch ».
(2) Envoyer DO TIMING-MARK [TELNET:7] après IP, et jeter toute la sortie localement jusqu'à ce qu'un WILL/WONT TIMING-MARK soit reçu du serveur Telnet.
Puisque le DO TIMING-MARK sera traité après l'IP au serveur, la réponse devrait être au bon endroit dans le flux de données de sortie. Cependant, le TIMING-MARK n'enverra pas de signal « vider la sortie tamponnée » au système d'exploitation du serveur. Que cela soit nécessaire ou non dépend du système serveur.
(3) Faire les deux.
La meilleure méthode n'est pas entièrement claire, car elle doit accommoder un certain nombre d'hôtes serveurs existants qui ne suivent pas les standards Telnet de diverses manières. L'approche la plus sûre est probablement de fournir une option contrôlable par l'utilisateur pour sélectionner (1), (2) ou (3).
3.2.5 Imprimante et clavier NVT : RFC-854, p. 11
En mode NVT, un Telnet ne devrait pas (SHOULD NOT) envoyer de caractères avec le bit de poids fort à 1, et ne doit pas (MUST NOT) l'envoyer comme bit de parité. Les implémentations qui passent le bit de poids fort aux applications devraient (SHOULD) négocier le mode binaire (voir Section 3.2.6).
DISCUSSION :
Les implémenteurs doivent être conscients qu'une lecture stricte de RFC-854 permet à un client ou serveur attendant NVT ASCII d'ignorer les caractères avec le bit de poids fort défini. En général, le mode binaire est censé être utilisé pour la transmission d'un jeu de caractères étendu (au-delà de 7 bits) avec Telnet.
Cependant, il existe des applications qui ont réellement besoin d'un mode NVT 8 bits, lequel n'est actuellement pas défini, et ces applications existantes positionnent effectivement le bit de poids fort pendant une partie ou la totalité de la durée de vie de la connexion Telnet. Notez que le mode binaire n'est pas la même chose qu'un mode NVT 8 bits, car le mode binaire désactive le traitement de fin de ligne. Pour cette raison, les exigences sur le bit de poids fort sont formulées avec SHOULD plutôt qu'avec MUST.
RFC-854 définit un ensemble minimal de propriétés d'un « terminal virtuel de réseau » ou NVT ; cela n'a pas pour but d'exclure des caractéristiques supplémentaires présentes dans des terminaux réels. Une connexion Telnet est parfaitement transparente à tous les caractères ASCII 7 bits, y compris les caractères de contrôle ASCII arbitraires.
Par exemple, un terminal pourrait prendre en charge des commandes plein écran codées comme des séquences d'échappement ASCII ; une implémentation Telnet transmettrait ces séquences comme des données non interprétées. Ainsi, un NVT ne doit pas être compris comme un type de terminal correspondant à un dispositif très limité.
3.2.6 Structure des commandes Telnet : RFC-854, p. 13
Puisque les options peuvent apparaître à n'importe quel point dans le flux de données, un caractère d'échappement Telnet (connu sous le nom d'IAC, avec la valeur 255) à envoyer comme données doit (MUST) être doublé.
3.2.7 Option binaire Telnet : RFC-856
Lorsque l'option binaire a été négociée avec succès, des caractères 8 bits arbitraires sont autorisés. Cependant, le flux de données doit (MUST) toujours être scanné pour les caractères IAC, toutes les commandes Telnet intégrées doivent (MUST) être obéies, et les octets de données égaux à IAC doivent (MUST) être doublés. Aucun autre traitement de caractères (par exemple, remplacer CR par CR NUL ou par CR LF) ne doit (MUST NOT) être effectué. En particulier, il n'y a pas de convention de fin de ligne (voir Section 3.3.1) en mode binaire.
DISCUSSION :
L'option binaire est normalement négociée dans les deux directions, afin de faire passer la connexion Telnet du mode NVT au « mode binaire ».
La séquence IAC EOR peut être utilisée pour délimiter des blocs de données à l'intérieur d'un flux Telnet en mode binaire.
3.2.8 Option Terminal-Type de Telnet : RFC-1091
L'option Terminal-Type doit (MUST) utiliser les noms de types de terminaux officiellement définis dans le RFC des numéros attribués [INTRO:5], lorsqu'ils sont disponibles pour le terminal particulier. Cependant, le récepteur d'une option Terminal-Type doit (MUST) accepter n'importe quel nom.
DISCUSSION :
RFC-1091 [TELNET:10] met à jour une version antérieure de l'option Terminal-Type définie dans RFC-930. La version antérieure permettait à un hôte serveur capable de prendre en charge plusieurs types de terminaux de connaître le type du terminal client particulier, en supposant que chaque terminal physique possède un type intrinsèque. Cependant, un « terminal » est aujourd'hui souvent en réalité un programme d'émulation de terminal s'exécutant dans un PC, capable d'émuler toute une gamme de types de terminaux. C'est pourquoi RFC-1091 étend la spécification afin de permettre une négociation plus générale du type de terminal entre le Telnet utilisateur et le Telnet serveur.
3.3 PROBLÈMES SPÉCIFIQUES
3.3.1 Convention de fin de ligne Telnet
Le protocole Telnet définit la séquence CR LF pour signifier « fin de ligne ». Pour l'entrée du terminal, cela correspond à une touche de complétion de commande ou « fin de ligne » pressée sur un terminal utilisateur ; sur un terminal ASCII, c'est la touche CR, mais elle peut également être étiquetée « Return » ou « Enter ».
Lorsqu'un serveur Telnet reçoit la séquence de fin de ligne Telnet CR LF comme entrée depuis un terminal distant, l'effet doit (MUST) être le même que si l'utilisateur avait pressé la touche « fin de ligne » sur un terminal local. Sur les hôtes serveurs qui utilisent ASCII, en particulier, la réception de la séquence Telnet CR LF doit causer le même effet qu'un utilisateur local pressant la touche CR sur un terminal local. Ainsi, CR LF et CR NUL doivent (MUST) avoir le même effet sur un hôte serveur ASCII lorsqu'ils sont reçus comme entrée sur une connexion Telnet.
Un Telnet utilisateur doit (MUST) être capable d'envoyer l'une des formes : CR LF, CR NUL et LF. Un Telnet utilisateur sur un hôte ASCII devrait (SHOULD) avoir un mode contrôlable par l'utilisateur pour envoyer soit CR LF soit CR NUL lorsque l'utilisateur presse la touche « fin de ligne », et CR LF devrait (SHOULD) être le défaut.
La séquence de fin de ligne Telnet CR LF doit (MUST) être utilisée pour envoyer des données Telnet qui ne proviennent pas d'un terminal vers un ordinateur (par exemple, lorsqu'un Telnet serveur envoie une sortie, ou lorsque le protocole Telnet est incorporé dans un autre protocole applicatif).
DISCUSSION :
Afin de permettre l'interopérabilité entre des clients et des serveurs Telnet arbitraires, le protocole Telnet a défini une représentation standard pour le terminateur de ligne. Comme le jeu de caractères ASCII ne comporte pas de caractère explicite de fin de ligne, les différents systèmes ont retenu des représentations différentes, par exemple CR, LF et la séquence CR LF. Le protocole Telnet a choisi la séquence CR LF comme standard pour la transmission réseau.
Malheureusement, la spécification du protocole Telnet dans RFC-854 [TELNET:1] s'est révélée quelque peu ambiguë quant au caractère que le client doit envoyer au serveur pour représenter la touche « fin de ligne ». Il en est résulté un problème d'interopérabilité important et persistant, aggravé par diverses implémentations erronées de Telnet utilisateur et serveur.
Bien que le protocole Telnet soit fondé sur un modèle parfaitement symétrique, dans une session de connexion à distance le rôle de l'utilisateur au terminal diffère de celui de l'hôte serveur. Par exemple, RFC-854 définit la signification de CR, LF et CR LF en tant que sortie du serveur, mais ne précise pas ce que le Telnet utilisateur doit envoyer lorsque l'utilisateur presse la touche « fin de ligne » de son terminal ; c'est là le point litigieux.
Lorsque l'utilisateur presse la touche « fin de ligne », certaines implémentations de Telnet utilisateur envoient CR LF, tandis que d'autres envoient CR NUL (en se fondant sur une lecture différente de la même phrase de RFC-854). Comme indiqué plus haut, ces deux formes sont équivalentes pour un hôte serveur ASCII correctement implémenté. Pour les autres serveurs, un mode est nécessaire dans le Telnet utilisateur.
L'existence de Telnet utilisateur n'envoyant que CR NUL lorsque CR est pressé crée un dilemme pour les hôtes non ASCII : soit ils traitent CR NUL en entrée comme équivalent à CR LF, excluant ainsi la possibilité de saisir un CR « nu », soit ils perdent toute interopérabilité.
Supposons qu'un utilisateur de l'hôte A se connecte via Telnet à l'hôte serveur B, puis exécute le programme Telnet utilisateur de B pour se connecter à l'hôte serveur C. Idéalement, la combinaison serveur/utilisateur Telnet sur B devrait être aussi transparente que possible, c'est-à-dire se comporter comme si A était directement connecté à C. En particulier, une implémentation correcte rendrait B transparent aux séquences de fin de ligne Telnet, à ceci près que CR LF pourrait être converti en CR NUL, et réciproquement.
IMPLÉMENTATION :
Pour comprendre le problème de la fin de ligne dans Telnet, il faut disposer au moins d'un modèle général de la relation entre Telnet et le système d'exploitation local. Le processus Telnet serveur est typiquement couplé au logiciel pilote de terminal du système d'exploitation en tant que pseudo-terminal. Une séquence de fin de ligne Telnet reçue par le Telnet serveur doit produire le même effet que l'appui sur la touche de fin de ligne d'un véritable terminal connecté localement.
Les systèmes d'exploitation qui prennent en charge des applications interactives caractère par caractère (par exemple les éditeurs) fournissent en général deux modes internes pour leurs E/S de terminal : un mode formaté, dans lequel les conventions locales de fin de ligne et d'autres règles de mise en forme ont été appliquées au flux de données, et un mode « brut » (raw), dans lequel l'application a un accès direct à chaque caractère saisi. Un Telnet serveur doit être implémenté de telle sorte que ces modes produisent le même effet pour le terminal distant que pour un terminal local. Par exemple, supposons qu'un Telnet serveur sur un hôte ASCII reçoive CR LF ou CR NUL ; en mode brut, le caractère CR est transmis à l'application, tandis qu'en mode formaté c'est la convention de fin de ligne du système local qui est utilisée.
3.3.2 Terminaux de saisie de données
DISCUSSION :
En plus des terminaux ASCII orientés ligne et orientés caractère pour lesquels Telnet a été conçu, il existe plusieurs familles de terminaux d'affichage vidéo parfois appelés « terminaux de saisie de données » ou DET. La famille IBM 3270 en est un exemple bien connu.
Deux protocoles Internet ont été conçus pour prendre en charge des DET génériques : SUPDUP [TELNET:16, TELNET:17] et l'option DET [TELNET:18, TELNET:19]. L'option DET utilise la (sous-)négociation pour piloter un terminal de saisie de données sur une connexion Telnet. SUPDUP est un protocole de terminal entièrement distinct, auquel on peut accéder depuis Telnet par négociation. Bien que SUPDUP et l'option DET aient tous deux été utilisés avec succès dans des environnements particuliers, aucun n'a connu d'acceptation générale ni d'implémentation étendue.
Une approche différente de l'interaction avec les DET s'est développée pour prendre en charge la famille IBM 3270 via Telnet, bien que la même méthode soit applicable à n'importe quel DET. L'idée est d'entrer dans un mode « DET natif », dans lequel le flux d'entrée/sortie natif du DET est envoyé comme données binaires. La commande Telnet EOR est utilisée pour délimiter les enregistrements logiques (par exemple des « écrans ») à l'intérieur de ce flux binaire.
IMPLÉMENTATION :
Les règles pour entrer dans le mode DET natif et en sortir sont les suivantes :
o Le serveur utilise l'option Terminal-Type [TELNET:10] pour apprendre que le client est un DET.
o Par convention (mais sans que cela soit requis), les deux extrémités négocient l'option EOR [TELNET:9].
o Les deux extrémités négocient l'option binaire [TELNET:3] pour entrer en mode DET natif.
o Lorsqu'une extrémité négocie la sortie du mode binaire, l'autre extrémité fait de même et le mode revient au NVT normal.
3.3.3 Exigences d'options
Chaque implémentation Telnet doit (MUST) supporter l'option binaire [TELNET:3] et l'option Suppress Go Ahead [TELNET:5], et devrait (SHOULD) supporter les options Echo [TELNET:4], Status [TELNET:6], End-of-Record [TELNET:9] et Extended Options List [TELNET:8].
Un Telnet utilisateur ou serveur devrait (SHOULD) supporter l'option Window Size [TELNET:12] si le système d'exploitation local fournit la capacité correspondante.
DISCUSSION :
Notez que l'option End-of-Record indique seulement qu'un Telnet est capable de recevoir un Telnet EOR sans se planter ; par conséquent, tout Telnet devrait être disposé à accepter la négociation de l'option End-of-Record. Voir également la discussion de la Section 3.2.3.
3.3.4 Initiation des options
Lorsque le protocole Telnet est utilisé dans une situation client/serveur, le serveur devrait (SHOULD) initier la négociation du mode d'interaction terminal qu'il attend.
DISCUSSION :
Le protocole Telnet est défini de manière parfaitement symétrique, mais son application est généralement asymétrique. On connaît des cas de connexions à distance ayant échoué parce qu'aucune des deux parties n'avait initié la négociation du mode de terminal non par défaut requis. C'est en général le serveur qui détermine le mode préféré ; il faut donc que le serveur initie la négociation. Comme la négociation est symétrique, l'utilisateur peut également l'initier.
Le client (Telnet utilisateur) devrait (SHOULD) fournir à l'utilisateur un moyen d'activer et de désactiver l'initiation de la négociation d'options.
DISCUSSION :
Un utilisateur a parfois besoin de se connecter à un service applicatif (par exemple FTP ou SMTP) qui utilise Telnet pour son flux de contrôle mais ne prend pas en charge les options Telnet. Si l'initiation de la négociation d'options peut être désactivée, le Telnet utilisateur peut alors être employé à cette fin.
3.3.5 Option Linemode de Telnet
DISCUSSION :
Une nouvelle option Telnet importante, LINEMODE [TELNET:12], a été proposée. L'option LINEMODE fournit une méthode standard pour qu'un Telnet utilisateur et un serveur Telnet conviennent que le client plutôt que le serveur effectuera le traitement des caractères du terminal. Lorsque le client a préparé une ligne complète de texte, il l'envoie au serveur (normalement) dans un seul segment TCP. Cette option réduira considérablement la surcharge en paquets des sessions Telnet et offrira à l'utilisateur une bien meilleure réactivité sur des réseaux congestionnés ou à long délai.
L'option LINEMODE permet de basculer dynamiquement entre le traitement local et le traitement distant des caractères. Par exemple, la connexion Telnet négociera automatiquement le passage en mode caractère par caractère pendant l'exécution d'un éditeur plein écran, puis reviendra en linemode à la fin de l'éditeur.
Nous nous attendons à ce que, au moment de la publication du présent RFC, les hôtes implémentent le côté client de cette option et puissent en implémenter le côté serveur. Pour implémenter correctement le côté serveur, le serveur doit pouvoir indiquer au système local de n'effectuer aucun traitement des caractères d'entrée, tout en mémorisant l'état courant du terminal et en notifiant le processus Telnet serveur lorsque cet état change. Cela permettra par exemple de traiter correctement l'écho des mots de passe et les éditeurs plein écran.
3.4 INTERFACE TELNET/UTILISATEUR
3.4.1 Transparence du jeu de caractères
Les implémentations Telnet utilisateur devraient (SHOULD) être capables d'envoyer ou de recevoir n'importe quel caractère ASCII 7 bits. Lorsque possible, toute interprétation de caractères spéciaux par le système d'exploitation de l'hôte utilisateur devrait (SHOULD) être contournée afin que ces caractères puissent être commodément envoyés et reçus sur la connexion.
Une certaine valeur de caractère doit (MUST) être réservée comme « échappement vers le mode commande » ; conventionnellement, doubler ce caractère permet de le saisir comme données. Le caractère spécifique utilisé devrait (SHOULD) être sélectionnable par l'utilisateur.
Sur une connexion en mode binaire, un programme Telnet utilisateur peut (MAY) fournir un mécanisme d'échappement pour saisir des valeurs 8 bits arbitraires, si le système d'exploitation de l'hôte ne permet pas de les entrer directement au clavier.
IMPLÉMENTATION :
La question de la transparence est moins pressante côté serveur, mais les implémenteurs devraient veiller à traiter correctement des points tels que : le masquage du bit de parité (envoyé par des clients anciens non conformes) avant que les données n'atteignent un programme n'attendant que du NVT ASCII, ainsi que la prise en charge correcte des programmes qui demandent un flux de données 8 bits.
3.4.2 Commandes Telnet
Un programme Telnet utilisateur doit (MUST) fournir à l'utilisateur la capacité d'entrer l'une des fonctions de contrôle Telnet IP, AO ou AYT, et devrait (SHOULD) fournir la capacité d'entrer EC, EL et Break.
3.4.3 Erreurs de connexion TCP
Un programme Telnet utilisateur devrait (SHOULD) signaler à l'utilisateur toute erreur TCP signalée par la couche transport (voir la section « Interface couche TCP/application » de [INTRO:1]).
3.4.4 Port de contact Telnet non par défaut
Un programme Telnet utilisateur devrait (SHOULD) permettre à l'utilisateur de spécifier optionnellement un numéro de port de contact non standard sur l'hôte serveur Telnet.
3.4.5 Vidage de la sortie
Un programme Telnet utilisateur devrait (SHOULD) fournir à l'utilisateur la capacité de spécifier si la sortie doit être vidée ou non lorsqu'un IP est envoyé ; voir Section 3.2.4.
Pour tout schéma de vidage de la sortie qui amène le Telnet utilisateur à supprimer localement la sortie jusqu'à la réception d'un signal Telnet en provenance du serveur, il devrait (SHOULD) exister un moyen pour l'utilisateur de rétablir manuellement la sortie normale, au cas où le serveur n'enverrait pas le signal attendu.
3.5 RÉSUMÉ DES EXIGENCES TELNET
| Fonctionnalité | Section | MUST | SHOULD | MAY | SHOULD NOT | MUST NOT |
|---|---|---|---|---|---|---|
| Négociation d'options | ||||||
| Implémenter la négociation d'options | 3.2.1 | ✓ | ||||
| Éviter les boucles de négociation | 3.2.1 | ✓ | ||||
| Refuser les options non supportées | 3.2.1 | ✓ | ||||
| Négociation OK à tout moment | 3.2.1 | ✓ | ||||
| Par défaut sur NVT | 3.2.1 | ✓ | ||||
| Envoyer nom officiel dans Term-Type | 3.2.8 | ✓ | ||||
| Accepter tout nom dans Term-Type | 3.2.8 | ✓ | ||||
| Implémenter Binary, Suppress-GA | 3.3.3 | ✓ | ||||
| Options Echo, Status, EOL, Ext-Opt-List | 3.3.3 | ✓ | ||||
| Option Window-Size si approprié | 3.3.3 | ✓ | ||||
| Serveur initie négociations de mode | 3.3.4 | ✓ | ||||
| Fonctions de contrôle | ||||||
| Supporter SE NOP DM IP AO AYT SB | 3.2.3 | ✓ | ||||
| Supporter EOR EC EL Break | 3.2.3 | ✓ | ||||
| Ignorer fonctions non supportées | 3.2.3 | ✓ | ||||
| Jeter données urgentes jusqu'à DM | 3.2.4 | ✓ | ||||
| Encodage | ||||||
| Ne pas envoyer bit haut en NVT | 3.2.5 | ✓ | ||||
| Ne pas envoyer bit haut comme parité | 3.2.5 | ✓ | ||||
| Toujours doubler octet IAC | 3.2.6 | ✓ | ||||
| Doubler IAC en mode binaire | 3.2.7 | ✓ | ||||
| Fin de ligne | ||||||
| EOL serveur = fin de ligne locale | 3.3.1 | ✓ | ||||
| Serveur ASCII accepte CR LF ou CR NUL | 3.3.1 | ✓ | ||||
| Utilisateur peut envoyer CR LF, CR NUL, LF | 3.3.1 | ✓ | ||||
| Utilisateur ASCII peut sélectionner CR LF/CR NUL | 3.3.1 | ✓ | ||||
| Mode par défaut utilisateur est CR LF | 3.3.1 | ✓ | ||||
| Interface utilisateur Telnet | ||||||
| E/S de tous les caractères 7 bits | 3.4.1 | ✓ | ||||
| Contourner interprétation OS locale | 3.4.1 | ✓ | ||||
| Caractère d'échappement | 3.4.1 | ✓ | ||||
| Caractère d'échappement paramétrable | 3.4.1 | ✓ | ||||
| Peut entrer IP, AO, AYT | 3.4.2 | ✓ | ||||
| Peut entrer EC, EL, Break | 3.4.2 | ✓ | ||||
| Signaler erreurs TCP à l'utilisateur | 3.4.3 | ✓ | ||||
| Port de contact non par défaut | 3.4.4 | ✓ | ||||
| Spécifier vidage sortie lors envoi IP | 3.4.5 | ✓ | ||||
| Restaurer manuellement mode sortie | 3.4.5 | ✓ |