3. Remote Login - Protocollo TELNET
3.1 INTRODUZIONE
Telnet è il protocollo applicativo Internet standard per il login remoto. Fornisce le regole di codifica per collegare la tastiera/display di un utente su un sistema client (「utente」) con un interprete di comandi su un sistema server remoto. Un sottoinsieme del protocollo Telnet è incorporato anche in altri protocolli applicativi, ad esempio FTP e SMTP.
Telnet utilizza una singola connessione TCP e il suo flusso dati normale (modalità «Terminale Virtuale di Rete» o «NVT») è ASCII a 7 bit con sequenze di escape per incorporare funzioni di controllo. Telnet consente anche la negoziazione di molti modi e funzioni opzionali.
La specifica Telnet primaria si trova in RFC-854 [TELNET:1], mentre le opzioni sono definite in molti altri RFC; vedere Sezione 7 per i riferimenti.
3.2 PROCEDURA DEL PROTOCOLLO
3.2.1 Negoziazione delle opzioni: RFC-854, pp. 2-3
Ogni implementazione Telnet deve (MUST) includere il meccanismo di negoziazione e sotto-negoziazione delle opzioni [TELNET:2].
Un host deve (MUST) seguire attentamente le regole di RFC-854 per evitare loop di negoziazione delle opzioni. Un host deve (MUST) rifiutare (cioè rispondere WONT/DONT a un DO/WILL) un'opzione non supportata. La negoziazione delle opzioni dovrebbe (SHOULD) continuare a funzionare (anche se tutte le richieste vengono rifiutate) per tutta la durata di una connessione Telnet.
Se tutte le negoziazioni delle opzioni falliscono, un'implementazione Telnet deve (MUST) impostare per default e supportare un NVT.
DISCUSSIONE:
Anche se «terminali» più sofisticati e negoziazioni di opzioni di supporto stanno diventando la norma, tutte le implementazioni devono essere preparate a supportare un NVT per qualsiasi comunicazione utente-server.
3.2.2 Funzione Go-Ahead di Telnet: RFC-854, p. 5, e RFC-858
Su un host che non invia mai il comando Telnet Go Ahead (GA), il server Telnet deve (MUST) tentare di negoziare l'opzione Suppress Go Ahead (cioè inviare «WILL Suppress Go Ahead»). Un Telnet utente o server deve (MUST) sempre accettare la negoziazione dell'opzione Suppress Go Ahead.
Quando sta guidando un terminale full-duplex per il quale GA non ha significato, un'implementazione Telnet utente può (MAY) ignorare i comandi GA.
DISCUSSIONE:
I terminali half-duplex («tastiera bloccata») linea per linea per i quali è stato progettato il meccanismo Go-Ahead sono largamente scomparsi dalla scena. Si è rivelato difficile implementare l'invio del segnale Go-Ahead in molti sistemi operativi, anche alcuni sistemi che supportano terminali half-duplex nativi. La difficoltà è tipicamente che il codice del server Telnet non ha accesso alle informazioni su se il processo utente è bloccato in attesa di input dalla connessione Telnet, cioè non può determinare in modo affidabile quando inviare un comando GA. Pertanto, la maggior parte degli host server Telnet non invia comandi GA.
L'effetto delle regole in questa sezione è di permettere a una delle due estremità di una connessione Telnet di porre il veto all'uso dei comandi GA.
C'è una classe di terminali half-duplex che è ancora commercialmente importante: i «terminali di immissione dati», che interagiscono in modo a schermo intero. Tuttavia, supportare i terminali di immissione dati utilizzando il protocollo Telnet non richiede il segnale Go Ahead; vedere Sezione 3.3.2.
3.2.3 Funzioni di controllo: RFC-854, pp. 7-8
L'elenco dei comandi Telnet è stato esteso per includere EOR (End-of-Record), con codice 239 [TELNET:9].
Sia i Telnet utente che server possono (MAY) supportare le funzioni di controllo EOR, EC, EL e Break, e devono (MUST) supportare AO, AYT, DM, IP, NOP, SB e SE.
Un host deve (MUST) essere in grado di ricevere e ignorare qualsiasi funzione di controllo Telnet che non supporta.
DISCUSSIONE:
Si noti che un server Telnet è richiesto di supportare la funzione Telnet IP (Interrupt Process), anche se l'host server ha un equivalente funzione in-stream (ad esempio Control-C in molti sistemi). La funzione Telnet IP può essere più forte di un comando di interruzione in-stream, a causa dell'effetto fuori banda dei dati urgenti TCP.
La funzione di controllo EOR può essere utilizzata per delimitare il flusso. Un'applicazione importante è il supporto dei terminali di immissione dati (vedere Sezione 3.3.2). C'era preoccupazione che poiché EOR non era stato definito in RFC-854, un host che non era preparato a ignorare correttamente comandi Telnet sconosciuti potrebbe bloccarsi se riceveva un EOR. Per proteggere tali host, l'opzione End-of-Record [TELNET:9] è stata introdotta; tuttavia, un programma Telnet implementato correttamente non richiederà questa protezione.
3.2.4 Segnale "Synch" di Telnet: RFC-854, pp. 8-10
Quando riceve dati TCP «urgenti», un Telnet utente o server deve (MUST) scartare tutti i dati eccetto i comandi Telnet fino a quando non viene raggiunto il DM (e la fine dell'urgente).
Quando invia Telnet IP (Interrupt Process), un Telnet utente dovrebbe (SHOULD) farlo seguire dalla sequenza «Synch» di Telnet, cioè inviare come dati TCP urgenti la sequenza «IAC IP IAC DM». Il puntatore urgente TCP punta all'ottetto DM.
Quando riceve un comando Telnet IP, un server Telnet può (MAY) inviare una sequenza «Synch» di Telnet all'utente, per svuotare il flusso di output. La scelta dovrebbe essere coerente con il modo in cui il sistema operativo server si comporta quando un utente locale interrompe un processo.
Quando riceve un comando Telnet AO, un server Telnet deve (MUST) inviare una sequenza «Synch» di Telnet all'utente, per svuotare il flusso di output.
Un Telnet utente dovrebbe (SHOULD) avere la capacità di svuotare l'output quando invia un Telnet IP; vedere anche Sezione 3.4.5.
DISCUSSIONE:
Ci sono tre modi possibili per un Telnet utente di svuotare il flusso di dati di output del server:
(1) Inviare AO dopo IP.
Questo farà sì che l'host server invii un segnale «svuota-output-bufferizzato» al suo sistema operativo. Tuttavia, l'AO potrebbe non avere effetto localmente, cioè fermare l'output del terminale sul lato Telnet utente, fino a quando il server Telnet non ha ricevuto e processato l'AO e ha inviato indietro un «Synch».
(2) Inviare DO TIMING-MARK [TELNET:7] dopo IP, e scartare tutto l'output localmente fino a quando non viene ricevuto un WILL/WONT TIMING-MARK dal server Telnet.
Poiché il DO TIMING-MARK sarà processato dopo l'IP al server, la risposta dovrebbe essere nel posto giusto nel flusso di dati di output. Tuttavia, il TIMING-MARK non invierà un segnale «svuota output bufferizzato» al sistema operativo del server. Se questo è necessario o meno dipende dal sistema server.
(3) Fare entrambe le cose.
Il metodo migliore non è del tutto chiaro, poiché deve soddisfare un certo numero di host server esistenti che non seguono gli standard Telnet in vari modi. L'approccio più sicuro è probabilmente fornire un'opzione controllabile dall'utente per selezionare (1), (2) o (3).
3.2.5 Stampante e tastiera NVT: RFC-854, p. 11
In modalità NVT, un Telnet non dovrebbe (SHOULD NOT) inviare caratteri con il bit di ordine superiore 1, e non deve (MUST NOT) inviarlo come bit di parità. Le implementazioni che passano il bit di ordine superiore alle applicazioni dovrebbero (SHOULD) negoziare la modalità binaria (vedere Sezione 3.2.6).
DISCUSSIONE:
Gli implementatori dovrebbero essere consapevoli che una lettura rigorosa di RFC-854 consente a un client o server che si aspetta NVT ASCII di ignorare i caratteri con il bit di ordine superiore impostato. In generale, la modalità binaria è prevista per essere utilizzata per la trasmissione di un set di caratteri esteso (oltre 7 bit) con Telnet.
Tuttavia, esistono applicazioni che necessitano realmente di una modalità NVT a 8 bit, attualmente non definita, e tali applicazioni esistenti impostano effettivamente il bit di ordine superiore durante una parte o l'intera durata della connessione Telnet. Si noti che la modalità binaria non coincide con una modalità NVT a 8 bit, poiché la modalità binaria disattiva l'elaborazione di fine riga. Per questo motivo i requisiti sul bit di ordine superiore sono espressi con SHOULD anziché con MUST.
RFC-854 definisce un insieme minimo di proprietà di un «terminale virtuale di rete» o NVT; ciò non intende escludere caratteristiche aggiuntive presenti nei terminali reali. Una connessione Telnet è completamente trasparente a tutti i caratteri ASCII a 7 bit, inclusi caratteri di controllo ASCII arbitrari.
Ad esempio, un terminale potrebbe supportare comandi a schermo intero codificati come sequenze di escape ASCII; un'implementazione Telnet trasmetterebbe tali sequenze come dati non interpretati. Un NVT non deve quindi essere inteso come il tipo di terminale di un dispositivo fortemente limitato.
3.2.6 Struttura dei comandi Telnet: RFC-854, p. 13
Poiché le opzioni possono apparire in qualsiasi punto del flusso di dati, un carattere di escape Telnet (noto come IAC, con il valore 255) da inviare come dati deve (MUST) essere raddoppiato.
3.2.7 Opzione binaria Telnet: RFC-856
Quando l'opzione binaria è stata negoziata con successo, sono consentiti caratteri arbitrari a 8 bit. Tuttavia, il flusso di dati deve (MUST) ancora essere scansionato per i caratteri IAC, tutti i comandi Telnet incorporati devono (MUST) essere obbediti, e i byte di dati uguali a IAC devono (MUST) essere raddoppiati. Nessun'altra elaborazione di caratteri (ad esempio sostituire CR con CR NUL o con CR LF) deve (MUST NOT) essere eseguita. In particolare, non c'è convenzione di fine riga (vedere Sezione 3.3.1) in modalità binaria.
DISCUSSIONE:
L'opzione binaria viene normalmente negoziata in entrambe le direzioni, per portare la connessione Telnet dalla modalità NVT alla «modalità binaria».
La sequenza IAC EOR può essere utilizzata per delimitare blocchi di dati all'interno di un flusso Telnet in modalità binaria.
3.2.8 Opzione Terminal-Type di Telnet: RFC-1091
L'opzione Terminal-Type deve (MUST) utilizzare i nomi dei tipi di terminale ufficialmente definiti nell'RFC dei numeri assegnati [INTRO:5], quando sono disponibili per il particolare terminale. Tuttavia, il ricevitore di un'opzione Terminal-Type deve (MUST) accettare qualsiasi nome.
DISCUSSIONE:
RFC-1091 [TELNET:10] aggiorna una versione precedente dell'opzione Terminal-Type definita in RFC-930. La versione precedente consentiva a un host server in grado di supportare più tipi di terminale di conoscere il tipo del particolare terminale client, assumendo che ogni terminale fisico avesse un tipo intrinseco. Oggi, tuttavia, un «terminale» è spesso in realtà un programma di emulazione di terminale eseguito su un PC, potenzialmente in grado di emulare un'intera gamma di tipi di terminale. Per questo motivo RFC-1091 estende la specifica per consentire una negoziazione più generale del tipo di terminale tra il Telnet utente e il Telnet server.
3.3 PROBLEMI SPECIFICI
3.3.1 Convenzione di fine riga Telnet
Il protocollo Telnet definisce la sequenza CR LF per significare «fine riga». Per l'input del terminale, questo corrisponde a un tasto di completamento comando o «fine riga» premuto su un terminale utente; su un terminale ASCII, questo è il tasto CR, ma può anche essere etichettato «Return» o «Enter».
Quando un server Telnet riceve la sequenza di fine riga Telnet CR LF come input da un terminale remoto, l'effetto deve (MUST) essere lo stesso come se l'utente avesse premuto il tasto «fine riga» su un terminale locale. Su host server che utilizzano ASCII, in particolare, la ricezione della sequenza Telnet CR LF deve causare lo stesso effetto di un utente locale che preme il tasto CR su un terminale locale. Quindi, CR LF e CR NUL devono (MUST) avere lo stesso effetto su un host server ASCII quando ricevuti come input su una connessione Telnet.
Un Telnet utente deve (MUST) essere in grado di inviare una qualsiasi delle forme: CR LF, CR NUL e LF. Un Telnet utente su un host ASCII dovrebbe (SHOULD) avere una modalità controllabile dall'utente per inviare CR LF o CR NUL quando l'utente preme il tasto «fine riga», e CR LF dovrebbe (SHOULD) essere il predefinito.
La sequenza di fine riga Telnet CR LF deve (MUST) essere utilizzata per inviare dati Telnet che non siano da terminale a computer (ad esempio quando un Telnet server invia output, oppure quando il protocollo Telnet è incorporato in un altro protocollo applicativo).
DISCUSSIONE:
Per consentire l'interoperabilità tra client e server Telnet arbitrari, il protocollo Telnet ha definito una rappresentazione standard per il terminatore di riga. Poiché il set di caratteri ASCII non contiene un carattere esplicito di fine riga, sistemi diversi hanno scelto rappresentazioni diverse, ad esempio CR, LF e la sequenza CR LF. Il protocollo Telnet ha scelto la sequenza CR LF come standard per la trasmissione in rete.
Sfortunatamente, la specifica del protocollo Telnet in RFC-854 [TELNET:1] si è rivelata alquanto ambigua riguardo a quale carattere un client debba inviare al server per rappresentare il tasto «fine riga». Il risultato è stato un problema di interoperabilità grave e persistente, aggravato da varie implementazioni errate di Telnet utente e server.
Sebbene il protocollo Telnet si basi su un modello perfettamente simmetrico, in una sessione di login remoto il ruolo dell'utente al terminale differisce da quello dell'host server. Ad esempio, RFC-854 definisce il significato di CR, LF e CR LF come output del server, ma non specifica cosa debba inviare un Telnet utente quando l'utente preme il tasto «fine riga» sul terminale; è proprio questo il punto controverso.
Quando l'utente preme il tasto «fine riga», alcune implementazioni di Telnet utente inviano CR LF, mentre altre inviano CR NUL (sulla base di una lettura differente della stessa frase di RFC-854). Come indicato sopra, per un host server ASCII correttamente implementato queste due forme sono equivalenti. Per gli altri server è invece necessaria una modalità nel Telnet utente.
L'esistenza di Telnet utente che inviano solo CR NUL quando viene premuto CR crea un dilemma per gli host non ASCII: o trattano CR NUL in ingresso come equivalente a CR LF, precludendo così la possibilità di immettere un CR «nudo», oppure perdono completamente l'interoperabilità.
Si supponga che un utente sull'host A effettui il login via Telnet sull'host server B e quindi esegua il programma Telnet utente di B per collegarsi all'host server C. Idealmente, la combinazione server/utente Telnet su B dovrebbe essere il più trasparente possibile, ovvero comportarsi come se A fosse collegato direttamente a C. In particolare, un'implementazione corretta renderebbe B trasparente alle sequenze di fine riga Telnet, con l'eccezione che CR LF potrebbe essere convertito in CR NUL e viceversa.
IMPLEMENTAZIONE:
Per comprendere il problema della fine riga in Telnet è necessario disporre almeno di un modello generale della relazione tra Telnet e il sistema operativo locale. Il processo Telnet server è tipicamente accoppiato al software del driver di terminale del sistema operativo come pseudo-terminale. Una sequenza di fine riga Telnet ricevuta dal Telnet server deve produrre lo stesso effetto della pressione del tasto di fine riga su un terminale realmente collegato in locale.
I sistemi operativi che supportano applicazioni interattive carattere per carattere (ad esempio gli editor) forniscono in genere due modalità interne per l'I/O di terminale: una modalità formattata, in cui le convenzioni locali per la fine riga e altre regole di formattazione sono state applicate al flusso di dati, e una modalità «raw», in cui l'applicazione ha accesso diretto a ogni carattere immesso. Un Telnet server deve essere implementato in modo che tali modalità producano per il terminale remoto lo stesso effetto che avrebbero per un terminale locale. Ad esempio, si supponga che un Telnet server su un host ASCII riceva CR LF o CR NUL: in modalità raw il carattere CR viene passato all'applicazione, mentre in modalità formattata viene utilizzata la convenzione di fine riga del sistema locale.
3.3.2 Terminali di immissione dati
DISCUSSIONE:
Oltre ai terminali ASCII orientati alla riga e orientati ai caratteri per i quali è stato progettato Telnet, ci sono diverse famiglie di terminali video che sono talvolta conosciuti come «terminali di immissione dati» o DET. La famiglia IBM 3270 è un esempio ben noto.
Sono stati progettati due protocolli Internet per supportare DET generici: SUPDUP [TELNET:16, TELNET:17] e l'opzione DET [TELNET:18, TELNET:19]. L'opzione DET utilizza la (sotto)negoziazione per pilotare un terminale di immissione dati su una connessione Telnet. SUPDUP è un protocollo di terminale completamente separato, al quale si può passare da Telnet mediante negoziazione. Sebbene sia SUPDUP sia l'opzione DET siano stati utilizzati con successo in ambienti particolari, nessuno dei due ha ottenuto accettazione generale né ampia implementazione.
Per il supporto della famiglia IBM 3270 tramite Telnet si è sviluppato un approccio diverso all'interazione con i DET, benché lo stesso metodo sia applicabile a qualunque DET. L'idea consiste nell'entrare in una modalità «DET nativo», in cui il flusso di input/output nativo del DET viene inviato come dati binari. Il comando Telnet EOR è utilizzato per delimitare i record logici (ad esempio le «schermate») all'interno di questo flusso binario.
IMPLEMENTAZIONE:
Le regole per entrare e uscire dalla modalità DET nativa sono le seguenti:
o Il server apprende tramite l'opzione Terminal-Type [TELNET:10] che il client è un DET.
o Per convenzione (ma non obbligatoriamente), entrambe le estremità negoziano l'opzione EOR [TELNET:9].
o Entrambe le estremità negoziano l'opzione binaria [TELNET:3] per entrare in modalità DET nativa.
o Quando una delle due estremità negozia l'uscita dalla modalità binaria, anche l'altra la segue e la modalità torna al normale NVT.
3.3.3 Requisiti delle opzioni
Ogni implementazione Telnet deve (MUST) supportare l'opzione binaria [TELNET:3] e l'opzione Suppress Go Ahead [TELNET:5], e dovrebbe (SHOULD) supportare le opzioni Echo [TELNET:4], Status [TELNET:6], End-of-Record [TELNET:9] e Extended Options List [TELNET:8].
Un Telnet utente o server dovrebbe (SHOULD) supportare l'opzione Window Size [TELNET:12] se il sistema operativo locale fornisce la capacità corrispondente.
DISCUSSIONE:
Si noti che l'opzione End-of-Record indica soltanto che un Telnet è in grado di ricevere un Telnet EOR senza andare in crash; pertanto ogni Telnet dovrebbe essere disposto ad accettare la negoziazione dell'opzione End-of-Record. Vedere anche la discussione nella Sezione 3.2.3.
3.3.4 Iniziazione delle opzioni
Quando il protocollo Telnet viene utilizzato in una situazione client/server, il server dovrebbe (SHOULD) iniziare la negoziazione della modalità di interazione del terminale che si aspetta.
DISCUSSIONE:
Il protocollo Telnet è definito in modo perfettamente simmetrico, ma la sua applicazione è di norma asimmetrica. Sono noti casi di login remoti falliti perché nessuna delle due parti aveva avviato la negoziazione della modalità di terminale non predefinita richiesta. In generale è il server a determinare la modalità preferita, quindi è il server a dover iniziare la negoziazione; poiché la negoziazione è simmetrica, può iniziarla anche l'utente.
Il client (Telnet utente) dovrebbe (SHOULD) fornire all'utente un modo per abilitare e disabilitare l'avvio della negoziazione delle opzioni.
DISCUSSIONE:
Talvolta un utente ha necessità di collegarsi a un servizio applicativo (ad esempio FTP o SMTP) che utilizza Telnet per il proprio flusso di controllo ma non supporta le opzioni Telnet. Se l'avvio della negoziazione delle opzioni può essere disabilitato, il Telnet utente può essere impiegato per questo scopo.
3.3.5 Opzione Linemode di Telnet
DISCUSSIONE:
Un'importante nuova opzione Telnet, LINEMODE [TELNET:12], è stata proposta. L'opzione LINEMODE fornisce un metodo standard per un Telnet utente e un server Telnet per concordare che il client piuttosto che il server eseguirà l'elaborazione dei caratteri del terminale. Quando il client ha composto un'intera riga di testo, la invia al server (normalmente) in un singolo segmento TCP. Questa opzione ridurrà notevolmente l'overhead di pacchetti delle sessioni Telnet e offrirà all'utente una reattività molto migliore su reti congestionate o con lunghi ritardi.
L'opzione LINEMODE consente di commutare dinamicamente tra elaborazione locale e remota dei caratteri. Ad esempio, durante l'esecuzione di un editor a schermo intero la connessione Telnet negozierà automaticamente il passaggio alla modalità carattere per carattere, per poi tornare al linemode al termine dell'editor.
Ci si attende che, al momento della pubblicazione del presente RFC, gli host implementino il lato client di questa opzione e possano implementarne il lato server. Per implementare correttamente il lato server, il server deve poter indicare al sistema locale di non effettuare alcuna elaborazione dei caratteri in ingresso, memorizzando invece lo stato corrente del terminale e notificando il processo Telnet server quando tale stato cambia. Ciò consentirà, ad esempio, di gestire correttamente l'eco delle password e gli editor a schermo intero.
3.4 INTERFACCIA TELNET/UTENTE
3.4.1 Trasparenza del set di caratteri
Le implementazioni Telnet utente dovrebbero (SHOULD) essere in grado di inviare o ricevere qualsiasi carattere ASCII a 7 bit. Dove possibile, qualsiasi interpretazione di caratteri speciali da parte del sistema operativo dell'host utente dovrebbe (SHOULD) essere bypassata in modo che questi caratteri possano essere comodamente inviati e ricevuti sulla connessione.
Un certo valore di carattere deve (MUST) essere riservato come «escape alla modalità comando»; convenzionalmente, raddoppiare questo carattere consente di inserirlo come dati. Il carattere specifico utilizzato dovrebbe (SHOULD) essere selezionabile dall'utente.
Su una connessione in modalità binaria, un programma Telnet utente può (MAY) fornire un meccanismo di escape per immettere valori arbitrari a 8 bit, qualora il sistema operativo dell'host non ne consenta l'inserimento diretto da tastiera.
IMPLEMENTAZIONE:
La questione della trasparenza è meno pressante sul server, ma gli implementatori dovrebbero prestare attenzione alla gestione di aspetti quali: il mascheramento del bit di parità (inviato da client più datati e non conformi) prima che i dati raggiungano un programma che si aspetta solo NVT ASCII, e la corretta gestione dei programmi che richiedono un flusso di dati a 8 bit.
3.4.2 Comandi Telnet
Un programma Telnet utente deve (MUST) fornire all'utente la capacità di inserire una qualsiasi delle funzioni di controllo Telnet IP, AO o AYT, e dovrebbe (SHOULD) fornire la capacità di inserire EC, EL e Break.
3.4.3 Errori di connessione TCP
Un programma Telnet utente dovrebbe (SHOULD) segnalare all'utente qualsiasi errore TCP segnalato dal livello di trasporto (vedere la sezione «Interfaccia livello TCP/applicazione» in [INTRO:1]).
3.4.4 Porta di contatto Telnet non predefinita
Un programma Telnet utente dovrebbe (SHOULD) consentire all'utente di specificare opzionalmente un numero di porta di contatto non standard sull'host server Telnet.
3.4.5 Svuotamento dell'output
Un programma Telnet utente dovrebbe (SHOULD) fornire all'utente la capacità di specificare se l'output deve essere svuotato o meno quando viene inviato un IP; vedere Sezione 3.2.4.
Per qualsiasi schema di svuotamento dell'output che porti il Telnet utente a scartare localmente l'output fino alla ricezione di un segnale Telnet dal server, dovrebbe (SHOULD) essere fornito all'utente un modo per ripristinare manualmente l'output normale, nel caso in cui il server non invii il segnale atteso.
3.5 RIEPILOGO DEI REQUISITI TELNET
| Funzionalità | Sezione | MUST | SHOULD | MAY | SHOULD NOT | MUST NOT |
|---|---|---|---|---|---|---|
| Negoziazione delle opzioni | ||||||
| Implementare negoziazione opzioni | 3.2.1 | ✓ | ||||
| Evitare loop di negoziazione | 3.2.1 | ✓ | ||||
| Rifiutare opzioni non supportate | 3.2.1 | ✓ | ||||
| Negoziazione OK in qualsiasi momento | 3.2.1 | ✓ | ||||
| Predefinito su NVT | 3.2.1 | ✓ | ||||
| Inviare nome ufficiale in Term-Type | 3.2.8 | ✓ | ||||
| Accettare qualsiasi nome in Term-Type | 3.2.8 | ✓ | ||||
| Implementare Binary, Suppress-GA | 3.3.3 | ✓ | ||||
| Opzioni Echo, Status, EOL, Ext-Opt-List | 3.3.3 | ✓ | ||||
| Opzione Window-Size se appropriato | 3.3.3 | ✓ | ||||
| Server inizia negoziazioni di modalità | 3.3.4 | ✓ | ||||
| Funzioni di controllo | ||||||
| Supportare SE NOP DM IP AO AYT SB | 3.2.3 | ✓ | ||||
| Supportare EOR EC EL Break | 3.2.3 | ✓ | ||||
| Ignorare funzioni non supportate | 3.2.3 | ✓ | ||||
| Scartare dati urgenti fino a DM | 3.2.4 | ✓ | ||||
| Codifica | ||||||
| Non inviare bit alto in NVT | 3.2.5 | ✓ | ||||
| Non inviare bit alto come parità | 3.2.5 | ✓ | ||||
| Raddoppiare sempre byte IAC | 3.2.6 | ✓ | ||||
| Raddoppiare IAC in modalità binaria | 3.2.7 | ✓ | ||||
| Fine riga | ||||||
| EOL al server = fine riga locale | 3.3.1 | ✓ | ||||
| Server ASCII accetta CR LF o CR NUL | 3.3.1 | ✓ | ||||
| Utente può inviare CR LF, CR NUL, LF | 3.3.1 | ✓ | ||||
| Utente ASCII può selezionare CR LF/CR NUL | 3.3.1 | ✓ | ||||
| Modalità predefinita utente è CR LF | 3.3.1 | ✓ | ||||
| Interfaccia utente Telnet | ||||||
| I/O di tutti i caratteri a 7 bit | 3.4.1 | ✓ | ||||
| Bypassare interpretazione OS locale | 3.4.1 | ✓ | ||||
| Carattere di escape | 3.4.1 | ✓ | ||||
| Carattere di escape impostabile dall'utente | 3.4.1 | ✓ | ||||
| Può inserire IP, AO, AYT | 3.4.2 | ✓ | ||||
| Può inserire EC, EL, Break | 3.4.2 | ✓ | ||||
| Segnalare errori TCP all'utente | 3.4.3 | ✓ | ||||
| Porta di contatto non predefinita | 3.4.4 | ✓ | ||||
| Specificare svuotamento output all'invio IP | 3.4.5 | ✓ | ||||
| Ripristinare manualmente modalità output | 3.4.5 | ✓ |