Retour à l'index des Normes françaises
RFC: 854
Statut : Standard
Remplace: NIC 18639
Crédits : J. Postel, ISI, Mai 1983
Traduction : V.G. FREMAUX / Ingénieur Professeur / EISTI
Le texte suivant est la traduction intégrale de la spécification TELNET, telle qu'éditée par les auteurs originaux du protocole, sans ajouts, commentaires, ni omissions. Ce document est un standard reconnu et approuvé par la communauté Internet.
Cette RFC définit un standard pour la communauté ARPA Internet. Les hôtes ARPA Internet sont enjoints à adopter et implémenter ce protocole.
Le but du protocole TELNET est de permettre une communication bidirectionnelle simple, sur une base d'octets de huit bits. Son objectif premier est de permettre d'interfacer des terminaux et des applications à travers un réseau. Il est envisageable de pouvoir utiliser ce protocole pour une communication de terminal à terminal ("linking") ou d'application à application (applications distribuées).
Une connexion TELNET s'appuie sur une connexion TCP pour transmettre des données dans lesquelles s'intercalent des séquences de contrôle TELNET.
Le protocole TELNET est bâti selon trois principes essentiels: premièrement, le concept de terminal réseau virtuel (Network Virtual Terminal); deuxièmement, le principe d'options négociées; et troisièmement, une "vue" symétrique de chaque entité d'extrémité (processus ou terminal).
La stratégie de base pour déterminer la possibilité d'usage d'une option est que l'une des parties (ou les deux) émette une requête demandant l'utilisation de telle ou telle option. L'autre extrémité peut alors accepter ou rejeter cette requête. Si la requête est acceptée, son usage prend immédiatement effet; si elle est rejetée, alors s'applique la règle standard définie pour le NVT. En clair, une extrémité peut toujours refuser d'accorder la mise en uvre d'un caractère optionnel, mais ne doit jamais refuser une requête de désactivation d'une option, dans la mesure où tous les acteurs doivent au moins implémenter le modèle NVT.
La syntaxe de la négociation d'option a été faite de sorte que deux requêtes émises simultanément pour la même option apparaissent à l'autre bout comme une acceptation de leur propre requête.
(*) NdT : Après plusieurs tentatives de traduction de ces primitives, nous avons pensé qu'il était plus judicieux de laisser ces primitives en anglais, dans la mesure où il est assez difficile de trouver une correspondance exacte de ces auxiliaires dans ce contexte. Pour la suite de l'exposé, nous rajoutons ici une partie explicative non contenue dans la norme originale, destinée à fixer le cadre d'utilisation de ces quatre primitives :
|
WILL |
Indique le désir d'utiliser, ou confirme le début de l'utilisation de l'option spécifiée. Dans le sens de "Je ferais bien" ou "Je ferai" |
|
WON'T |
Indique le refus d'utiliser ou de continuer à utiliser l'option spécifiée. Dans le sens de "Je ne ferai pas (ou plus)". |
|
DO |
Notifie une requête pour que l'autre extrémité utilise, ou la confirmation que ce côté attend l'utilisation de l'option spécifiée. Dans le sens de "Utilise !" ou "fais !". |
|
DON'T |
Notifie une demande expresse que l'autre partie cesse d'utiliser, ou la confirmation que l'on attend plus l'usage, de l'option spécifiée. Dans le sens de "Ne fais pas !" |
a. Les acteurs ne doivent émettre des requêtes que pour demander le changement d'une option; c-à-d., éviter d'envoyer une commande pour indiquer dans quel mode on se trouve.
b. Si un acteur reçoit une requête lui demandant d'entrer dans un mode dans lequel il se trouve déjà, la requête ne doit pas être acquittée. Cette non-réponse est essentielle pour éviter le cas de bouclages protocolaires infinis. Il est important cependant qu'une réponse soit donnée à toute requête de changement de mode "justifiée" - même si c'est par la négative.
c. Lorsqu'une des deux parties émet une commande d'option vers l'autre, que ce soit une requête ou un acquittement d'une précédente requête, et dans la mesure où l'utilisation de cette option entraîne une modification du traitement effectué sur le représentation des données émises, alors cette commande doit être insérée dans le flux de données, à l'endroit à partir duquel elle doit prendre effet. (Il doit être noté ici qu'une certaine durée peut s'écouler entre l'émission première d'un requête et la réception de la réponse, qui peut d'ailleurs être négative. Pour cela, un hôte souhaitera pouvoir tamponner les données, après avoir requis une option, jusqu'à ce qu'il puisse être informé de l'acceptation ou du refus de cette option. Ceci permet alors de masquer cette période "d'incertitude" pour l'utilisateur).
De nombreuses requêtes d'option vont certainement s'entrecroiser à l'établissement d'une connexion TELNET, chacune des deux parties essayant d'obtenir le meilleur service de la part de la partie adverse. Outre ceci cependant, les options peuvent être utilisées pour modifier dynamiquement les caractéristiques d'une connexion afin de s'adapter à des changements de conditions locales. Par exemple, le NVT, comme il sera expliqué plus loin, utilise une "discipline" de transmission bien adaptée à des applications "interprétées par lignes" comme le BASIC, mais beaucoup moins adaptée à des applications fonctionnant au "caractère" comme pour NLS. Un serveur peut choisir d'affecter le processeur distant à des tâches nécessitant une technique de transmission au "caractère" uniquement lorsque le processeur local en a la nécessité et négocierait à ce moment seulement l'option correspondante. Toutefois, pour ne plus être "dérangé" à chaque caractère émis par le processeur distant, il pourra demander (c-à-d., négocier) le retour au mode NVT lorsqu'un contrôle au caractère n'est plus nécessaire.
Il est possible que des requêtes émises par des processus stimulent une boucle de requête infinie si le processus répond à un rejet par une nouvelle tentative de négociation de la même option. Pour éviter de tels bouclages du protocole, on ne devra jamais requérir une option rejetée tant qu'aucun événement ne suggère un changement dans la situation. Concrètement, cela peut vouloir dire que le processus déroule un code différent, ou une autre commande a été déclenchée par l'utilisateur, ou tout événement ayant une signification pour cette combinaison de processus et d'option. Une règle de sécurité consiste à ne jamais tenter de renégocier une option, sauf après réception d'information substantielle de la part du distant, ou après intervention volontaire de l'opérateur humain local.
Les programmeurs d'options ne doivent pas se sentir contraints par la syntaxe quelque peu limitée de négociation d'option. Le but premier d'une syntaxe aussi simple est de mettre facilement en uvre le mécanisme d'options - et de ce fait tout aussi facile de les ignorer. Si certaines options demandaient une mécanique de négociation un peu plus complexe qu'il n'est possible de réaliser avec les primitives "DO, DON'T, WILL, WON'T", la méthode acceptable est de s'en tenir à ce mécanisme pour établir si les deux parties connaissent l'option en question, et une fois cette confirmation obtenue, il est possible de mettre en uvre un mécanisme plus exotique sans crainte d'une possible incompréhension. Par exemple, une des parties pourrait envoyer une requête pour changer la longueur de la ligne. Si celle-ci est acceptée, alors une syntaxe différente peut être mise en application pour effectivement négocier la longueur de la ligne - telle qu'une négociation à plusieurs champs du type "ligne minimale/ligne maximale/ligne souhaitée". Le concept essentiel à respecter est qu'une négociation complexe ne puisse être effectuée sans le passage par une étape simple (standard) de négociation, établissant au préalable la capacité des deux parties à mener à bien la transaction plus fine.
Pour résumer, WILL XXX est émis par les deux côtés, pour indiquer que les deux parties désirent (offrent) utiliser l'option XXX, DO XXX et DON'T XXX représentant un acquittement positif ou négatif; de façon similaire, DO XXX est envoyé pour indiquer une demande à utiliser l'option XXX (par l'autre partie), WILL XXX et WON'T XXX étant alors les acquittements positifs et négatifs. Dans la mesure où le NVT est tout ce qui reste lorsqu'aucune option n'est active, les réponses DON'T et WON'T garantissent le passage à un état dans lequel les deux côtés peuvent se mettre en attente. Ainsi, tous les hôtes devront implémenter leur processus TELNET de sorte à ne pas reconnaître implicitement toute option non connue, en simplement renvoyant un refus à toute requête d'option qui ne peut être comprise.
Pour autant que possible, le protocole TELNET a rendu la communication serveur-utilisateur symétrique de sorte à pouvoir gérer aussi bien les connexions utilisateur-utilisateur (intercommunication) que serveur-serveur (applications distribuées). Il est souhaitable, mais non imposé, que les options respectent ce principe. Dans tous les cas, la symétrie reste un des principes généralement reconnus.
Le document associé, "TELNET Option Specifications," pourra être consulté pour connaître la procédure à suivre pour l'établissement de nouvelles options.
Le Network Virtual Terminal (NVT) est un composant réseau bidirectionnel en mode caractères. Le NVT dispose d'une sortie "d'impression" et d'un clavier. L'impression (au sens le plus large) reçoit le flux d'entrée de données et le clavier produit un flux sortant de données émis sur la connexion TELNET et, si un "écho local" est souhaité, également "imprimé" sur le NVT. Les "Echos" ne sont pas sensés traverser le réseau (bien que certaines options autorisent la génération de l'écho par le distant ("remote echoing"), aucun hôte n'est "obligé" de fournir cette option). Le jeu de caractères utilisé est l'ASCII-US sept bits dans un octet de huit bits, sauf cas particuliers décrits ici. Toute conversion de code et considérations temporelles sont des problématiques locales et n'affectent pas le NVT.
Bien qu'une connexion TELNET à travers le réseau soit intrinsèquement bidirectionnelle, le NVT doit être considéré comme un appareil unidirectionnel alterné (half-duplex) fonctionnant en mode tampon de ligne. C'est-à-dire, sauf et jusqu'à ce que des options ne soient négociées pour signifier le contraire, les conditions suivantes constituent la transmission de données par défaut sur une liaison TELNET :
Cette règle est motivée par le "coût" élevé, dans certains hôtes, du traitement des interruptions d'arrivée réseau, et correspond mieux à la spécification du NVT dans laquelle les échos ne traversent pas le réseau. De ce fait, il est raisonnable d'accumuler une certaine quantité de données à la source. De nombreux systèmes effectuent un traitement à la fin de chaque ligne (de nombreuses imprimantes en ligne ou lecteurs de cartes fonctionnent de cette façon), et la transmission sera donc déclenchée à la fin de la ligne. A l'inverse, un utilisateur ou un processus pourra souhaiter envoyer les données sans pour autant que la fin de ligne ne soit explicitement marquée; pour cela, les implémenteurs seront tenus de mettre à disposition un moyen de signaler que toutes les données rémanentes dans le tampon doivent être transmises.
Cette règle n'impose pas la transmission d'une commande TELNET GA à partir d'un terminal pour chaque fin de ligne, dans la mesure où les hôtes serveurs ne nécessitent pas, en général, de signal supplémentaire (en plus du caractère habituel fin-de-ligne ou tout autre caractère défini localement dans ce but) pour commencer leur exécution. Plutôt, la commande TELNET GA est destinée à aider un hôte local (celui de l'utilisateur) à piloter un terminal half-duplex équipé d'un clavier "verrouillable" tel qu'un IBM 2741. Une description de ce type de terminal et de son fonctionnement permettra de mieux comprendre l'utilité de la commande GA.
Une connexion depuis un terminal sur un hôte local est toujours sous contrôle soit de l'utilisateur, soit de l'hôte. Aucune des deux extrémités ne peut unilatéralement "prendre la main" sur l'autre; il faudra que la partie contrôlante laisse la main explicitement. Côté terminal, le matériel est conçu de sorte à laisser la main à l'hôte à chaque fois qu'une ligne est terminée (c'est-à-dire, lorsque la touche "Entrée" est frappée par l'utilisateur). Dès que c'est le cas, l'ordinateur (local) rattaché traite la ligne d'entrée, décide des sorties à générer, en l'absence desquelles la main est rendue au terminal. Si une sortie doit être faite, l'ordinateur gardera le contrôle de la connexion jusqu'à ce que toutes les données soient émises.
La difficulté d'utiliser ce type de liaison à travers un réseau est évidente. L'hôte local n'est plus en position pour décider s'il doit garder le contrôle de la liaison sur le terminal après réception d'une fin-de-ligne ou au contraire rendre la main; cette décision ne peut être prise que par l'hôte "distant" qui exécute le processus de traitement. La commande TELNET GA institue un mécanisme par lequel le processus "distant" (serveur) peut signaler à l'hôte local qu'il est temps de redonner la main au terminal (donc à l'utilisateur). Elle doit être utilisée au moment (et seulement au moment) où la main doit être redonnée à l'utilisateur. Notez que la transmission prématurée d'une commande GA peut provoquer le blocage de "l'impression" de donnée, dans la mesure où il sera en droit de considérer que la voie de transmission s'est libérée, et échouera dans sa tentative d'inverser le sens de communication (on rappelle ici que nous sommes typiquement dans le cas d'un terminal à liaison unidirectionnelle alternée ou "half-duplex").
Ce qui précède, bien sûr, ne s'applique pas pour la direction de communication dans le sens utilisateur vers serveur. Dans cette direction, des commandes GA peuvent être émises à tout moment, mais ce n'est à la rigueur même pas nécessaire. Dans le même ordre d'idée, si la connexion TELNET est utilisée pour une communication de processus à processus, les commandes GA ne sont utiles dans aucune des deux directions. Enfin, pour une communication de terminal à terminal, des commandes GA peuvent être nécessaires dans aucune, une seule, ou les deux directions. Lorsqu'un hôte prévoit d'autoriser la communication de terminal à terminal, il est suggéré que l'hôte donne à l'utilisateur un moyen de signaler manuellement qu'il est temps d'envoyer une commande GA vers l'autre extrémité de la connexion TELNET; ceci, cependant, n'est pas une obligation pour les programmeurs d'applications TELNET.
Notez dans ce cas qu'étant donné la symétrie du modèle TELNET, il est supposé que l'on a affaire à un NVT à chaque extrémité de la connexion TELNET, du moins conceptuellement.
Comme il a été dit dans l'introduction de ce document, l'objectif premier du protocole TELNET est de fournir une interface standard de terminaux et de processus "orientés terminaux" à travers une liaison réseau. Des expériences précédentes de ce type d'interconnexion ont montré que ces fonctionnalités sont implémentées dans de nombreux serveurs, mais que les méthodes d'invocation de ces fonctions sont très diversifiées. Pour un utilisateur humain qui doit travailler simultanément sur plusieurs serveurs de natures différentes, cette hétérogénéité est assez frustrante. TELNET, pour cela, définit une représentation standardisée pour cinq de ces fonctionnalités, telles que décrites ci-après. Ces représentations standard ont des significations elles aussi standard, bien que non obligatoires (à l'exception que la fonction Interrupt Process (IP) peut être imposée par d'autres protocoles s'appuyant sur TELNET); en somme, un système qui ne proposerait pas une fonction identique à ses utilisateurs locaux n'est nullement obligé de proposer une telle fonction à ses utilisateurs distants et pourra interpréter l'appel d'une telle commande comme s'il s'agissait d'une No-operation. A l'inverse, un système qui propose la commande à ses utilisateurs locaux est tenu de reconnaître et d'exécuter cette commande pour des utilisateurs distants qui utiliseraient la représentation standard appropriée.
De nombreux systèmes procurent une commande qui permet de suspendre, interrompre, arrêter brutalement, ou provoquer la fin normale d'un processus utilisateur. Cette fonction est fréquemment utilisée lorsque l'utilisateur pense que son programme est parti dans une boucle infinie, ou lorsqu'un programme a été lancé par inadvertance. IP est la représentation standardisée de cette fonctionnalité. Les implémenteurs devront noter qu'IP peut être nécessaire à d'autres protocoles se basant sur TELNET, et que cette fonctionnalité devra être implémentée si l'on prévoit d'utiliser ces protocoles par la suite.
De nombreux systèmes procurent une fonction qui, lorsqu'un processus "imprime" des données à l'écran, en permet l'exécution normale (ou du moins, le déroulement jusqu'au même point que si l'exécution est faite sans utilisation de cette commande) mais sans imprimer les sorties sur le terminal utilisateur. En plus, cette fonction videra tout tampon intermédiaire des données déjà sorties par le processus, mais non encore "imprimées" (ou affichées) à l'écran. AO est la représentation standardisée pour cette fonctionnalité. Par exemple, certains systèmes d'exploitation (ou sous systèmes, par exemple un Shell fils), suite à une commande utilisateur, renvoient en réponse une longue chaîne de caractères sur le terminal de l'utilisateur, puis signalent qu'ils sont prêt à recevoir une nouvelle commande en affichant un caractère de "prompt" (précédé d'un <CR><LF>). Si la commande AO est reçue pendant la transmission de la chaîne de texte, une implémentation "sensée" supprimerait ce qu'il reste à afficher de la chaîne, mais laisserait au minimum passer le "prompt" et la séquence <CR><LF> qui le précède. (Ceci peut se distinguer de l'action qui pourrait être menée dans le cas d'une commande IP; cette dernière provoquerait la suppression de la fin de la ligne de texte, mais en plus la sortie du sous-système, suivant le cas).
Il doit être rappelé, pour les serveurs qui implémentent cette fonctionnalité, qu'il peut exister des tampons de données extérieurs au système lui-même (dans le réseau, et sur l'hôte local où est raccordé l'utilisateur) qui devraient aussi être vidés; la manière de le faire est d'envoyer le signal "Synch" (décrit ci-après) à l'hôte local.
De nombreux systèmes proposent à l'utilisateur une méthode pour tester d'une façon explicite (ex, à l'écran) si le système est toujours opérationnel. Cette fonction peut être invoquée lorsque le système reste "silencieux" pendant un temps apparemment long, peut être parce que le traitement des données est subjectivement plus long que ce qu'avait prévu l'utilisateur, ou à cause d'une surcharge temporaire, etc. AYT est la représentation standard de cette fonctionnalité.
La plupart des systèmes proposent une fonction pour effacer la dernière position de caractère "imprimé"* dans le flux de données entré par l'utilisateur. Cette fonction est typiquement utilisée pour éditer et corriger la ligne d'entrée lorsque des erreurs y ont été commises. EC est la représentation standard pour cette fonctionnalité.
*NOTE: Une position de caractère "imprimé" peut contenir plusieurs caractères comme le résultat d'une surcharge, notamment des séquences de type <char1> BS <char2> ou BS est le caractère de retour arrière et <char2> le caractère "corrigé".
La plupart des systèmes proposent une fonction qui permet l'effacement complet de la "ligne" d'entrée. Cette fonction est typiquement utilisée pour taper une nouvelle ligne de commande à la place d'une autre qui est abandonnée. EL est la représentation standard pour cette fonctionnalité.
La plupart des systèmes en temps partagé proposent des mécanismes qui permet à l'utilisateur d'un terminal de reprendre la main sur un processus "en rideau"; les fonctions IP et AO sont des exemples de ces mécanismes. De tels systèmes, pour ce qui est des utilisateurs locaux, ont accès à tous les signaux émis par ces derniers, soit sous forme de caractères normaux ou signaux "hors bande" implémentés par le matériel telle que ceux produits par activation de la touche "BREAK" d'un Télétype ou de la touche "ATTN" de l'IBM 2741. Ceci n'est évidemment pas nécessairement vrai lorsque le terminal est raccordé via un réseau; les mécanismes de contrôle de flux du réseau peuvent obliger à une rétention de ces données, notamment au niveau de l'hôte local associé à l'utilisateur.
Pour contourner ce problème, le mécanisme du signal "Synch" a été introduit dans TELNET. Un signal Synch utilise le mécanisme d'urgence de TCP, couplé à une commande DATA MARK de TELNET. L'introduction de données urgentes dans un flux TCP, lesquelles outrepassent les règles de contrôle de flux établies pour la connexion TELNET normale, est utilisée pour indiquer au processus récepteur d'entrer dans un mode particulier de traitement des données émises sur le réseau. Dans ce mode, le flux d'arrivée réseau est inspecté en permanence dans l'attente de signaux "significatifs" décrits ci-après, toute autre donnée étant ignorée. La commande DATA MARK (DM) de TELNET est la marque de synchronisation dans le flux de données qui indique que la commande spéciale a été d'ores et déjà envoyée et que le récepteur peut . ʑ(( ˑ(Kp .. ʑ(( ˑ(= AR t C M A g 1 . t x t RTCMAG~1TXT ڴ(( ۴(]{ ~ 0 x x . .t m p 0XX TMP ڴ(( ۴(k{