General Considerations (Considérations générales)

Une connexion TELNET (TELNET Connection) est une connexion Transmission Control Protocol (TCP, Transmission Control Protocol) utilisée pour transmettre des données entrelacées d'informations de contrôle TELNET (Control Information).

Le protocole TELNET (TELNET Protocol) est construit sur trois idées principales : premièrement, le concept de "Terminal Virtuel Réseau" (Network Virtual Terminal) ; deuxièmement, le principe des options négociées (Negotiated Options) ; et troisièmement, une vue symétrique des terminaux et des processus (Symmetric View).

Lorsqu'une connexion TELNET est établie pour la première fois, chaque extrémité est supposée provenir et se terminer à un "Terminal Virtuel Réseau" (Network Virtual Terminal, NVT). Un NVT est un dispositif imaginaire (Imaginary Device) qui fournit une représentation intermédiaire (Intermediate Representation) standard à l'échelle du réseau d'un terminal canonique (Canonical Terminal). Cela élimine la nécessité pour les hôtes "serveur" (Server) et "utilisateur" (User) de conserver des informations sur les caractéristiques des terminaux de l'autre et les conventions de traitement des terminaux. Tous les hôtes, qu'ils soient utilisateurs ou serveurs, mappent leurs caractéristiques et conventions de dispositifs locaux pour sembler traiter avec un NVT sur le réseau, et chacun peut supposer un mappage similaire par l'autre partie. Le NVT vise à trouver un équilibre entre être trop restrictif (ne pas fournir aux hôtes un vocabulaire suffisamment riche pour mapper leurs jeux de caractères locaux) et être trop inclusif (pénaliser les utilisateurs avec des terminaux modestes).

REMARQUE : L'hôte "utilisateur" est l'hôte auquel le terminal physique est normalement connecté, et l'hôte "serveur" est l'hôte qui fournit normalement un service. Comme point de vue alternatif, applicable même dans les communications terminal à terminal ou processus à processus, l'hôte "utilisateur" est l'hôte qui a initié la communication.
Le principe des options négociées reconnaît le fait que de nombreux hôtes souhaiteront fournir des services supplémentaires au-delà de ceux disponibles dans un NVT, et que de nombreux utilisateurs disposeront de terminaux sophistiqués et souhaiteront avoir des services élégants plutôt que minimaux. Indépendantes de, mais structurées dans le protocole TELNET, se trouvent diverses "options" (Options) qui seront approuvées et peuvent être utilisées avec la structure "DO, DON'T, WILL, WON'T" (discutée ci-dessous) pour permettre à un utilisateur et un serveur de convenir d'utiliser un ensemble plus élaboré (ou peut-être simplement différent) de conventions pour leur connexion TELNET. Ces options pourraient inclure le changement du jeu de caractères (Character Set), du mode écho (Echo Mode), etc.

La stratégie de base pour configurer l'utilisation des options consiste à ce qu'une partie (ou les deux) initie une demande pour qu'une option prenne effet. L'autre partie peut alors accepter ou rejeter la demande. Si la demande est acceptée, l'option prend effet immédiatement ; si elle est rejetée, l'aspect associé de la connexion reste tel que spécifié pour un NVT. Clairement, une partie peut toujours refuser une demande d'activation, et ne doit jamais (must never) refuser une demande de désactivation d'une option puisque toutes les parties doivent être prêtes à supporter le NVT.

La syntaxe de négociation d'options a été configurée de sorte que si les deux parties demandent une option simultanément, chacune verra la demande de l'autre comme l'accusé de réception positif de la sienne.
La symétrie de la syntaxe de négociation peut potentiellement conduire à des boucles d'accusé de réception non terminantes (Nonterminating Acknowledgment Loops) -- chaque partie voyant les commandes entrantes non pas comme des accusés de réception mais comme de nouvelles demandes qui doivent être acquittées. Pour empêcher de telles boucles, les règles suivantes prévalent :

a. Les parties ne peuvent demander qu'un changement d'état d'option ; c'est-à-dire qu'une partie ne peut pas (may not) envoyer une "demande" simplement pour annoncer dans quel mode elle se trouve.

b. Si une partie reçoit ce qui semble être une demande pour entrer dans un mode dans lequel elle se trouve déjà, la demande ne devrait pas (should not) être acquittée. Cette non-réponse est essentielle pour empêcher les boucles infinies dans la négociation. Il est requis (required) qu'une réponse soit envoyée aux demandes de changement de mode -- même si le mode n'est pas changé.

