3. Conventions Telnet proposées
3A.
Le site serveur doit initialement supposer que l'écho est assuré par un processus du site utilisateur, jusqu'à instruction explicite contraire. Si le site utilisateur peut envoyer caractère par caractère, alors, une fois la connexion et la session établies, l'utilisateur peut passer à l'écho par le site serveur (server-site-echo) au moyen d'une commande adressée au site serveur, puis commander (de manière invisible pour le site serveur) son Telnet local pour changer également son mode d'écho.
3B.
Le processus serveur doit supposer qu'il recevra le même jeu de caractères que celui que peuvent générer les terminaux « directement » raccordés à lui. (Nous recommandons au moins l'ASCII à 128 caractères.) Le Telnet de l'utilisateur devra peut-être reconnaître des séquences de deux caractères pour permettre la génération à la fois des codes majuscules et minuscules et des codes de contrôle. Nous recommandons que l'utilisateur puisse fixer majuscules ou minuscules comme casse par défaut pour les terminaux à casse unique et puisse spécifier un caractère de bascule de casse (case shift character). L'utilisateur devrait également pouvoir spécifier un caractère pour indiquer que le caractère frappé juste après doit être converti en code de caractère de contrôle approprié. Cette dernière convention permet aux codes de contrôle générés directement au terminal d'être reconnus par le système de l'utilisateur, permettant ainsi l'échappement vers le système utilisateur. Établir une convention permettant à tous les codes de contrôle d'entrer dans le réseau, et à la sortie du réseau d'alimenter le moniteur du serveur avant d'entrer dans le processus serveur, fournit un mécanisme simple pour générer un échappement vers de nombreux systèmes existants. (Pour certains systèmes, le problème est plus compliqué que cela et nous en discutons plus bas.)
3C.
Nous recommandons que des normes réseau soient établies pour la signification des échos locaux de HT, VT et FF, ou qu'une convention soit établie pour transmettre au processus serveur la signification de ces caractères. Le NLS(NIC), par exemple, doit suivre la position de la tête d'impression et, en l'absence de telles conventions, convertira ces codes de caractères en espaces et sauts de ligne. Cela signifie que l'aspect de la page en sortie peut différer de l'aspect en entrée. Il serait utile à l'utilisateur que sa page en sortie puisse être mise en forme telle qu'elle apparaissait en entrée.
3D.
Les caractères LF seraient traités comme s'ils étaient générés par la frappe de la touche de saut de ligne sur un terminal « directement » raccordé au système serveur.
3E.
Le caractère retour chariot (CR) peut être une source de difficultés considérables. Par exemple, en entrée, des systèmes différents, ou le même système à des moments différents, peuvent renvoyer en écho et transmettre des codes différents au terminal et au processus utilisateur. Certains systèmes moniteur ne renvoient rien en écho, ou seulement un CR, ou un CRLF. Certains systèmes transmettent un CR, un CRLF ou un code de fin de ligne (end of line, EOL) au processus utilisateur. Le processus utilisateur peut contrôler l'écho ou s'y ajouter. Compte tenu des combinaisons qui peuvent exister à chaque extrémité de la connexion réseau et entre elles, une confusion peut régner si nous ne supposons pas la définition du point 2A et la convention de mise en œuvre du point 2E. Ces hypothèses impliquent que lorsqu'un CR est frappé, un CR est envoyé sur le réseau. Si le système moniteur de l'utilisateur ou le matériel de contrôle de terminal convertit un CR en CRLF ou en EOL, alors le programme Telnet doit le reconvertir en CR. Lorsque le CR atteint le moniteur du serveur, celui-ci le traitera correctement pour le processus serveur.
Lorsque l'écho est assuré par le système serveur, le ou les codes appropriés seront renvoyés en écho. Le Telnet de l'utilisateur, à la réception d'un CRLF, peut le compléter par les caractères nuls (null) appropriés pour gérer la temporisation du mouvement du chariot d'un terminal particulier.
Lorsque l'écho est assuré par le système utilisateur, il serait idéal que le Telnet ou le système de l'utilisateur emploie la même convention d'écho que le système serveur. Cela signifie que le Telnet doit soit disposer d'une table des conventions d'écho des divers systèmes auxquels il peut se connecter, soit pouvoir obtenir cette information du système ou du processus serveur, ou inversement.
Pour un protocole Telnet initial, ce n'est probablement pas nécessaire. Le système utilisateur peut adopter par défaut un écho de CRLF pour chaque CR reçu. Ce comportement par défaut devrait convenir à toutes les situations que nous connaissons et au NIC.
3F.
Pour la communication depuis des systèmes caractère par caractère et ligne par ligne, le processus Telnet peut devoir reconnaître un caractère (affectable par l'utilisateur) que nous appelons fin de flot (end of stream, EOS). Ce caractère doit remplir la fonction définie dans la discussion qui suit. Le point important est de distinguer la fin de flot (end-of-stream), qui est une fonction réseau, de la fin de ligne (end-of-line), qui est une fonction du système utilisateur ou serveur. Considérons d'abord les systèmes ligne par ligne. Nous n'avons pas beaucoup d'expérience des systèmes ligne par ligne, aussi ce qui suit devra-t-il faire l'objet d'une étude et d'une clarification plus poussées. D'après ce que nous comprenons, les systèmes ligne par ligne reconnaissent un caractère tel que CR ou un signal de rupture (break) comme le code qui réveille le processus utilisateur et provoque la transmission vers lui de la ligne de texte. Du point de vue du NLS(NIC), il est important que l'utilisateur puisse saisir des lignes de texte terminées chacune par un CR lorsque c'est approprié, et qu'à d'autres moments il puisse saisir du texte non terminé par un CR. (Une expression pour le NLS(NIC) est une chaîne de texte de longueur « arbitraire » et n'a pas besoin de contenir de CR ; en sortie, la ligne est repliée pour l'utilisateur à sa frontière de page, définissable par l'utilisateur.)
Comme exemple de ce qui est requis, considérons le cas où le système de l'utilisateur reconnaît le CR comme fin de ligne. Dans ce cas, le Telnet est réveillé à la réception d'un CR. Nous recommanderions alors que le code CR soit placé littéralement dans le tampon de sortie du Telnet. Si un CR est précédé d'un caractère EOS, le CR ne doit pas être placé dans le tampon de sortie du Telnet. La transmission à travers le réseau peut se produire soit à la réception d'un EOS, soit automatiquement lorsque le tampon de sortie du Telnet se remplit. La transmission depuis des systèmes ligne par ligne vers des systèmes caractère par caractère pourrait exiger la frappe malcommode de trois touches pour faire passer un caractère à travers le réseau.
Considérons maintenant la transmission depuis un système caractère par caractère vers un système serveur ligne par ligne. Un problème similaire à celui qui va être décrit existe également entre systèmes ligne par ligne. Étant donné la définition d'un caractère EOS différent du CR, une ligne peut être mise en mémoire tampon jusqu'à la réception de l'EOS, puis envoyée sans l'EOS. Comment le système desservant sait-il qu'une ligne a été envoyée ? Une manière serait que le NCP desservant reconnaisse les frontières de messages. Cette convention violerait un objectif de conception. Une autre manière serait que le Telnet de l'utilisateur demande à son NCP d'envoyer une commande INS. L'envoi de commandes de contrôle de type INS pourrait introduire des situations de compétition (race conditions) dans le réseau et devrait être étudié avant que leur emploi avec un processus Telnet ne soit arrêté. Comme certains des systèmes ligne par ligne que nous connaissons disposent d'un matériel spécial qui reconnaît le signal de fin de ligne, nous avons besoin d'un moyen d'être compatibles avec ce matériel au moyen de signaux de contrôle logiciels. Nous laissons ce problème à l'étude par le sous-groupe du NWG.
3G.
Nous revenons maintenant au problème de l'interruption ou de l'échappement dans le système serveur distant. Dans les systèmes qui ne verrouillent pas le clavier d'entrée pendant qu'une sortie est en cours, les mécanismes et conventions décrits ci-dessus semblent adéquats, sauf si le signal d'échappement est un signal de rupture (break) particulier. Ce dernier cas exige une étude plus approfondie. Dans les systèmes qui n'autorisent aucune entrée pendant qu'une sortie est en cours, il faudra peut-être subir les conséquences d'une telle discipline de terminal et se préparer à attendre l'arrêt de la sortie avant de pouvoir envoyer un code d'échappement. Si le clavier est verrouillé et qu'un signal de rupture d'échappement peut être envoyé au système de l'utilisateur, il peut empêcher la sortie d'atteindre le terminal, mais il faut être prêt à continuer de la recevoir depuis le site serveur jusqu'à ce que l'utilisateur puisse informer son processus Telnet d'envoyer un signal d'interruption ou d'échappement au site serveur. Ceci, là encore, est un problème à étudier plus avant.
Le système en ligne (Online System) du Network Information Center fonctionne sur un système moniteur caractère par caractère et les conventions établies dans le présent document suffisent pour y accéder. Ces conventions sont résumées dans l'annexe A.