Network Working Group J. Postel Request for Comments: 854 J. Reynolds ISI Obsoletes: NIC 18639 May 1983 SPECIFICHE DEL PROTOCOLLO TELNET Distribuita da .::http://www.rfc.altervista.org::. Questo RFC specifica uno standard per la comunità ARPA Internet. Gli Host appartenenti ad ARPA Internet sono invitati a adottare ed implementare questo standard. INTRODUZIONE Lo scopo del protocollo TELNET è offrire un'agevolazione generica per le comunicazioni, bi-direzionale e orientata ai byte di otto bit. Il suo obiettivo principale è consentire un metodo standard di congiunzione tra dispositivi terminali e processi orientati a terminali l'uno con l'altro. E' previsto che il protocollo possa anche essere usato per comunicazioni terminale-terminale ("linking") e processo-processo (computazione distribuita). CONSIDERAZIONI GENERALI Una connessione TELNET è una connessione Transmission Control Protocol (TCP) usata per trasmettere dati con il compendio dell'informazione di controllo propria di TELNET. Il Protocollo TELNET è costruito su tre idee fondamentali: prima, il concetto di un "Network Virtual Terminal"; secondo, il principio delle opzioni negoziate; e terzo, organizzazione simmetrica di processi e terminali. 1. Quando viene stabilita una connessione TELNET, ogni parte coinvolta agisce come origine e conclusione di un Network Virtual Terminal o NVT. NVT è un dispositivo immaginario che consente una rappresentazione standard, network-wide e intermedia di un terminale canonico. Questo elimina il bisogno per gli host sia "server" sia "user" di conservare informazioni sulle caratteristiche dei terminali di ognuno e le specifiche convenzioni di impiego. Tutti gli host, sia utente, sia server, assumono un mappaggio per le varie caratteristiche e convenzioni tali da far sembrare che si stia trattando con uno stesso NVT lungo il network, dato che ognuno può assumere un sistema di mappaggio simile a quello della controparte. NVT è studiato con il giusto equilibrio tra l'essere eccessivamente limitanti (non munendo gli host di un vocabolario abbastanza ricco per mappare il set dei rispettivi caratteri locali), e l'essere eccessivamente inclusivi (cosa che penalizzerebbe gli utenti muniti di terminali di caratteristiche modeste). NOTA: Per host "user" (utente) si intende quello al quale il terminale fisico è normalmente collegato, l'host "server" è quello che di solito offre un certo servizio. Volendo inquadrare la cosa da un altro punto di vista, applicabile anche in tipi di comuncazione terminale a terminale o processo a processo, si può vedere l'host user come quello che ha iniziato la sessione di comunicazione. Postel & Reynolds [Page 1] RFC 854 May 1983 2. Il principio di negoziazione delle opzioni prende atto del fatto che molti host desiderano offrire nel tempo servizi addizionali che vanno sotto o oltre quelli disponibili tramite un NVT, e molti utenti potrebbero avere terminali sofisticati e desiderare quindi dei servizi elegani piuttosto che minimali. Le varie "opzioni" indipendenti da TELNET, ma strutturate nell'ambito del protocollo, che verranno sancite possono essere esplicate ricorrendo alla formula "DO, DON'T, WILL, WON'T" (discussa successivamente), così da consentire ad un utente ed un server di convenire nell'uso di un set di convenzioni più elaborato (oppure differente) per la loro connessione TELNET. Tra queste opzioni possiamo includere il cambiamento dell'insieme di caratteri, la modalità echo, ecc. La strategia di base per settare l'uso di opzioni è avviare una richiesta da una delle parti (o da ognuna) per verificare che qualche opzione possa avere effetto. L'altra parte, dopo, potrebbe accettare o rifiutare la richiesta. Se la richiesta viene accettata, l'opzione deve avere luogo immediatamente; se viene rifiutata, l'aspetto associato alla connessione rimane quello solito di un NVT. Tuttavia, una parte potrebbe comunque rifiutare una richiesta relativa ad un'abilitazione, ma non deve mai rifiutare una richiesta volta a disabilitare qualche opzione poiché tutte le parti devono essere preparate per supportare NVT. La sintassi di negoziazione delle opzioni è stata impostata in modo che, se entrambe le parti richiedono una opzione simultaneamente, ognuna vede la richiesta dell'altro come conferma positiva della propria. 3. La simmetria della sintassi di negoziazione può potenzialmente concludersi in loop di conferma infiniti -- ogni parte vede i comandi in arrivo non come conferme ma come nuove richieste che devono essere approvate. Per prevenire questi loops, vanno seguite le seguenti regole: a. Le parti idalmente possono solo richiedere una variazione nello stato di opzioni; nel senso che una parte non potrebbe inoltrare una "richiesta" solo per annuncarie in quale modalità si trova. b. Se una parte riceve ciò che appare essere una richiesta per entrare in qualche modalità già attiva, la richiesta di norma non andrebbe essere accettata. Questa non risposta è essenziale per prevenire loop infiniti nella negoziazione. E' necessario che una risposta sia spedita per richiedere un cambiamento di modalità -- anche se la modalità non viene cambiata. c. Ogni volta che una parte inoltra un comando di opzione ad una seconda parte, sia come richiesta o riconoscimento, e l'uso della opzione ha un qualsiasi effetto nel trattamento dei dati che vengono spediti dalla prima parte alla seconda, allora il comando deve essere inserito nello stream di di dati al punto dove si desidera che abbia effetto. Postel & Reynolds [Page 2] RFC 854 May 1983 Andrebbe considerato che trascorrerà un po' di tempo tra la trasmissione di una richiesta e la ricezione di una conferma, la quale potrebbe comunque essere negativa. Per ovviare, l'host potrebbe bufferizzare i dati dopo avere richiesto una determinata opzione fino a quando non viene a conoscenza che quest'ultima sia stata accettata o respinta, in questo modo è possibile trattare adeguatamente i dati confluiti durante il periodo di incertezza. Quando viene stabilita una connessione TELNET, in una fase iniziale, ogni parte invia continuamente richieste di opzione perché desidera ottenere il miglior servizio possibile dalla controparte. L'impiego di richieste di opzione, tuttavia, non è ristretto a questo ambito, è utilizzato anche per modificare in modo dinamico le caratteristiche della connessione per soddisfare i cambiamenti delle condizioni locali. Per esempio, NVT, come sarà spiegato in seguito, adotta una disciplina di trasmissione volta principalmente a coprire opzioni relative alla composizione di linee di testo per volta, come nel BASIC, e scarsamente adatte a soddisfare le esigenze di applicazioni orientate alla digitazione di un carattere per volta, come nel caso di NLS. Un server, se necessario, potrebbe infatti dedicare una procedurra extra di interpetrazione adottando una disciplina "character at time" desiderando dunque di negoziare un'opzione appropriata. Tuttavia, anziché sovraccaricare il flusso con informazioni extra da processare, potrebbe decidere di tornare ad NVT (quindi negoziare) non appena il tipo di controllo dettagliato precedentemente richiesto non risultasse più necessario Nel caso in cui un processo rispondesse ad un eventuale rifiuto reinoltrando la stessa richiesta di opzione si potrebbe venire a creare un ciclo di negoziazione senza fine. Allo scopo di prevenire simili circostanze, le richieste di opzione non dovrebbero essere reinoltrate fino a quando non avviene un cambiamento effettivo. Operazionalmente, è possibile che il processo stia facendo girare un programma differente, o che l'utente abbia dato un altro comando, o qualsiasi altra cosa abbia senso nel contesto del processo e dell'opzione considerati. Una buona regola in pratica è che una richiesta sia reinoltrata solo come conseguenza di una informazione recapitata dalla controparte o quando richiesto da un intervento umano a livello locale. Agli occhi di chi progetta le varie opzioni, la sintassi per la negoziazione delle opzioni non dovrebbe essere considerata limitante. L'intento della sintassi semplice è infatti rendere facile la possibilità di avere opzioni -- poiché in corrispondenza è facile mostrare ignoranza a proposito di esse. Se qualche particolare opzione richiede una struttura di negoziazione più ricca di quella possibile ricorrendo alla formula "DO, DON'T, WILL, WON'T", il metodo migliore è usare la medesima procedura standard "DO, DON'T, WILL, WON'T" per stabilire un'intesa preliminare tra entrambe le parti, una volta che questo è avvenuto si può ricorrere liberamente anche ad una sintassi più esotica. Per esempio, una parte potrebbe inoltrare una richiesta per modificare (o stabilire) la lungezza di una linea di testo. Se le due parti concordano, successivamente si può anche utilizzare una sintassi differente per la negoziazione effettiva della lunghezza da assegnare alla linea -- volendo ampliare l'esempio, una di queste "sotto-negoziazioni" potrebbe includere i campi riguardanti il minimo consentito, il massimo disponibile e le lunghezze desiderate dalla linea. Il concetto importante è che una negoziazione extra non abbia mai luogo prima che una precedente negoziazione Postel & Reynolds [Page 3] RFC 854 May 1983 standard abbia stabilito che entrambi le parti siano capaci di decifrare la sintassi espansa adottata nel caso. Ricapitolando, il costrutto WILL XXX viene inoltrato da una delle parti per indicare che desidera ricorrere all'opzione XXX. DO XXX e DON'T XXX indicano una risposta positiva o negativa; in modo simile, DO XXX viene inoltrato anche per indicare il desiderio che la controparte inizi ad adottare l'opzione XXX. WILL XXX e WON'T XXX indicano una risposta rispettivamente positiva o negativa. Poiché NVT è ciò che rimane quando nessuna opzione viene abilitata, le risposte DON'T e WON'T garantiscono che la connessione rimanga in uno stato che entrambi le parti possono continuare a gestire. Così, tutti gli host possono implementare i loro processi TELNET pur essendo totalmente inconsapevoli delle opzioni che non sono supportate, semplicemente rispondendo con un rifiuto ad ogni richiesta di opzione che non può essere correttamente computata. Quanto più possibile, il protocollo TELNET è stato struttrato secondo una simmetria server-user in maniera tale che possa facilmente e naturalmente supportare i casi user-user (linking) e server-server (processi in cooperazione). Si spera, ma non è assolutamente richiesto, che le opzioni favoriscano questo intento. In ogni caso, è abbastanza esplicito che questa simmetria sia un principio di operabilità piuttosto che una regola inviolabile. Un documento di informazione, "TELNET Option Specifications", dovrebbe essere consultato per avere informazioni sulla procedura per stabilire nuove opzioni. IL NETWORK VIRTUAL TERMINAL Il Network Virtual Terminal (NVT) è un device di caratteri bidirezionale. NVT ha una stampante e una tastiera. La stampante risponde ai dati in arrivo e la tastiera produce dati in uscita che vengono spediti verso la connessione TELNET e, se gli "echoes" sono desiderati, anche verso la stampante del NVT. Non è obbligatoriamente necessario che gli "Echoes" attraversino la rete (sebbene le opzioni per abilitare una modalità di "remote" echoing esistano, nessun host è obbligato ad implementare tassativamente questa opzione). Il set di codici è 7-bit USASCII in un cambo di 8-bit, salvo eventuali eccezioni che segnaleremo. Ogni considerazione a proposito di conversioni di codice e temporeggiamento sono problemi locali e non riguardano direttamente NVT. TRASMISSIONE DI DATI Sebbene una connessione TELNET attraverso la rete sia intrinsecamente full duplex, NVT va visto come un dispositivo half-duplex operante in una modalità line-buffered. Cioè, a meno che e fino a che non vengano negoziate opzioni contrarie, le seguenti condizioni di default vengono associate alla trasmissione di dati lungo la connessione TELNET: Postel & Reynolds [Page 4] RFC 854 May 1983 1) Fin dove lo spazio del buffer disponibile al sistema locale lo permette, i dati dovrebbero essere accumulati nell'host che li produce fino a che una linea completa di dati non è pronta per essere trasmessa, o fino a che qualche segnale esplicito localmente definito per trasmettere non si presenti. Questo segnale potrebbe essere generato sia da un processo o da un utente umano. La motivazione per questa regola è la dispendiosità, per alcuni host, di processare gli input interrupt di rete, considerato anche l'accorgimento di defalut che gli "echoes" non percorrano la rete. In questo modo è ragionevole bufferizzare l'ammontare di dati alla sua sorgente. Molti sistemi impiegano delle azioni di elaborazione alla fine di ogni input di linea (anche le stampanti di linee di testo o gli incisori di schede frequentemente tendono a funzionare in questo modo), così la trasmissione dovrebbe essere avviata alla fine di una linea. D'altra parte, un utente o processo potrebbe qualche volta trovare necessario o gradevole fornire dati che non terminino alla fine di una linea; di conseguenza gli implementatori sono invitati a prevedere dei metodi di signaling locale in modo che tutti i dati bufferizzati possano essere trasmessi immediatamente. 2) Quando un processo ha completato la spedizione dei dati verso una stampante NVT e non ha accodato alcun input dalla tastiera NVT per ulteriori elaborazioni (cioè, quando un processo da un'estermità di una connessione TELNET non può procedere senza l'input dall'altra estremità), il processo deve trasmettere il comando TELNET Go Ahead (GA). Questa regola non intende richiedere che il comando TELNET GA venga spedito da un terminale alla fine di ogni linea digitata, poichè i server host normalmente non richiedono un segnale speciale (in addizione a quello end-of-line o altri caratteri localmente definiti) al fine di dare via all'elaborazione. Più che altro, il TELNET GA è studiato per aiutare l'host locale di un utente a far funzionare fisicamente un terminale semiduplex che ha una tastiera chiudibile, come il modello IBM 2741. Una descrizione di questo tipo di terminale potrebbe essere di aiuto per un uso opportuno del comando GA. La connessione terminale-computer è sempre sotto il controllo sia dell'utente o del computer. Ne l'uno ne l'altro può impossessarsi unilateralmente del controllo di uno dall'altro; piuttosto la parte che lo possiede deve cedere il proprio controllo esplicitamente. Dalla parte del terminale, l'hardware è costruito in modo che ceda il proprio controllo ogni volta che una "linea" è terminata (cioè quando l'utente richiede una nuova linea). Quando questo accade, il computer collegato (locale) processa i dati di input, decide se è opportuno generare l'output e se non è il caso restituisce il controllo al terminale. Postel & Reynolds [Page 5] RFC 854 May 1983 Se invece l'output va generato, in controllo viene conservato dal computer fino a che l'intero output non è stato trasmesso. Le difficoltà nell'utilizzare questo tipo di terminale nella rete dovrebbero apparire ovvie. Il computer "locale" non è in grado di decidere se conservare il controllo dopo aver captato un segnale di end-of-line oppure no; questa decisione può essere presa solo dal computer "remoto" che sta processando i dati. Il comando GA di TELNET mette quindi a disposizione un meccanismo tramite il quale il computer "remoto" (server) può segnalare al computer "locale" (user) che è arrivato il momento di prendere il controllo. Quanto descritto va applicato nelle circostanze descritte ed una sola volta per caso, qualora dunque andasse restituito all'utente il controllo del terminale. E' bene notare che una trasmissione prematura del comando GA potrebbe comportare un blocco dell'output, poiché l'utente viene portato a credere che il sistema trasmittente sia andato in pausa, e di conseguenza l'utente non riuscirà ad ottenere il controllo manuale della linea. Quanto descritto sopra, come ovvio, non si applica alla direzione di comunicazione user-to-server. In questa direzione, i comandi GA potrebbero anche essere inviati in ogni momento, ma non necessitano di essere inoltrati. Inoltre, se la connessione TELNET viene utilizzata per comunicazioni process-to-process, non è necessario inoltrare i comandi GA in nessuna delle due direzioni, Infine, per comuncazioni terminal-to-terminal, i comandi GA potrebbero essere richiesti per entrambe, una o nessuna delle direzioni. Se un host prevede di supportare la comunicazione terminal-to-terminal è suggerito che questo fornisca l'utente di strumenti per la segnalazione manuale necessaria nel caso in cui è richiesto inviare un comando GA lungo la connessione TELNET; questo, tuttavia, non è un requisito indispensabile per chi implementa un processo TELNET. Nota che la simmetria di un modello TELNET richiede che ci sia un NVT da ogni parte delle connessione TELNET, quantomeno concettualmente. RAPPRESENTAZIONE STANDARD DELLE FUNZIONI DI CONTROLLO Come già accennato nell'Introduzione di questo documento, lo scopo principale del protocollo TELNET è fornire una congiunzione standard tra dispositivi di terminale e processi terminal-oriente nella rete. Le prime esperienze con questo tipo di interconnessione hanno mostrato che certe funzioni vengono implemenetate dalla maggior parte dei server, ma che i metodi di invocare queste funzioni si differiscono ampiamente. Per un utente umano che abitualmente deve interagire con più sistemi di server, la quantità di differenze può mostrarsi altamente frustrante. TELNET, quindi, definisce una rappresentazione standard per cinque di queste funzioni, come descritto successivamente. Postel & Reynolds [Page 6] RFC 854 May 1983 Queste rapparesntazioni standard hanno dei significati canonici, ma non richiesti (fatta eccezione che la funzione Interrupt Process (IP) potrebbe essere richiesta di altri protocolli che usano TELNET); secondo questa dicitura, un sistema che non prevede il supporto di una o più funzioni per gli utenti locali non ha quindi bisogno di offrirne il supporto agli utenti del network e potrebbe decidere di considerarne la rappresentazione standard, qualora si presentasse, come una No-Operation. D'altro canto, un sistema che supporta una funzione per un utente locale è obbligata a mettere a disposizione la stessa funzione per i vari utenti del network che la richiamano ricorrendo alla rappresentazione standard. Interrupt Process (IP) Molti sistemi dispongono di una funzione che sospende, interrompe abortisce, o termina l'operazione di un processo user. Questa funzione è usata frequentemente quando un utente crede che il proprio processo sia caduto in un ciclo infinito, o quando un processo indesiderato è stato involontariamente avviato. IP è la rappresentazione standard per l'invocazione di questa funzione. Gli implementatori dovrebbero notare che IP potrebbe essere importante per altri protocolli che usano TELNET, e di conseguenza dovrebbe essere implementato se è previsto che questi altri protocolli vadano supportati. Abort Output (AO) Diversi sistemi dispongono di una funzione che permette ad un processo, che sta generando un output, di completare un'operazione (o arrivare allo stesso punto di arresto che raggiungerebbe se arrivasse al completamento) ma senza spedire l'output al terminale dell'utente. Inoltre, tipicamente questa funzione cancella ogni output prodotto ma non ancora stampato (o visualizzato) al momento attuale nel terminale dell'utente. AO è la rappresentazione standard per invocare questa funzione. Per esempio, qualche sottosistema potrebbe di norma accettare il comando di un utente, inviare come risposta una lunga stringa di testo al terminale dell'utente, e finalmente segnalare di essere pronto ad accettare il prossimo comando inoltrando un carattere di "prompt" (preceduto da ) al terminale dell'utente. Se l'AO è stato ricevuto durante la trasmissione della stringa di testo, una ragionevole implementazione bloccherebbe la parte rimanente della stringa di testo, trasmettendo comunque il carattere di prompt e il precedente . (Questo va distinto dall'azione che potrebbe avvenire a seguito della ricezione di un comando IP; IP potrebbe causare la soppresisione della stringa di testo e l'uscita dal sottosistema). Andrebbe notato, nei sistemi server che dispongono di questa funzione, che ci possono essere dei buffer esterni (nella rete e nell'host locale dell'utente) che dovrebbero essere puliti; il modo appropriato per fare questo è trasmettere il segnale "Synch" (descritto sotto) al sistema utente. Postel & Reynolds [Page 7] RFC 854 May 1983 Are You There (AYT) Una svariata gamma di sistemi dispone di una funzione che mette a disposizione un tipo di messaggio che evidenzi esplicitamente che il sistema sia attivo e funzionante. Questa funzione potrebbe essere invocata dall'utente quando il sistema appare inaspettatamente "silenzioso" per un lungo periodo, per cause quali la non avvenuta anticipazione (da parte dell'utente) della lunghezza di una computazione, un inusuale stato di eccessivo sovraccarico, etc. AYT è la rappresentazione standard per invocare questa funzione. Erase Character (EC) Molti sistemi mettono a disposizione una funzione che cancella l'ultimo carattere immesso o "print position"* dallo stream di dati che vengono forniti dall'utente. Questa funzione è solitamente usata per modificare l'input della tastiera quando si commette un errore di battitura. EC è la rappresentazione standard per invocare questa funzione *NOTA: Una "print position" può contenere diversi caratteri frutto del risultato di sovrapposizione, o di sequenze del tipo BS ... Erase Line (EL) Molti sistemi dispongono di una funzione che cancella tutti i dati nell'attuale "linea" di input. Questa funzione è tipicamente usata per modificare l'input della tastiera. EL è la rappresentazione standard per invocare questa funzione. IL SEGNALE "SYNCH" DI TELNET Diversi sistemi di time-sharing dispongono di un meccanismo che permette ad un terminale utente di riottenere il controllo di un processo fuori corso. Le funzioni IP ed AO, descritte sopra, sono esempi di questi meccanismi. Questi sistemi, quando usati localmente, hanno accesso a tutti i segnali forniti dall'utente, sia che questi siano caratteri normali o speciali segnali di "out of band" come quello previsti dal tasto "Break" di una telestampatrice o il tasto "ATTN" del modello IBM 2741. Questo non è necessariamente vero quando i terminali sono connessi al sistema tramite la rete; i meccanismi di controllo del flusso di rete possono causare che un segnale venga bufferizzato altrove, per esempio nell'host dell'utente. Postel & Reynolds [Page 8] RFC 854 May 1983 Per rimediare a questo problema, è stato introdotto il meccanismo di telnet "Synch". Un segnale Synch consiste in una notificazione Urgente TCP accoppiata con il comando DATA MARK di TELNET. La notificazione Urgente, che non è soggetta al flusso di controllo riguardante la connessione TELNET, è usata per invocare uno speciale trattamento del flusso di dati da parte del processo che lo riceve. Con questo, il flusso di dati viene immediatamente esaminato ricercando i segnali "di interesse" come descriveremo, scartando i dati in frapposizione. Nello stream di dati, il comando DATA MARK (DM) di TELNET è il marchio di sincronizzazione volto a indicare che ogni segnale speciale si è già presentato e che quindi il ricevente può tornare ad una normale elaborazione del flusso di dati. Synch viene spedito tramite l'operazione TCP di invio settando il flag Urgent e mettendo DM come l'ultimo (o l'unico) ottetto. Quando più Synch vengono inviati in rapida successione, le notificazioni Urgenti potrebbero fondersi. Non è possibile contare gli Urgent poiché il numero di quelli ricevuti può presentarsi minore o uguale al numero di inviati. Quando si è in modalità normale, un DM equivale ad una non operazione; quando si è in modalità urgente, segnala la fine di una processazione urgente. Se TCP mostra la fine di un dato Urgente prima che DM viene rilevato, TELNET dovrebbe continuare il trattamento speciale dello stream di dati fino a quando non si presenta DM. Se, inoltre, TCP indica un dato Urgente dopo che DM si è presentato, ciò si può essere soltanto presentato per via di un susseguente Synch. TELNET dovrebbe continuare il trattamento speciale dello stream di dati fino a quando un ulteriore DM non viene rilevato. I segnali definiti come "Interessanti" dunque sono: la rappresentazione standard di IP, AO, e AYT (ma non EC oppure EL); le analogie locali di queste rappresentazioni standard (se ve ne sono); tutti gli altri comandi di TELNET; altri segnali definiti in sito che possono essere impiegati senza ritardare la scansione del flusso di dati. Poiché un effetto del meccanismo SYNCH è essenzialmente l'eliminazione di tutti i caratteri (eccetto i comandi di TELNET) tra il mittente del Synch ed il destinatario, questo meccanismo viene inteso come la soluzione standard per cancellare il data path ogni volta che lo si desidera. Per esempio, se un utente genera la trasmissione di un AO, il server che riceve l'AO (se comunque dispone della funzione) dovrebbe restituire un Synch all'utente. Infine, così come la notificazione Urgente TCP è necessaria a livello di TELNET come un segnale di out-of-band, così altri protocolli che fanno uso di TELNET potrebbero richiedere un comando TELNET che possa essere inteso come un segnale di out-of-band ad un livello differente. Postel & Reynolds [Page 9] RFC 854 May 1983 Per convenzione, la sequenza [IP, Synch] va usata come un segnale. Ad esempio, si supponga che qualche altro protocollo, che usa TELNET, definisca il carattere STOP di stringa in analogia al comando AO. Si immagini che un utente di questo protocollo desideri che il server processi la stringa STOP, ma la connessione è bloccata perché il server sta processando altri comandi. L'utente dovrebbe dare ordini al proprio sistema in modo da: 1. Inviare il carattere IP di TELNET 2. Inviare la sequenza di TELNET SYNC, vale a dire: Inviare il Data Mark (DM) come il solo carattere con un'operazione di invio Urgente propria di TCP. 3. Invia il carattere STOP stringa; e... 4. Invia la rappresentazione analoga del DM di TELNET offerta dall'altro protocollo, se questa esiste L'utente, (o il processo che agisce in suo beneficio) deve tramettere la sequenza di TELNET SYNCH descritta sopra nel passo 2 per assicurare che il IP di TELNET giunga attraverso l'interpetre TELNET del server. L'Urgente dovrebbe svegliare il processo TELNET; IP dovrebbe svegliare il processo successivo posto a livello superiore. LA STAMPANTE NVT E LA TASTIERA La stampante NVT non specifica un sistema a proposito di inserimento e dimensione delle pagine in larghezza e lunghezza e può produrre rappresentazioni di tutti i 95 grafici USASCII (codici da 32 fino a 126). Dei 33 codici di controllo USASCII (da 0 a 31 e il 127), e i 128 codici non predefiniti (dal 128 al 255), vengono adottate le seguenti specifiche per la stampante NVT: NOME CODICE SIGNIFICATO NULL (NUL) 0 Nessuna operazione (No OPeration) Line Feed (LF) 10 Muove la stampante alla successiva linea da stampare, conservando la stessa posizione orizzontale. Carriage Return (CR) 13 Muove la stampante verso il margine a sinistra della linea corrente. Postel & Reynolds [Page 10] RFC 854 May 1983 In aggiunta, verranno definiti dei codici, comunque non richiesti per agire nella stampante NVT. Nessuna delle due parti di una connessione TELNET dovrebbe presumere che l'altra parte adotterà o abbia adottato, alcun tipo particolare di azione circa la ricezione o la trasmissione di ciò che segue: BELL (BEL) 7 Produce un segnale udibile o visibile (che assolutamente non muove la testina della stampante). Back Space (BS) 8 Muove la testina della stampante di un carattere verso il margine sinistro. Horizontal Tab (HT) 9 Muove la stampante verso il tab stop successivo. Non rimane specificato come ogni parte determini o stabilisca dove questi tab stops siano locati. Vertical Tab (VT) 11 Muove la stampante verso il successivo tab stop verticale. Non viene specificato come ogni parte determini o stabilisca dove questi tab stops siano locati. Form Feed (FF) 12 Muove la stampante verso il margine superiore della pagina successiva, conservando la stessa posizione orizzontale. Tutti i codici rimanenti non implicano che la stampante assuma alcun modo di agire. La sequenza "CR LF", come definito, causerà che NVT venga posizionato al margine sinistro della linea successiva di stampa (come farebbe per esempio, la sequenza "LF CR"). Tuttavia, molti sistemi e terminali non trattano CR e LF indipendentemente, e dovranno ricorrere ad alcune operazioni per simulare il loro effetto. (Per esempio, qualche terminale non supporta CR indipendentemente da LF, ma su questi terminali è possibile simulare un CR con un backspace.) Perciò, la sequenza "CR LF" deve essere trattata come un singolo carattere "new line" e va usato ogni volta che le loro azioni combinate sono presunte; la sequenza "CR NUL" deve essere usata laddove sia effettivamente desiderata la preparazione di una sola pagina; il carattere CR deve essere evitato in altri contesti. Questa regola garantisce ai sistemi di poter decidere se effettuare una funzione "new line" o un backspace multiplo considerando la sequenza di caratteri dello stream successivi al CR che permetterà una decisione razionale. Nota che "CR LF" o "CR NUL" sono richiesti in entrambe le direzioni Postel & Reynolds [Page 11] RFC 854 May 1983 (nella modalità ASCII di defalut), per preservare la simmetria del modello NVT. Sebbene in certe circostanze (es. echo remoto e soppressione delle opzioni di go haead) sia possibile prevedere che i caratteri non vengano spediti verso una reale stampante, per amor di completezza, il protocollo richiede che venga inserito un NUL seguente un CR e non seguito da LF nello stream. All'opposto, un NUL ricevuto dopo un CR nello stream di dati, dovrebbe essere estratto prima di applicare l'NVT al mappaggio del set di caratteri locali. La tastiera NVT ha tasti (keys), o combinazioni di tasti, o sequenze di tasti, per generare tutti i 128 codici USASCII. Nota che sebbene molti non abbiano effetto sulla stampante NVT, la tastiera NVT è capace di generarli. In aggiunta a questi codici, la tastiera NVT sarà capace di generare i seguenti codici addizionali che, salvo eccezioni, vengono definiti ma non sono obbligatori. I reali assegnamenti di codice per questi "caratteri" sono nella sezione dei Comandi di TELNET, perché essi vengono visti come sono, in qualche senso, genericamente e dovrebbero essere disponibili anche quando lo stream di dati è interpetrato secondo un altro set di caratteri. Synch Questo tasto permette all'utente di cancellare il suo data path verso la controparte. L'attivazione di questo tasto causa un DM (vedi la sezione dei comandi) per essere spedita nello stream di dati ed una notificazione Urgente TCP gli viene associata. Il binomio DM-Urgent deve assumere il significato descritto nei paragrafi precedenti. Break (BRK) Questo codice è disponibile in quanto è un segnale fuori dal set USASCII che è correntemente supportato all'interno di molti sistemi. E' studiato per indicare che il tasto Break (Break Key) o il tasto di Attention (Attention Key) è stato premuto. Nota, comunque, che questo codice è studiato per mettere a disposizione un 129esimo codice per sistemi che lo richiedono, non intende porsi come un sinonimo di IP. Interrupt Process (IP) Sospende, interrompe, abortisce o termina il processo al quale l'NVT è connesso. Inoltre, è parte del segnale out-of-band per altri protocolli che usano TELNET. Postel & Reynolds [Page 12] RFC 854 May 1983 Abort Output (AO) Permette al processo corrente di (sembrare di) computare per completezza ma senza inviare il corrispettivo output all'utente. Inolte, invia un Synch all'utente. Are You There (AYT) Spedisce in ritorno all'NVT un segnale evidente (es. stampabile) che l'AYT è stato ricevuto. Erase Character (EC) Il ricevente dovrebbe cancellare l'ultimo carattere immesso o "print position" dallo stream di dati. Erase Line (EL) Il ricevente dovrebbe cancellare dallo stream di dati i caratteri (in verso di retrocessione) fino a, ma non includendo, l'ultima sequenza "CR LF" spedita lungo la connessione TELNET. L'impiego di questi tasti speciali, nonché dei comandi di manipolazione della stampante, è finalizzato alla possibilità di estendere il sistema di mapping utilizzato normalmente per "NVT" in uno "locale". Proprio come il byte di dati NVT 68 (104 ottale) va associato al suo corrispettivo locale per il codice "uppercase D", così il carattere EC va associato alla corrispondete funzione locale "Erase Character". Inoltre, così come il mappaggio del 124 (174 ottale) è qualcosa di arbitrario in un ambiente che non dispone di un carattere "vertical bar", il carattere EL potrebbe assumere un mappaggio arbitrario (o nessuno) se non si dispone di una risorsa locale per apportare un "Erase Line". Ciò è molto simile agli effettori del formato: se il terminale attualmente dispone di un "Vertical Tab" allora il mappaggio per VT è risulta ovvio, è solo quando il terminale non possiede un vertical tab che l'effetto di VT è imprevedibile. STRUTTURA DI UN COMANDO TELNET Tutti i comandi TELNET consistono di almeno una sequenza di due byte: il carattere di escape "Interpret as Command" (IAC) seguito dal codice per il comando. I comandi riguardanti la negoziazione di opzioni sono tre sequenze di byte, il terzo byte è il codice al quale l'opzione è riferita. Questo formato è stato scelto così da indurre un uso più intelligente del "data space" -- tramite negoziazioni dall'NVT di base, naturalmente -- le collisioni dei byte di dati con i valori di comando verranno minimizzati, tutte le simili collisioni che intercorrono nell'inconveniente, e l'inefficienza, di "escaping" dei byte di dati all'interno dello stream. Postel & Reynolds [Page 13] RFC 854 May 1983 Con il set-up attuale, solo IAC ha bisogno di essere ripetuto due volte per essere inviato come dato, e gli altri 255 codici possono essere passati trasparentemente. Qui di seguito sono definiti i comandi di TELNET. Nota che questi codici e le sequenze di codice assumono il significato che viene indicato solo quando sono immediatamente preceduti da un IAC. NAME CODE MEANING SE 240 End of subnegotiation parameters. NOP 241 No operation. Data Mark 242 The data stream portion of a Synch. This should always be accompanied by a TCP Urgent notification. Break 243 NVT character BRK. Interrupt Process 244 The function IP. Abort output 245 The function AO. Are You There 246 The function AYT. Erase character 247 The function EC. Erase Line 248 The function EL. Go ahead 249 The GA signal. SB 250 Indicates that what follows is subnegotiation of the indicated option. WILL (option code) 251 Indicates the desire to begin performing, or confirmation that you are now performing, the indicated option. WON'T (option code) 252 Indicates the refusal to perform, or continue performing, the indicated option. DO (option code) 253 Indicates the request that the other party perform, or confirmation that you are expecting the other party to perform, the indicated option. DON'T (option code) 254 Indicates the demand that the other party stop performing, or confirmation that you are no longer expecting the other party to perform, the indicated option. IAC 255 Data Byte 255. Postel & Reynolds [Page 14] RFC 854 May 1983 INSTAURAZIONE DELLA CONNESSIONE La connessione TCP TELNET viene stabilita tra la porta U dell'utente e la porta L del server. Il server si tiene in ascolto nella sua porta L (compresa tra le well known) in attesa di connessioni. Poiché una connessione TCP è full duplex ed è identificata da una coppia di porte il server può essere impegnato in più connessioni simultane. In tal caso le connessioni coinvolgeranno la porta L del server e diverse porte U dell'utente. Assegnazione della Porta Quando usato per l'accesso utente ad un servizio offerto da un sistema remoto (es. accesso terminale remoto) la porta assegnata al server per questo protocollo è la 23 (27 ottale). In questo modo L=23. ------------------------------- Tradotto da: Andrea Ingegneri - email: a_ingegneri@hotmail.com Note di traduzione: ho tradotto questo documento senza alcuna particolare pretesa ma con lo scopo di aiutare me stesso e gli altri nella lettura dell'RFC 854 reperibile in forma originale presso http://www.rfc-editor.org/. Invito infatti il lettore ad accompagnare la lettura del presente a quella dell'originale in lingua inglese ed in caso di errori di traduzione provvedere alla loro correzione. Ho volutamente evitato di tradurre certi termini che ho reputato conservassero un significato più forte nella loro lingua di origine. Date alcune caratteristiche del documento prettamente legate a varie forme grammaticali tipiche della lingua inglese, è probabile che certe frasi siano state riformulate per suonare meglio in italiano, in ogni caso si è cercato di lasciare intatto il significato originale, che può comunque essere tratto dal testo vero e proprio. Finito di tradurre il 27 Aprile 2002 Postel & Reynolds [Page 15]