| Network Working
Group J. Postel
Request for Comments: 854 J.
Reynolds
ISI
Obsoletes: NIC 18639 May 1983
SPECIFICHE DEL PROTOCOLLO
TELNET
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]
Per ulteriori RFC in italiano
visita http://www.napolihak.it
|
