Groupe de travail Réseau |
J. Postel |
Request for Comments : 856 |
J. Reynolds, ISI |
STD 27 |
|
Document rendu obsolète : NIC 15389 |
mai 1983 |
Traduction Claude Brière de L’Isle
La présente RFC spécifie une norme pour la communauté ARPA Internet. Les hôtes sur l’ARPA Internet sont supposés adopter et mettre en œuvre cette norme.
TRANSMIT-BINARY 0
IAC WILL TRANSMIT-BINARY
L’envoyeur de cette commande DEMANDE la permission de commencer à transmettre, ou confirme qu’il va commencer maintenant à transmettre des caractères qui sont à interpréter comme des données binaires de 8 bits par le receveur des données.
IAC WON'T TRANSMIT-BINARY
Si la connexion fonctionne déjà en mode de transmission binaire, l’envoyeur de cette command DEMANDE à commencer de transmettre les caractères de données qui sont à interpréter comme des caractères ASCII NVT standard par le receveur des données. Si la connexion ne fonctionne pas déjà en mode de transmission binaire, l’envoyeur de cette commande REFUSE de commencer à transmettre des caractères qui sont à interpréter comme des caractères binaires par le receveur des données (c’est-à-dire que l’envoyeur des données demande de continuer à transmettre des caractères dans le mode présent).
Une connexion ne fonctionne en mode de transmission binaire que lorsqu’une partie l’a demandé et que l’autre en a accusé réception.
IAC DO TRANSMIT-BINARY
L’envoyeur de cette commande DEMANDE que l’envoyeur des données commence à transmettre, ou confirme que l’envoyeur des données est supposé transmettre, des caractères qui sont à interpréter comme des donnée binaires de 8 bits (c’est-à-dire, par la partie qui envoie cette commande).
IAC DON'T TRANSMIT-BINARY
Si la connexion fonctionne déjà en mode de transmission binaire, l’envoyeur de cette commande DEMANDE que l’envoyeur des données commence à transmettre des caractères qui sont à interpréter comme des caractères ASCII NVT standard par le receveur des données (c’est-à-dire, la partie qui envoie cette commande). Si la connexion ne fonctionne pas déjà en mode de transmission binaire, l’envoyeur de cette commande DEMANDE que l’envoyeur des données continue de transmettre des caractères qui sont à interpréter dans le présent mode.
Une connexion ne fonctionne en mode de transmission binaire que lorsqu’une partie l’a demandé et que l’autre en a accusé réception.
WON'T TRANSMIT-BINARY
DON'T TRANSMIT-BINARY
La connexion ne fonctionne pas en mode binaire.
Il est parfois utile d’avoir un chemin de transmission binaire disponible au sein de TELNET sans avoir à utiliser un des protocoles plus efficaces de niveau supérieur qui fournissent des transmissions binaires (comme le protocole de transfert de fichier FTP). L’utilisation du préfixe IAC au sein du protocole TELNET de base procure l’option de la transmission binaire d’une façon naturelle, n’exigeant que l’ajout d’un mécanisme par lequel les parties impliquées peuvent se mettre d’accord pour INTERPRETER les caractères transmis sur une connexion TELNET comme des données binaires.
Avec l’activation de l’option de transmission binaire, le receveur devrait interpréter les caractères reçus de l’émetteur qui ne sont pas précédés de IAC comme des données binaires à 8 bits, avec l’exception de IAC suivi par IAC ce qui signifie des données binaires à 8 bits avec la valeur décimale 255. IAC suivi par une commande TELNET effective (plus tous caractères supplémentaires requis pour compléter la commande) est encore la commande même avec l’option de transmission binaire activée. IAC suivi par un caractère qui n’est pas une commande TELNET définie a la même signification que IAC suivi par NOP, bien que un IAC suivi par une commande indéfinie ne devrait normalement pas être envoyé dans ce mode.
Il est prévu que les mises en oeuvre de l’option de transmission binaire choisiront de refuser d’autres options (comme l’option de transmission EBCDIC) lorsque l’option de transmission binaire est activée. Cependant, si une paire d’hôtes peut accepter d’être simultanément en mode de transmission binaire et, par exemple, en mode écho, il n’y a rien à y redire s’ils négocient cette combinaison.
Il faut mentionner que la signification de WON'T et DON'T dépend du fonctionnement actuel de la connexion en mode binaire ou non. Si on considère une connexion qui fonctionne, par exemple, en mode EBCDIC qui implique un système qui a choisi de e pas mettre en oeuvre la reconnaissance de la commande binaire. Si ce système doit recevoir un DO RANSMIT-BINARY, il ne reconnaître pas l’option TRANSMIT-BINARY et va donc retourner un WON'T TRANSMIT-BINARY. Si la valeur par défaut pour le WON'T TRANSMIT-BINARY était toujours de l’ASCII NVT, l’envoyeur du DO TRANSMIT-BINARY s’attendrait à ce que le receveur soit passé en ASCII NVT, alors que le receveur du DO TRANSMIT-BINARY ne fera pas cette interprétation.
Et donc, nous avons la règle que lorsqu’une connexion ne fonctionnement pas actuellement en mode binaire, le mode par défaut (c’est à dire, l’interprétation de WON'T et DON'T) est de continuer à fonctionner dans le mode actuel, que ce soit de l’ASCII NVT, de l’EBCDIC, ou tout autre mode. Cependant, cette règle ne s’applique plus une fois qu’une connexion fonctionne dans un mode binaire (tel que les deux extrémités sont tombées d’accord) ; ceci exigerait que chaque extrémité de la connexion maintienne une pile, contenant toutes les transitions de méthodes de codage qui sont survenues précédemment sur la connexion, afin d’interpréter correctement un WON'T ou un DON'T. Et donc, un WON'T ou un DON'T reçu alors que la connexion fonctionne en mode binaire cause le retour de la méthode de codage à l’ASCII NVT.
Il faut se souvenir qu’une connexion TELNET est un canal de communication bidirectionnel. Le mode de transmission binaire doit être négocié séparément pour chaque direction de flux de données, si c’est cela qui est souhaité.
Les mises en oeuvre de l’option de transmission binaire, comme c’est le cas avec les mises en oeuvre de toutes les autres options TELNET, doivent suivre les règles de prévention des boucles données dans la section Considérations générales de la spécification du protocole TELNET.
Considérons maintenant quelques problèmes de la transmission binaire à la fois de et vers un processeur et un terminal :
a. Transmission binaire à partir d’un terminal.
Celui qui met en œuvre l’option de transmission binaire devrait examiner comment (ou si) un terminal qui transmet sur une connexion TELNET avec la transmission binaire activée est autorisé à générer des caractères entièrement en huit bits, ignorant les considérations de parité, etc., sur les entrées provenant du terminal.
b. Transmissions binaires vers un processeur.
Celui qui met en œuvre l’option de transmission binaire devrait examiner comment (ou si) tous les caractères sont passés à un processeur qui reçoit sur une connexion avec la transmission binaire activée. Comme exemple de problème possible, TOPS-20 intercepte certains caractères (comme ETX, le contrôle C terminal) au niveau de surveillance et ne les passe pas au processeur.
c. Transmission binaire à partir d’un processeur.
Celui qui met en œuvre l’option de transmission binaire devrait examiner comment (ou si) un processeur qui transmet sur une connexion avec la transmission binaire activée est autorisé à envoyer des caractères en huit bits intégral sans caractères interceptés par la couche de surveillance et changés en d’autres caractères. Un exemple d’une telle conversion sera trouvé dans le système TOPS-20 où certains caractères non imprimables sont normalement convertis en accent circonflexe (flèche vers le haut) suivi par un caractère imprimable.
d. Transmission binaires vers un terminal.
Celui qui met en œuvre l’option de transmission binaire devrait examiner comment (ou si) tous les caractères reçus sur une connexion avec la transmission binaire activée sont envoyés à un terminal. L’ajout de caractères de temporisation normalement insérés localement, les calculs de parité, et toute la conversion de code normale, peuvent poser problème.