c. Chaque fois qu'une partie envoie une commande d'option à une seconde partie, que ce soit comme demande ou comme accusé de réception, et que l'utilisation de l'option aura un effet sur le traitement des données envoyées de la première partie à la seconde, alors la commande doit (must) être insérée dans le flux de données au point où il est souhaité qu'elle prenne effet. (Il convient de noter qu'un certain temps s'écoulera entre la transmission d'une demande et la réception d'un accusé de réception, qui peut être négatif. Ainsi, un hôte peut souhaiter mettre en mémoire tampon les données, après avoir demandé une option, jusqu'à ce qu'il apprenne si la demande est acceptée ou rejetée, afin de cacher la "période d'incertitude" (Uncertainty Period) à l'utilisateur.)

Les demandes d'options sont susceptibles de fuser dans les deux sens lorsqu'une connexion TELNET est établie pour la première fois, chaque partie tentant d'obtenir le meilleur service possible de l'autre partie. Au-delà de cela, cependant, les options peuvent être utilisées pour modifier dynamiquement les caractéristiques de la connexion pour s'adapter aux conditions locales changeantes. Par exemple, le NVT, comme expliqué plus tard, utilise une discipline de transmission bien adaptée aux nombreuses applications "ligne par ligne" (Line at a Time) telles que BASIC, mais mal adaptée aux nombreuses applications "caractère par caractère" (Character at a Time) telles que NLS. Un serveur pourrait choisir de consacrer la surcharge de processeur supplémentaire requise pour une discipline "caractère par caractère" lorsque cela convient au processus local et négocierait une option appropriée. Cependant, plutôt que d'être ensuite définitivement chargé de la surcharge de traitement supplémentaire, il pourrait basculer (c'est-à-dire négocier) vers NVT lorsque le contrôle détaillé n'est plus nécessaire.

Il est possible que des demandes initiées par des processus stimulent une boucle de demande non terminante si le processus répond à un rejet en redemandant simplement l'option. Pour empêcher de telles boucles de se produire, les demandes rejetées ne devraient pas (should not) être répétées jusqu'à ce que quelque chose change. Sur le plan opérationnel, cela peut signifier que le processus exécute un programme différent, ou que l'utilisateur a donné une autre commande, ou tout ce qui a du sens dans le contexte du processus donné et de l'option donnée. Une bonne règle empirique est qu'une nouvelle demande ne devrait se produire qu'à la suite d'informations ultérieures de l'autre extrémité de la connexion ou lorsqu'elle est demandée par une intervention humaine locale.

Les concepteurs d'options ne devraient pas se sentir contraints par la syntaxe quelque peu limitée disponible pour la négociation d'options. L'intention de la syntaxe simple est de faciliter la présence d'options -- puisqu'il est correspondamment facile de professer l'ignorance à leur sujet. Si une option particulière nécessite une structure de négociation plus riche que celle possible dans "DO, DON'T, WILL, WON'T", la bonne approche consiste à utiliser "DO, DON'T, WILL, WON'T" pour établir que les deux parties comprennent l'option, et une fois cela accompli, une syntaxe plus exotique peut être utilisée librement. Par exemple, une partie peut envoyer une demande pour modifier (établir) la longueur de ligne (Line Length). Si elle est acceptée, alors une syntaxe différente peut être utilisée pour négocier réellement la longueur de ligne -- une telle "sous-négociation" (Sub-Negotiation) pourrait inclure des champs pour les longueurs de ligne minimales autorisées, maximales autorisées et souhaitées. Le concept important est que de telles négociations étendues ne devraient jamais commencer avant qu'une négociation préalable (standard) ait établi que les deux parties sont capables d'analyser la syntaxe étendue.

En résumé, WILL XXX est envoyé, par l'une ou l'autre partie, pour indiquer le désir (offre, Offer) de cette partie de commencer à exécuter l'option XXX, DO XXX et DON'T XXX étant ses accusés de réception positifs et négatifs ; de même, DO XXX est envoyé pour indiquer un désir (demande, Request) que l'autre partie (c'est-à-dire le destinataire du DO) commence à exécuter l'option XXX, WILL XXX et WON'T XXX étant les accusés de réception positifs et négatifs. Puisque le NVT est ce qui reste lorsqu'aucune option n'est activée, les réponses DON'T et WON'T garantissent de laisser la connexion dans un état que les deux extrémités peuvent gérer. Ainsi, tous les hôtes peuvent implémenter leurs processus TELNET pour être totalement inconscients des options non prises en charge, retournant simplement un rejet à (c'est-à-dire refusant) toute demande d'option qui ne peut pas être comprise.

Autant que possible, le protocole TELNET a été rendu symétrique serveur-utilisateur afin qu'il couvre facilement et naturellement les cas utilisateur-utilisateur (liaison, Linking) et serveur-serveur (processus coopérants, Cooperating Processes). Il est espéré, mais pas absolument requis, que les options favoriseront davantage cette intention. En tout cas, il est explicitement reconnu que la symétrie est un principe de fonctionnement plutôt qu'une règle absolue.

Un document complémentaire, "Spécifications des options TELNET" (TELNET Option Specifications), devrait (should) être consulté pour des informations sur la procédure d'établissement de nouvelles options.