General Considerations (Considerazioni generali)

Una connessione TELNET (TELNET Connection) è una connessione Transmission Control Protocol (TCP, Transmission Control Protocol) utilizzata per trasmettere dati con informazioni di controllo TELNET (Control Information) intervallate.

Il protocollo TELNET (TELNET Protocol) è costruito su tre idee principali: primo, il concetto di "Terminale Virtuale di Rete" (Network Virtual Terminal); secondo, il principio delle opzioni negoziate (Negotiated Options); e terzo, una visione simmetrica dei terminali e dei processi (Symmetric View).

Quando una connessione TELNET viene stabilita per la prima volta, si presume che ogni estremità origini e termini a un "Terminale Virtuale di Rete" (Network Virtual Terminal, NVT). Un NVT è un dispositivo immaginario (Imaginary Device) che fornisce una rappresentazione intermedia (Intermediate Representation) standard, a livello di rete, di un terminale canonico (Canonical Terminal). Questo elimina la necessità per gli host "server" (Server) e "utente" (User) di mantenere informazioni sulle caratteristiche dei terminali reciproci e sulle convenzioni di gestione dei terminali. Tutti gli host, sia utenti che server, mappano le caratteristiche e le convenzioni dei dispositivi locali in modo da sembrare di avere a che fare con un NVT sulla rete, e ciascuno può assumere una mappatura simile da parte dell'altra parte. L'NVT è destinato a trovare un equilibrio tra essere eccessivamente restrittivo (non fornire agli host un vocabolario sufficientemente ricco per la mappatura nei loro set di caratteri locali) ed essere eccessivamente inclusivo (penalizzare gli utenti con terminali modesti).

NOTA: L'host "utente" è l'host a cui il terminale fisico è normalmente collegato, e l'host "server" è l'host che normalmente fornisce un servizio. Come punto di vista alternativo, applicabile anche nelle comunicazioni terminale-terminale o processo-processo, l'host "utente" è l'host che ha avviato la comunicazione.
Il principio delle opzioni negoziate riconosce il fatto che molti host vorranno fornire servizi aggiuntivi oltre a quelli disponibili all'interno di un NVT, e molti utenti avranno terminali sofisticati e vorrebbero avere servizi eleganti, piuttosto che minimi. Indipendenti da, ma strutturate all'interno del protocollo TELNET, ci sono varie "opzioni" (Options) che saranno sanzionate e possono essere utilizzate con la struttura "DO, DON'T, WILL, WON'T" (discussa di seguito) per consentire a un utente e un server di concordare l'uso di un insieme più elaborato (o forse semplicemente diverso) di convenzioni per la loro connessione TELNET. Tali opzioni potrebbero includere la modifica del set di caratteri (Character Set), della modalità echo (Echo Mode), ecc.

La strategia di base per impostare l'uso delle opzioni è che una parte (o entrambe) avvii una richiesta affinché un'opzione abbia effetto. L'altra parte può quindi accettare o rifiutare la richiesta. Se la richiesta è accettata, l'opzione ha immediatamente effetto; se è rifiutata, l'aspetto associato della connessione rimane come specificato per un NVT. Chiaramente, una parte può sempre rifiutare una richiesta di abilitazione e non deve mai (must never) rifiutare una richiesta di disabilitazione di un'opzione poiché tutte le parti devono essere preparate a supportare l'NVT.

La sintassi della negoziazione delle opzioni è stata configurata in modo che se entrambe le parti richiedono un'opzione simultaneamente, ciascuna vedrà la richiesta dell'altra come l'acknowledgement positivo della propria.
La simmetria della sintassi di negoziazione può potenzialmente portare a cicli di acknowledgement non terminanti (Nonterminating Acknowledgment Loops) -- ciascuna parte vede i comandi in arrivo non come acknowledgement ma come nuove richieste che devono essere confermate. Per prevenire tali cicli, prevalgono le seguenti regole:

a. Le parti possono richiedere solo una modifica dello stato dell'opzione; cioè, una parte non può (may not) inviare una "richiesta" semplicemente per annunciare in quale modalità si trova.

b. Se una parte riceve quello che sembra essere una richiesta di entrare in una modalità in cui si trova già, la richiesta non dovrebbe (should not) essere confermata. Questa non-risposta è essenziale per prevenire cicli infiniti nella negoziazione. È richiesto (required) che venga inviata una risposta alle richieste di cambio di modalità -- anche se la modalità non viene cambiata.

c. Ogni volta che una parte invia un comando di opzione a una seconda parte, sia come richiesta che come acknowledgement, e l'uso dell'opzione avrà qualche effetto sull'elaborazione dei dati inviati dalla prima parte alla seconda, allora il comando deve (must) essere inserito nel flusso di dati nel punto in cui si desidera che abbia effetto. (Va notato che trascorrerà del tempo tra la trasmissione di una richiesta e la ricezione di un acknowledgement, che può essere negativo. Pertanto, un host può desiderare di bufferizzare i dati, dopo aver richiesto un'opzione, fino a quando non apprende se la richiesta è accettata o rifiutata, al fine di nascondere il "periodo di incertezza" (Uncertainty Period) all'utente.)

