Spécifications des options TELNET

La présente RFC spécifie une norme pour la communauté ARPA Internet. Les hôtes de l’ARPA Internet sont invités à adopter et mettre en œuvre la présente norme.

Les raisons de la fourniture d’options dans le protocole TELNET sont de permettre aux hôtes d’obtenir des solutions aussi élégantes que possible aux problèmes de communication entre des appareils dissemblables au sein du cadre de travail fourni par le terminal réseau virtuel (NVT, Network Virtual Terminal). Il devrait être possible aux hôtes d’inventer, tester, ou supprimer des options à volonté. Néanmoins, il est envisagé que les options qui se révèle être généralement utiles soient finalement prises en charge par de nombreux hôtes ; il est donc souhaitable que les options soient soigneusement documentées et bien publiées. De plus, il est nécessaire de s’assurer qu’un seul code d’option n’est pas utilisés pour plusieurs options différentes.

Le présent document spécifie une méthode d’allocation et de normalisation des codes d’option pour la documentation des options. L’individu responsable de l’allocation des codes d’option peut renoncer à exiger une documentation complète dans certains cas d’expérimentation, mais en général, la documentation sera exigée avant l’allocation du code. Les options seront publiées au moyen de l’édition de leur documentation sous forme de RFC ; les inventeurs d’options peuvent, bien sûr, les publier aussi par d’autres moyens.

Les codes d’option seront alloués par :

Jonathan B. Postel
University of Southern California
Information Sciences Institute (USC-ISI)
4676 Admiralty Way
Marina Del Rey, California 90291
(213) 822-1511
Mailbox = POSTEL@USC-ISIF

La documentation des options devrait contenir au moins les sections suivantes :

Section 1 – Nom de commande et code d’option

Section 2 – Signification de la commande

La signification de chaque commande TELNET possible relative à cette option devrait être décrite. Noter que pour des options complexes, où des "sous-négociations" sont nécessaires, il peut y avoir un grand nombre de commandes possibles. Le concept de "sous-négociation" est décrit plus en détail ci-dessous.

Section 3 – Spécification de la valeur par défaut

Les hypothèses de valeur par défaut pour les hôtes qui ne mettent pas en œuvre, ou n’utilisent pas, l’option doivent être décrites.

Section 4 - Motifs

Une explication détaillée des motifs de l’invention d’une option particulière, ou du choix d’une forme particulière de l’option, est extrêmement utile pour ceux qui n’ont pas été confrontés (ou n’ont pas encore réalisé qu’ils sont confrontés) au problème que l’option est conçue pour résoudre.

Section 5 - Description (ou règles de mise en œuvre)

Simplement définir la signification d’une commande et fournir une déclaration des motivations n’est pas toujours suffisant pour garantir que deux mises en œuvre d’une option seront capables de communiquer. Donc une description plus complète devrait être fournie dans la plupart des cas. Cette description peut prendre la forme d’un texte, d’un exemple de mise en œuvre, de conseils pour les développeurs, etc.

Note sur la notion de "sous-négociation"

Certaines options exigeront que soient passées plus d’informations entre les hôtes qu’un simple code d’option. Par exemple, toute option qui exige un paramètre est dans ce cas. La stratégie à utiliser comporte deux étapes : d’abord, les deux parties se mettent d’accord pour "discuter" le ou les paramètres, et ensuite, a lieu la "discussion".

La première étape, d’accord pour discuter les paramètres, se tient de façon normale ; une partie propose l’utilisation de l’option par l’envoi d’un DO (ou WILL) suivi du code de l’option, et l’autre partie accepte en retournant un WILL (ou DO) suivi du code de l’option. Une fois que les deux parties se sont mises d’accord pour utiliser l’option, la sous-négociation a lieu en utilisant la commande SB, suivie du code de l’option, suivi du ou des paramètres, suivi par la commande SE. Chaque partie est supposée être capable d’analyser le ou les paramètres, car chacune a indiqué qu’elle prend l’option en charge (via l’échange initial de WILL et DO). D’un autre côté, le receveur peut localiser la fin d’une chaîne de paramètre en cherchant la commande SE (c’est-à-dire, la chaîne IAC SE), même si le receveur est incapable d’analyser les paramètres. Bien sûr, chaque partie peut refuser de poursuivre la sous-négociation à tout moment en envoyant un WON'T ou DON'T à l’autre partie.

Et donc, pour l’option "ABC", qui requiert une sous-négociation, les formats des commandes TELNET sont :

IAC WILL ABC
Offre d’utiliser l’option ABC (ou accusé de réception favorable de la demande de l’autre partie).

IAC DO ABC
Demande à l’autre partie d’utiliser l’option ABC (ou accusé de réception favorable de l’offre de l’autre partie)

IAC SB ABC <paramètres> IAC SE
Une étape de sous-négociation, utilisée par l’une ou l’autre partie.

Les concepteurs d’options qui ont besoin de "sous-négociation" doivent veiller avec grand soin à éviter les boucles involontaires dans le processus de sous-négociation. Par exemple, si chaque partie peut accepter toute valeur d’un paramètre, et si les deux parties suggèrent des paramètres avec des valeurs différentes, il est alors vraisemblable que l’une d’elles va avoir une oscillation infinie "d’accusés de réception" (où chaque receveur croit qu’il accuse simplement réception de la nouvelle proposition de l’autre).

Finalement, si les paramètres d’une option "sous-négociation" comportent un octet avec une valeur de 255, il est nécessaire de doubler cet octet conformément aux règles générales de TELNET.