3. Convenzioni Telnet proposte
3A.
Il sito server deve inizialmente presumere che l'eco sia eseguito da un processo del sito utente, fino a esplicito comando contrario. Se il sito utente può inviare carattere per carattere, allora, dopo che connessione e login sono stati stabiliti, l'utente può passare all'eco del sito server (server-site-echo) con un comando al sito server e quindi comandare (in modo invisibile al sito server) il suo Telnet locale di cambiare anch'esso la propria modalità di eco.
3B.
Il processo server deve presumere che riceverà lo stesso insieme di caratteri che i terminali «direttamente» collegati ad esso possono generare. (Raccomandiamo almeno l'ASCII a 128 caratteri.) Il Telnet dell'utente potrebbe dover riconoscere sequenze di due caratteri per consentire la generazione sia dei codici maiuscoli e minuscoli sia dei codici di controllo. Raccomandiamo che l'utente possa impostare maiuscole o minuscole come caso predefinito per i terminali a caso singolo e poter specificare un carattere di commutazione di caso (case shift character). L'utente dovrebbe inoltre poter specificare un carattere per indicare che il carattere battuto subito dopo deve essere convertito nel corrispondente codice di carattere di controllo. Quest'ultima convenzione consente che i codici di controllo generati direttamente al terminale siano riconosciuti dal sistema dell'utente, abilitando così l'escape verso il sistema utente. Creare una convenzione che consenta a tutti i codici di controllo di entrare nella rete e che l'uscita della rete alimenti il monitor del server prima di entrare nel processo server fornisce un meccanismo semplice per generare un escape verso molti sistemi esistenti. (Per alcuni sistemi il problema è più complicato di così e ne discutiamo più avanti.)
3C.
Raccomandiamo che vengano stabiliti standard di rete per il significato degli echi locali di HT, VT e FF, oppure che venga stabilita una convenzione per inviare al processo server il significato di questi caratteri. Il NLS(NIC), ad esempio, deve tenere traccia della posizione della testina di stampa e, in assenza di tali convenzioni, convertirà questi codici di caratteri in spazi e avanzamenti di riga. Ciò significa che l'aspetto della pagina in uscita può differire dall'aspetto in ingresso. Sarebbe utile all'utente se la sua pagina in uscita potesse essere formattata come appariva in ingresso.
3D.
I caratteri LF sarebbero trattati come se fossero generati premendo il tasto di avanzamento riga su un terminale «direttamente» collegato al sistema server.
3E.
Il carattere di ritorno carrello (CR) può essere fonte di notevoli difficoltà. Ad esempio, in ingresso, sistemi diversi o lo stesso sistema in momenti diversi, possono riportare in eco e trasmettere codici diversi al terminale e al processo utente. Alcuni sistemi monitor non riportano nulla in eco, oppure solo un CR, oppure un CRLF. Alcuni sistemi trasmettono un CR, un CRLF o un codice di fine riga (end of line, EOL) al processo utente. Il processo utente può controllare l'eco o aggiungervi. Date le combinazioni che possono esistere a ciascuna estremità della connessione di rete e tra loro, può esservi confusione a meno che non assumiamo la definizione del punto 2A e la convenzione di implementazione del punto 2E. Queste assunzioni implicano che, quando viene battuto un CR, sulla rete viene inviato un CR. Se il sistema monitor dell'utente o l'hardware di controllo del terminale converte un CR in un CRLF o in un EOL, allora il programma Telnet deve riconverterlo in un CR. Quando il CR raggiunge il monitor del server, quest'ultimo lo gestirà correttamente per il processo server.
Quando l'eco è gestito dal sistema server, verranno riportati in eco il codice o i codici corretti. Il Telnet dell'utente, alla ricezione di un CRLF, può farlo seguire dai caratteri nulli (null) appropriati per gestire la temporizzazione del movimento del carrello di un particolare terminale.
Quando l'eco è gestito dal sistema utente, sarebbe ideale che il Telnet o il sistema dell'utente usasse la stessa convenzione di eco che userebbe il sistema server. Ciò significa che il Telnet deve avere una tabella delle convenzioni di eco per i vari sistemi ai quali può collegarsi, oppure che può ottenere questa informazione dal sistema o dal processo server, o viceversa.
Per un protocollo Telnet iniziale questo probabilmente non è necessario. Il sistema utente può adottare come comportamento predefinito quello di riportare in eco un CRLF per ogni CR ricevuto. Questo valore predefinito dovrebbe essere soddisfacente per tutte le situazioni che conosciamo e per il NIC.
3F.
Per la comunicazione da sistemi carattere per carattere e riga per riga, il processo Telnet potrebbe dover riconoscere un carattere (assegnabile dall'utente) che chiamiamo fine flusso (end of stream, EOS). Questo carattere deve avere la funzione definita nella discussione che segue. Il punto importante è distinguere la fine flusso (end-of-stream) come funzione di rete dalla fine riga (end-of-line) come funzione del sistema utente o server. Consideriamo prima i sistemi riga per riga. Non abbiamo molta esperienza con i sistemi riga per riga, quindi quanto segue richiederà ulteriore studio e chiarimento. Per come lo comprendiamo, i sistemi riga per riga riconoscono un carattere come CR o un segnale di interruzione (break) come il codice che risveglia il processo utente e provoca la trasmissione a esso della riga di testo. Dal punto di vista del NLS(NIC) è importante che l'utente possa immettere righe di testo ciascuna terminata da un CR quando appropriato e, in altri momenti, poter immettere testo non terminato con un CR. (Una frase per il NLS(NIC) è una stringa di testo di lunghezza «arbitraria» e non deve contenere CR; in uscita la riga viene ripiegata per l'utente al suo confine di pagina, definibile dall'utente.)
Come esempio di ciò che è richiesto, consideriamo il caso in cui il sistema dell'utente riconosce il CR come fine riga. In tal caso il Telnet verrebbe risvegliato alla ricezione di un CR. Raccomanderemmo che, in questo caso, il codice CR venga immesso letteralmente nel buffer di uscita del Telnet. Se un CR è preceduto da un carattere EOS, allora il CR non deve essere posto nel buffer di uscita del Telnet. La trasmissione attraverso la rete può avvenire sia alla ricezione di un EOS sia automaticamente quando il buffer di uscita del Telnet si riempie. La trasmissione da sistemi riga per riga verso sistemi carattere per carattere potrebbe richiedere la scomoda pressione di tre tasti per far passare un carattere attraverso la rete.
Consideriamo ora la trasmissione da un sistema carattere per carattere a un sistema server riga per riga. Un problema simile a quello che verrà descritto esiste anche tra sistemi riga per riga. Data la definizione di un carattere EOS diverso dal CR, una riga può essere accumulata in un buffer fino alla ricezione dell'EOS e quindi inviata senza l'EOS. Come fa il sistema servente a sapere che una riga è stata inviata? Un modo sarebbe che il NCP servente riconosca i confini dei messaggi. Questa convenzione violerebbe un obiettivo di progettazione. Un altro modo sarebbe che il Telnet dell'utente chieda al proprio NCP di inviare un comando INS. L'invio di comandi di controllo di tipo INS potrebbe introdurre condizioni di gara (race conditions) nella rete e dovrebbe essere studiato prima che il loro impiego con un processo Telnet venga stabilito. Poiché alcuni dei sistemi riga per riga che conosciamo dispongono di hardware speciale che riconosce il segnale di fine riga, abbiamo bisogno di un modo per essere compatibili con questo hardware mediante segnali di controllo software. Lasciamo questo problema allo studio ulteriore da parte del sottogruppo del NWG.
3G.
Torniamo ora al problema dell'interruzione o dell'escape nel sistema server remoto. Nei sistemi che non bloccano la tastiera di ingresso mentre è in corso un'uscita, i meccanismi e le convenzioni delineati sopra sembrano adeguati, a meno che il segnale di escape non sia un particolare segnale di interruzione (break signal). Quest'ultimo caso richiede ulteriore studio. Nei sistemi che non consentono alcun ingresso mentre è in corso un'uscita, si potrebbe dover vivere con le conseguenze di una tale disciplina di terminale ed essere pronti ad attendere che l'uscita si fermi prima di poter inviare un codice di escape. Se la tastiera è bloccata e un segnale di interruzione di escape può essere inviato al sistema dell'utente, esso può impedire che l'uscita arrivi al terminale, ma occorre essere pronti a continuare a riceverla dal sito server finché l'utente non possa informare il suo processo Telnet di inviare un segnale di interruzione o di escape al sito server. Anche questo è un problema che richiede ulteriore studio.
Il sistema in linea (Online System) del Network Information Center opera su un sistema monitor carattere per carattere e le convenzioni stabilite in questo documento sono adeguate per accedervi. Queste convenzioni sono riassunte nell'appendice A.