Le richieste di opzioni probabilmente andranno avanti e indietro quando una connessione TELNET viene stabilita per la prima volta, poiché ciascuna parte tenta di ottenere il miglior servizio possibile dall'altra parte. Oltre a ciò, tuttavia, le opzioni possono essere utilizzate per modificare dinamicamente le caratteristiche della connessione per adattarsi alle mutevoli condizioni locali. Ad esempio, l'NVT, come verrà spiegato in seguito, utilizza una disciplina di trasmissione ben adatta alle molte applicazioni "riga alla volta" (Line at a Time) come BASIC, ma poco adatta alle molte applicazioni "carattere alla volta" (Character at a Time) come NLS. Un server potrebbe scegliere di dedicare l'overhead del processore extra richiesto per una disciplina "carattere alla volta" quando è adatta per il processo locale e negozierebbe un'opzione appropriata. Tuttavia, piuttosto che essere poi permanentemente gravato dall'overhead di elaborazione extra, potrebbe passare (cioè, negoziare) di nuovo a NVT quando il controllo dettagliato non è più necessario.

È possibile che le richieste avviate dai processi stimolino un ciclo di richieste non terminante se il processo risponde a un rifiuto semplicemente richiedendo nuovamente l'opzione. Per prevenire il verificarsi di tali cicli, le richieste rifiutate non dovrebbero (should not) essere ripetute fino a quando qualcosa cambia. Operativamente, ciò può significare che il processo sta eseguendo un programma diverso, o l'utente ha dato un altro comando, o qualsiasi cosa abbia senso nel contesto del processo dato e dell'opzione data. Una buona regola pratica è che una nuova richiesta dovrebbe verificarsi solo come risultato di informazioni successive dall'altra estremità della connessione o quando richiesto da un intervento umano locale.

I progettisti di opzioni non dovrebbero sentirsi vincolati dalla sintassi alquanto limitata disponibile per la negoziazione delle opzioni. L'intento della sintassi semplice è rendere facile avere opzioni -- poiché è corrispondentemente facile professare ignoranza su di esse. Se un'opzione particolare richiede una struttura di negoziazione più ricca di quella possibile all'interno di "DO, DON'T, WILL, WON'T", l'approccio corretto è utilizzare "DO, DON'T, WILL, WON'T" per stabilire che entrambe le parti comprendono l'opzione, e una volta raggiunto questo obiettivo, una sintassi più esotica può essere utilizzata liberamente. Ad esempio, una parte potrebbe inviare una richiesta per alterare (stabilire) la lunghezza della riga (Line Length). Se è accettata, allora può essere utilizzata una sintassi diversa per negoziare effettivamente la lunghezza della riga -- una tale "sotto-negoziazione" (Sub-Negotiation) potrebbe includere campi per le lunghezze di riga minime consentite, massime consentite e desiderate. Il concetto importante è che tali negoziazioni espanse non dovrebbero mai iniziare fino a quando una negoziazione precedente (standard) ha stabilito che entrambe le parti sono in grado di analizzare la sintassi espansa.

In sintesi, WILL XXX viene inviato, da una delle due parti, per indicare il desiderio (offerta, Offer) di quella parte di iniziare a eseguire l'opzione XXX, con DO XXX e DON'T XXX come suoi acknowledgement positivi e negativi; similmente, DO XXX viene inviato per indicare un desiderio (richiesta, Request) che l'altra parte (cioè, il destinatario del DO) inizi a eseguire l'opzione XXX, con WILL XXX e WON'T XXX come acknowledgement positivi e negativi. Poiché l'NVT è ciò che rimane quando nessuna opzione è abilitata, le risposte DON'T e WON'T garantiscono di lasciare la connessione in uno stato che entrambe le estremità possono gestire. Pertanto, tutti gli host possono implementare i loro processi TELNET per essere totalmente inconsapevoli delle opzioni non supportate, restituendo semplicemente un rifiuto a (cioè, rifiutando) qualsiasi richiesta di opzione che non può essere compresa.

Per quanto possibile, il protocollo TELNET è stato reso simmetrico server-utente in modo che copra facilmente e naturalmente i casi utente-utente (collegamento, Linking) e server-server (processi cooperanti, Cooperating Processes). Si spera, ma non è assolutamente richiesto, che le opzioni favoriscano ulteriormente questa intenzione. In ogni caso, è esplicitamente riconosciuto che la simmetria è un principio operativo piuttosto che una regola ferrea.

Un documento correlato, "Specifiche delle opzioni TELNET" (TELNET Option Specifications), dovrebbe (should) essere consultato per informazioni sulla procedura per stabilire nuove opzioni.