Network Working Group J. VanBokkelen Request for Comments: 1091 FTP Software, Inc. Obsoletes: RFC 930 February 1989 L'opzione telnet TERMINAL-TYPE Traduzione a cura di ComiSAT Brescia, Gen. 2019 (comisat@yahoo.it) Distribuita da .::http://www.rfc.altervista.org::. Stato di Questo Documento Questa RFC specifica uno standard per la comunita' Internet. Gli host su internet che si scambiano informazioni relative al tipo di terminale all'interno del protocollo Telnet devono adottare ed implementare questo standard. Questo standard sostituisce l'RFC 930. Viene fatta una modifica per consentire lo scorrimento di un elenco di possibili tipi di terminale per selezionare quello piu' appropriato. La distribuzione di questo documento non e' soggetta a limitazioni. 1. Nome e Codice del Comando TERMINAL-TYPE 24 2. Significati del Comando IAC WILL TERMINAL-TYPE Il mittente esprime la volonta' di inviare informazioni relative al tipo di terminale mediante una subnegoziazione. IAC WON'T TERMINAL-TYPE Il mittente rifiuta di inviare informazioni relative al tipo di terminale. IAC DO TERMINAL-TYPE Il mittente esprime la volonta' di ricevere informazioni relative al tipo di terminale mediante una subnegoziazione. IAC DON'T TERMINAL-TYPE Il mittente rifiuta di accettare informazioni relative al tipo di terminale. VanBokkelen [Page 1] RFC 1091 Telnet Terminal-Type Option February 1989 IAC SB TERMINAL-TYPE SEND IAC SE Il server chiede al client di trasmettergli il suo (del client) successivo tipo di terminale e di cambiare le modalita' di emulazione (se sono supportati piu' di un tipo di terminale). Il codice di SEND e' 1. (Vedasi piu' avanti). IAC SB TERMINAL-TYPE IS ... IAC SE Il client riporta il nome del suo attuale (od unico) tipo di terminale. Il codice di IS e' 0. (Vedasi piu' avanti). 3. Default WON'T TERMINAL-TYPE Le informazioni relative al tipo di terminale non saranno scambiate. DON'T TERMINAL-TYPE Le informazioni relative al tipo di terminale non saranno scambiate. 4. Motivi dell'Opzione Sulla maggior parte delle macchine con display a mappa di bit (ad es. PC e postazioni di lavori grafiche) viene utilizzato un programma per l'emulazione di terminale client per simulare un terminale ASCII convenzionale. La maggior parte di questi programmi hanno piu' modalita' di emulazione, spesso con un'ampia varieta' di caratteristiche. Allo stesso modo, applicazioni e sistemi moderni possono avere a che fare con una varieta' di tipi di terminale. Cio' che serve e' un modo per il client di presentare al server un elenco di modalita' di emulazione di terminale disponibili, dal quale il server puo' selezionare quella preferita (per ragioni arbitrarie). E' inoltre necessario un meccanismo per modificare la modalita' di emulazione durante il corso di una sessione, magari in funzione di esigenze dei programmi applicativi. Gli esistenti meccanismi per il passaggio del tipo di terminale in telnet non sono stati progettati tenendo conto di modalita' multiple di emulazione. Sebbene siano ammessi nomi multipli, essi sono considerati sinonimi. Non sono definite modifiche alla modalita' di emulazione, e l'elenco delle modalita' puo' essere scansionato solo una volta. Questo documento definisce una semplice estensione ai meccanismi esistenti che soddisfa entrambi i criteri di cui sopra. Questa suppone il comportamento delle implementazioni codificate secondo lo standard precedente al fine di ottenere la piena retrocompatibilita'. VanBokkelen [Page 2] RFC 1091 Telnet Terminal-Type Option February 1989 5. Descrizione dell'Opzione La disponibilita' a scambiare informazioni relative al tipo di terminale e' concordata attraverso una negoziazione di opzione telnet convenzionale. WILL e DO sono utilizzati solamente per ottenere e garantire il permesso per discussioni future. L'attuale scambio delle informazioni di stato avviene all'interno del sottocomandi di opzione (IAC SB TERMINAL-TYPE...). Una volta che i due host si sono scambiati un WILL e un DO, il mittente del DO-TERMINAL-TYPE (il server) e' libero di richiedere l'informazione relativa al tipo. Solamente il server puo' inviare richieste IAC SB TERMINAL-TYPE SEND IAC SE) e solamente il client puo' trasmettere l'informazione relativa al tipo di terminale corrente (all'interno di un comando IAC SB TERMINAL-TYPE IS ... IAC SE). L'informazione relativa al tipo di terminale non puo' essere inviata spontaneamente, ma solamente in risposta ad una richiesta. L'informazione relativa al tipo di terminale e' una stringa NVT ASCII. All'interno di questa, caratteri maiuscoli e minuscoli sono considerati equivalenti. L'elenco completo dei nomi validi per i tipi di terminale si trova nell'ultima RFC "Numeri Assegnati" [4]. La trasmissione dell'informazione relativa al tipo di terminale da un client telnet in risposta ad una richiesta da parte di un server telnet implica che il client debba contemporaneamente cambiare la modalita' di emulazione, a meno che il tipo di terminale inviato sia un sinonimo di un tipo di terminale precedente, o vi siano altri prerequisiti per l'accesso ad un nuovo regime (ad es. aver concordato l'opzione telnet BINARY). La ricezione di tale informazione da parte del server non implica un immediato cambio di elaborazione. Ad ogni modo, l'informazione puo' essere passata ad un processo, il quale puo' modificare i dati che invia per soddisfare particolari caratteristiche del terminale. Ad esempio, alcuni sistemi operativi hanno un terminale che accetta un codice per indicare il tipo di terminale che dev'essere usato. Mediante le opzioni TERMINAL TYPE e BINARY un server telnet su un tale sistema potrebbe fare in modo che i terminali si muovano come se fossero connessi direttamente comprese le funzioni speciali non disponibili ad un terminale di rete virtuale (NVT) standard. Si tenga presente che questa specifica e' volutamente asimmetrica. Essa parte dal presupposto che i sistemi operativi e le applicazioni server in generale non modifichino i tipi di terminale in punti arbitrari di una sessione. Cosi', un client puo' inviare un nuovo tipo (e potenzialmente cambiare la modalita' di emulazione) solamente quando gli viene richiesto dal server. 6. Considerazioni sull'Implementazione L'informazione relativa al "tipo di terminale" puo' essere qualsiasi stringa NVT ANSI significativa per entrambi i lati della negoziazione. La lista dei nomi dei tipi di terminale in "Numeri Assegnati" e' intesa VanBokkelen [Page 3] RFC 1091 Telnet Terminal-Type Option February 1989 per minimizzare la confusione generata da "grafie" alternative dei tipi di terminale. Ad esempio, potrebbe nascere confusione qualora una delle due parti chiami un terminale "IBM3278-2" mentre l'altra parte lo chiami "IBM-3278/2". Qualora un tipo di terminale non sia compreso non vi sono conseguenza negative tranne che per alcune altre opzioni (come ad esempio lo switch alla modalita' BINARY) che potrebbero essere rifiutate qualora non sia stato specificato un tipo di terminale valido. In alcuni casi, uno specifico terminale puo' essere conosciuto con piu' di un nome, ad esempio un tipo specifico ed un tipo invece piu' generico, oppure il client puo' essere una workstation con un display integrato in grado di emulare piu' di un tipo di terminale. In questi casi, il mittente del comando TERMINAL-TYPE IS dovrebbe rispondere a successivi comandi TERMINAL-TYPE SEND con vari nomi. In questo modo, un server telnet che non comprende la prima risposta puo' richiedere le alternative. Se un client supporta emulazioni di terminale differenti, la modalita' dell'emulatore dev'essere modificata per coincidere con l'ultimo tipo inviato, salvo emulazioni particolari che abbiano altre opzioni telnet (ad ese. BINARY) come prerequisiti (in quel caso, l'emulazione cambiera' all'ultimo tipo inviato quando il prerequisito verra' soddisfatto). Quando i tipi sono sinonimi essi dovrebbero essere inviati nell'ordine dal piu' al meno specifico. Quando il server (il ricevente del TERMINAL_TYPE IS) riceve la stessa risposta per due volte consecutive, significa che si ha raggiunto la fine della lista dei tipi disponibili. In modo analogo, il client dovrebbe indicare che ha inviato tutti i nomi disponibili ripetendo l'ultimo inviato. Se viene ricevuta una successiva richiesta, allora significa che il server desidera tornare all'inizio della lista dei tipi disponibili (probabilmente per scegliere il male minore). Le implementazioni server conformi allo standard precedente smetteranno di inviare comandi TERMINAL-TYPE SEND dopo aver ricevuto la stessa risposta due volte consecutive, funzionando in accordo al vecchio standard. Si presume che le implementazioni client conformi allo standard precedente invieranno l'ultimo tipo della lista in risposta ad una terza richiesta (cosi' come la seconda). I server nuovo-stile devono riconoscerlo e non inviare piu' richieste. Se il tipo di terminale e' sconosciuto o non riconosciuto dall'altra parte dovrebbe essere usato il tipo "UNKNOWKN". Una lista completa ed aggiornata dei nomi di tipi di terminale verra' mantenuta nel "Numeri Assegnati". La lunghezza massima del nome di un tipo di terminale e' di 40 caratteri. 7. Interfacce Utente I client ed i server telnet conformi a questa specifica dovrebbero VanBokkelen [Page 4] RFC 1091 Telnet Terminal-Type Option February 1989 fornire, nelle loro interfacce utente, le seguenti funzioni: I client che supportano modalita' di emulazione multipla dovrebbero consentire all'utente di specificare quale sia la modalita' preferita (quale nome inviare per primo) prima di stabilire la connessione. L'ordine dei nomi inviati non dovrebbe poter essere cambiato dopo che e' iniziata la negoziazione. Tale modalita' iniziale sara' anche la modalita' di default per i server che non supportano l'opzione TERMINAL TYPE. I server dovrebbero memorizzare il nome del tipo di terminale corrente e la lista dei nomi disponibili in modo che sia accessibile ad entrambi gli utente (tramite un comando da tastiera) e a qualsiasi applicazione che necessita dell'informazione. In aggiunta, dovrebbe esserci un meccanismo corrispondente per richiedere la modifica del tipo di terminale attraverso una serie di subnegoziazioni SEND/IS. 8. Esempi In questo esempio il server considera accettabile il primo tipo. Server: IAC DO TERMINAL-TYPE Client: IAC WILL TERMINAL-TYPE (Il server puo' ora richiedere un tipo di terminale in qualsiasi momento) Server: IAC SB TERMINAL-TYPE SEND IAC SE Client: IAC SB TERMINAL-TYPE IS IBM-3278-2 IAC SE In questo esempio il server richiede tipi di terminali aggiuntivi ed accetta il secondo (ed ultimo della lista del client) tipo inviato (compatibile alla RFC 930): Server: IAC DO TERMINAL-TYPE Client: IAC WILL TERMINAL-TYPE (Il server puo' ora richiedere un tipo di terminale in qualsiasi momento) Server: IAC SB TERMINAL-TYPE SEND IAC SE Client: IAC SB TERMINAL-TYPE IS ZENITH-H19 IAC SE Server: IAC SB TERMINAL-TYPE SEND IAC SE Client: IAC SB TERMINAL-TYPE IS UNKNOWN IAC SE VanBokkelen [Page 5] RFC 1091 Telnet Terminal-Type Option February 1989 Server: IAC SB TERMINAL-TYPE SEND IAC SE Client: IAC SB TERMINAL-TYPE IS UNKNOWN IAC SE In questo esempio, il server richiede tipi di terminali aggiuntivi, e procede oltre la fine della lista per selezionare il primo tipo offerto dal client (client e server di tipo nuovo): Server: IAC DO TERMINAL-TYPE Client: IAC WILL TERMINAL-TYPE (Il server puo' ora richiedere un tipo di terminale in qualsiasi momento) Server: IAC SB TERMINAL-TYPE SEND IAC SE Client: IAC SB TERMINAL-TYPE IS DEC-VT220 IAC SE Server: IAC SB TERMINAL-TYPE SEND IAC SE Client: IAC SB TERMINAL-TYPE IS DEC-VT100 IAC SE Server: IAC SB TERMINAL-TYPE SEND IAC SE Client: IAC SB TERMINAL-TYPE IS DEC-VT52 IAC SE Server: IAC SB TERMINAL-TYPE SEND IAC SE Client: IAC SB TERMINAL-TYPE IS DEC-VT52 IAC SE Server: IAC SB TERMINAL-TYPE SEND IAC SE Client: IAC SB TERMINAL-TYPE IS DEC-VT220 IAC SE 9. Riferimenti: [1] Postel, J., and J. Reynolds, "Telnet Protocol Specification", RFC 854, USC Information Sciences Institute, May 1983. [2] Postel, J., and J. Reynolds, "Telnet Option Specification", RFC 855, USC Information Sciences Institute, May 1983. [3] Solomon, M., and E. Wimmers, "Telnet Terminal Type Option", RFC 930, University of Wisconsin - Madison, January 1985. [4] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1010, USC Information Sciences Institute, May 1987. VanBokkelen [Page 6] RFC 1091 Telnet Terminal-Type Option February 1989 Nota del Revisore: Devo molto del presente testo alle RFC 884 e 930, di Marvin Solomon e Edward Wimmers dell'Universita' del Wisconsin - Madison, e devo l'idea dell'estensione alle discussioni sulla mailing lista "tn3270" dell' estate 1987. Indirizzi degli Autori James VanBokkelen FTP Software, Inc. 26 Princess Street Wakefield, MA 01880-3004 Phone: (617) 246-0900 Email: jbvb@ftp.com VanBokkelen [Page 7]