Introduzione

Riteniamo la proposta Meyer (Note #46) la più accettabile finora, esattamente per le ragioni che egli elenca, vale a dire: semplice, sufficiente per la maggior parte degli usi previsti della rete, facile da implementare, estensibile. Non comprende tutto ciò che è stato suggerito di recente; tuttavia concordiamo con i punti proposti e riteniamo che le funzionalità mancanti probabilmente non valgano la pena di essere contrastate, ritardando così la specifica.

Formuliamo i seguenti commenti sulle sette questioni sollevate nella Note #47.

Concordiamo con Steve sul fatto che la riconnessione dinamica sarà necessaria in seguito per usi più sofisticati della rete. Concordiamo anche con le persone del Project MAC sul fatto che inizialmente non è necessaria. Con un po' di esperienza della rete e con le esigenze specifiche del suo uso, la riconnessione dinamica può essere realizzata meglio.
INT è facile da implementare e serve a uno scopo utile.
Siamo favorevoli a includere un sottocampo per l'identificatore di tag di istanza. Vediamo la necessità di entrambi i casi: a) quando più processi devono apparire indistinguibili, e b) quando un dato utente che possiede più processi deve distinguerli. Le parti di programma che non devono distinguere tra i processi dovrebbero semplicemente ignorare il tag di istanza. Il suggerimento di Tom di usare parte del sottocampo del numero utente riduce soltanto la lunghezza complessiva dei sottocampi da 32 bit a 24 bit; il problema rimane.
Non concordiamo né con Steve né con MAC sul fatto che non si debba imporre alcuna struttura particolare ai dati trasmessi. Preferiamo il « message data type » citato da E. I. Ancona, Note #42, pagina 1. Un esempio del suo uso è stato citato nella Note #39, pagina 2, transmit vs broadcast. Per quanto riguarda un insieme di caratteri standard, sosteniamo fermamente l'adozione di uno fin dall'inizio, in particolare ASCII. Abbiamo osservato che la maggior parte dei siti aveva già suggerito ASCII. C'è qualcuno che obietta?
L'allineamento sui confini di parola è più attraente del doppio riempimento.
Il suggerimento di Steve di accodare a breve termine gli RFC è accettabile come opzione.
Sosteniamo l'UCC nella Note #46 per tre ragioni principali:
1. In generale l'utente non dovrebbe conoscere il codice di socket remoto del processo con cui desidera comunicare.
2. La connessione duplex aggiuntiva può fornire un certo controllo di supervisione sul comportamento del processo, eventualmente in combinazione con la procedura di interrupt.
3. La maggior parte degli altri metodi proposti richiede l'accodamento.
Riteniamo che debba esistere un UCC standard, ma incoraggiamo UCC sperimentali paralleli.

Formuliamo due commenti aggiuntivi sulla Note #46 che non sono stati ribaditi nella Note #47.

BLK e RSM sono più lineari dei suggerimenti precedenti e non negano il multiplexing su un dato collegamento. Per quanto riguarda l'uso dei collegamenti, facciamo riferimento a un esempio fornito da Bob Kahn in cui un IMP intermedio cade e si mangia il RFNM di qualcuno. Ciò non dovrebbe richiedere una riconnessione.

Nella Note #46, pagina 6, l'affermazione che l'UCC ha la capacità di chiudere le connessioni verso un processo morto dipende dall'installazione. Nel nostro caso particolare l'NCP viene informato direttamente del guasto di un processo, a causa della particolare interfaccia software attraverso la quale tutti i processi, incluso l'NCP, devono comunicare.

JFH:hs

Nota: Questo RFC è stato reso in forma leggibile dalla macchina per l'inserimento negli archivi RFC online da Gary Okada 7/97.