Network Working Group J. Postel Request for Comments: 959 J. Reynolds ISI Obsoletes RFC: 765 (IEN 149) October 1985 FILE TRANSFER PROTOCOL (FTP) (protocollo per il trasferimento di file) Traduzione a cura di ComiSAT Brescia, Apr. 2003 (comisat@yahoo.it) Distribuita da .::http://www.rfc.altervista.org::. Stato di questa memoria Questa memoria e’ la specifica ufficiale del Protocollo di Traferimento File (File Transfer Protocol – FTP). La distribuzione di questo documento non e’ soggetta a limitazioni. In questa edizione della specifica sono inclusi i seguenti nuovi comandi opzionali: CDUP (Change to Parent Directory – Vai alla cartella superiore), SMNT (Structure Mount – Monta struttura), STOU (Store Unique - Archivia in modo univoco), RMD (Remove Directory – Rimuovi cartella), MKD (Make Directory – Crea cartella), PWD (Print Directory – Stampa cartella), and SYST (System - Sistema). Si noti che questa specifica e’ compatibile con le edizioni precedenti. Tavola dei contenuti [N.d.T.: nella versione originale l’indice non e’ presente, ma ho ritenuto utile inserirlo ugualmente]. 1. INTRODUZIONE ...................................................... 2 2. GENERALITA’ ....................................................... 2 2.1. Storia ....................................................... 3 2.2. Terminologia ................................................. 4 2.3. Il modello FTP ............................................... 9 3. FUNZIONI DI TRASFERIMENTO DATI .................................... 11 3.1. Rappresentazione dei dati e memorizzazione ................... 11 3.1.1. Tipi di dati ............................................ 12 3.1.1.1. Tipo ASCII ......................................... 12 3.1.1.2. Tipo EBCDIC ........................................ 13 3.1.1.3. Tipo Image (immagine) .............................. 13 3.1.1.4. Tipo Local (locale) ................................ 13 3.1.1.5. Controllo del formato .............................. 14 3.1.1.5.1. Non-print ..................................... 14 3.1.1.5.2. Controllo di formato Telnet ................... 15 3.1.1.5.3. Carriage Control (ASA) ........................ 15 3.1.2. Strutture di dati ....................................... 16 3.1.2.1. Struttura-a-file ................................... 17 3.1.2.2. Struttura-a-record ................................. 17 3.1.2.3. Struttura-a-page (pagina) .......................... 17 Postel & Reynolds [Page 1] RFC 959 October 1985 File Transfer Protocol 3.2. Stabilire la connessione dati ................................ 19 3.3. Gestione della connessione dati .............................. 20 3.4. Modalita' di trasmissione .................................... 21 3.4.1. Modalita' Stream (a flusso) ............................. 22 3.4.2. Modalita' Block (a blocco) .............................. 22 3.4.3. Modalita' Compressed (compressa) ........................ 24 3.5. Ripristino di errori e riavvio ............................... 25 4. FUNZIONI DI TRASFERIMENTO FILE .................................... 26 4.1. Comandi FTP .................................................. 26 4.1.1. Comandi di controllo d'accesso .......................... 26 4.1.2. Comandi che specificano i parametri di trasferimento .... 28 4.1.3. Comandi di servizio FTP ................................. 30 4.2. Risposte FTP ................................................. 36 4.2.1. Codici di risposta per gruppi di funzione ............... 40 4.2.2. Elenco ordinato dei codici di risposta .................. 42 5. SPECIFICHE DICHIARATIVE ........................................... 44 5.1. Implementazione minima ....................................... 44 5.2. Connessioni .................................................. 45 5.3. Comandi ...................................................... 46 5.3.1. Comandi FTP ............................................. 48 5.3.2. Argomenti dei comandi FTP ............................... 49 5.4. Sequenze di comandi e risposte ............................... 50 6. DIAGRAMMI DI STATO ................................................ 55 7. TIPICO SCENARIO FTP ............................................... 60 8. ISTITUZIONE DELLA CONNESSIONE ..................................... 60 APPENDICE I - Struttura-a-page (pagina) ............................ 61 APPENDICE II - Comandi relativi alle cartelle ....................... 63 APPENDICE III - RFCs relative al FTP ................................. 67 RIFERIMENTI .......................................................... 70 1. INTRODUZIONE Gli obiettivi del FTP sono 1) promuovere la condivisione di files (dati e/o programmi), 2) incoraggiare l’uso implicito o indiretto di comuputers remoti (via software), 3) proteggere un utente da variazioni nei sistemi di archiviazione file tra hosts, e 4) trasferire dati in modo efficiente ed affidabile. L’FTP, benche’ usabile direttamente da un utente ad un terminale, e’ disegnato principalmente per essere usato da programmi. Il tentativo di questa specifica e’ soddisfare le diverse necessita’ degli utenti di maxi-hosts, mini-hosts, personal workstations e TACs, grazie ad un protocollo semplice e facilmente implementabile. Questo articolo presuppone la conoscenza del Transmissione Control Protocol (TCP) [2] e del Telnet Protocol [3]. Tali documenti sono contenuti nella guida protocolli dell’ARPA-internet [1]. 2. GENERALITA’ In questa sezione viene discussa la storia, la terminologia e il modello FTP. I termini definiti in questa sezione sono quelli che hanno un significato particolare per l’FTP. Parte della terminologia e’ strettamente specifica al modello FTP; alcuni lettori possono fare riferimento alla sezione sul modello FTP mentre riesamino la terminologia. Postel & Reynolds [Page 2] RFC 959 October 1985 File Transfer Protocol 2.1. STORIA L’FTP ha avuto una lunga evoluzione negli ultimi anni. L’Appendice III e’ un elenco cronologico delle Request for Comment relative all’FTP. Queste includono il primo meccanismo di trasferimento file del 1971, sviluppato per l’implementazione su hosts al M.I.T. (RFC 114), e commenti e discussioni nell’RFC 141. L’RFC 172 forniva un protocollo orientato a livello-utente per il trasferimento di file tra hosts (compresi terminali IMP). La revisione di questo documento della RFC 265 riespose l’FTP ad una rivisitazione aggiuntiva, mentre l’RFC 281 suggeriva ulteriori modifiche. L’uso di una transazione “Set Data Type” fu proposta con la RFC 294 nel Gennaio 1982. L’RFC 354 rese obsolete le RFCs 264 e 265. Il File Transfer Protocol era adesso definito come un protocollo per il trasferimento di file tra hosts su ARPANET, con la funzione primaria di trasferire file tra hosts in modo affidabile ed efficiente e consentire l’uso conveniente di capacita’ di archiviazione remota di files L’RFC 385 commentava ulteriori errori, punti di enfasi e aggiunte al protocollo, mentre la RFC 414 forniva un rapporto su server e user FTP. La RFC 430, pubblicata nel 1973 (tra altre RFC troppo numerose per essere menzionate) presentava ulteriori commenti sull’FTP. Finalmente arriviamo ad un documento “ufficiale” sull’FTP con l’RFC 454. Dal Luglio 1973 sono state fatte considerevoli modifiche dall’ultima versione dell’FTP, tuttavia la struttura generale e’ rimasta sempre la stessa. L’RFC 542 fu pubblicata come nuova specifica “ufficiale” che rifletteva tali cambiamenti. Ad ogni modo, molte implementazioni basate sulle precedenti specifiche non furono aggiornate. Nel 1974 le RFCs 607 e 614 continuarono a portare commenti sull’FTP. La RFC 624 proponeva ulteriori cambiamenti e modifiche di minor importanza. Nel 1975 l’RFC 686, intitolata “Leaving Well Enough Alone”, discuteva le differenza tra tutte le versioni del FTP. La RFC 691 presentava una revisione minore della RFC 686, riguardante il soggetto dei file stampa. Motivata dalla transizione dal NCP al TCP nacque, da tutte le RFC precedenti, l’RFC 765, come specifica del FTP usato col TCP. Quest’attuale edizione della specifica FTP e’ intesa a correggere alcuni errori delle documentazioni minori, migliorare la spigazione di alcune caratteristiche del protocollo, e aggiungere alcuni nuovi comandi opzionali. Postel & Reynolds [Page 3] RFC 959 October 1985 File Transfer Protocol In particolare, i seguenti nuovi comandi opzionali vengono inclusi in questa edizione della specifica: CDUP - Change to Parent Directory (vai alla cartella superiore) SMNT - Structure Mount (monta struttura) STOU - Store Unique (memorizza in modo univoco) RMD - Remove Directory (rimuovi cartella) MKD - Make Directory (crea cartella) PWD - Print Directory (visualizza cartella corrente) SYST – System (sistema) La presente specifica e’ compatibile con le edizioni precedenti. Un programma implementato in conformita’ alle precedenti specifiche dovrebbe essere automaticamente conforme a questa specifica. 2.2. TERMINOLOGIA ASCII Il set di caratteri ASCII e’ come definito nell’ARPA-Internet Protocol Handbook. Nel FTP, i caratteri ASCII sono definiti per essere la meta’ piu’ bassa di un set di codici a 8-bit (es°, il bit piu’ significativo e’ lo zero). Controlli d’accesso I controlli d’accesso definiscono i privilegi d’accesso di un utente nell’uso di un sistema ed ai files di quel sistema. I controlli di accesso sono necessari per prevenire utilizzi accidentali o non autorizzati di files. E’ prerogativa di un processo server-FTP invocare controlli d’accesso. Dimensione in byte Vi sono due tipi di dimensioni in byte di interesse nel FTP: la dimensione in byte logica di un file, e la dimensione in byte di trasferimento usata per la trasmissione dei dati. La dimensioni in byte di trasferimento e’ sempre a 8 bits. La dimensioni in byte di trasferimento non e’ necessariamente la dimensione con cui vengono memorizzati i dati in un sistema, ne’ la dimensione in byte logica per l’interpretazione della struttura dei dati. Postel & Reynolds [Page 4] RFC 959 October 1985 File Transfer Protocol Connessione di controllo Percorso di comunicazione tra il PI-utente e il PI-server per lo scambio di comandi e risposte. Questa connessione segue il Telnet Protocol. Connessione di dati Connessione full-duplex sulla quale sono trasferiti i dati, in un modo e tipo specificato. I dati trasferiti possono essere parte di un file, un file intero o un numero di files. Il percorso puo’ essere tra un DTP-server e un DTP-utente, oppure tra DTP-servers. DTP [N.d.T.: Data Transfer Process - processo di trasferimento dati) Il processo di trasferimento dati stabilisce e dirige la connesione di dati. Il DTP puo’ essere passivo o attivo. Porta dati Il processo di trasferimento dati passivo “ascolta” su una porta dati per una connessione dal processo di trasferimento attivo in modo tale da aprire la connessione di dati. End-of-Line La sequenza end-of-line [N.d.T.: fine della linea] definisce la separazione tra le linee visualizzate (stampate). La sequenza e’ un Carriage Return (ritorno a capo) seguito da un Line Feed (inizio riga). EOF La condizione end-of-file [N.d.T.: fine del file] che definisce la fine di un file che e’ stato traferito. EOR La condizione end-of-record [N.d.T.: fine del record] che definisce la fine di un record che e’ stato traferito. Ripristino d’errore Una procedura che consente ad un utente di sistemare alcuni errori come il failure [fallimento] di un sistema host o di un processo di traferimento. Nel FTP, il ripristino d’errore puo’ implicare il rieseguire il trasferimento di un file da un dato checkpoint [punto di controllo]. Postel & Reynolds [Page 5] RFC 959 October 1985 File Transfer Protocol Comandi FTP Set (insieme) di comandi che comprendono lo scorrimento delle informazioni di controllo dal FTP-utente al processo FTP-server. File Un insieme ordinato di dati (compresi i programmi) di lunghezza arbitraria e univocamente identificato da un nome (comprensivo di percorso). Mode La modalita’ nella quale i dati vengono trasferiti in una connessione di dati. La modalita’ definisce il formato dei dati durante il trasferimento compreso l’EOR e l’EOF. Le modalita’ di trasferimento definite nel FTP sono descritte nella sezione sulle Modalita’ di Trasmissione. NVT [N.d.T.: Network Virtual Terminal – terminale virtuale di rete] Il terminale virtuale di rete come definito nel protocollo telnet. NVFS [N.d.T.: Network Virtual File System – file system virtuale di rete] Il file system virtuale di rete. Un concetto che definisce un file system standard di rete con comandi standard e convenzioni di pathname (percorsi e relativa nomenclatura). Page [N.d.T.: pagina] Un file puo’ essere strutturato come un insieme di parti indipendenti chiamate pages. L’FTP supporta la trasmissione di files discontinui come indipendenti pages indicizzati. Pathname [N.d.T.: Percorso - nome di un file comprensivo di percorso] Il pathname viene definito affinche’ sia la stringa di caratteri che dev’essere data ad un file system da un utente in modo che un file sia identificato. Il pathname contiene solitamente nomi di cartelle e/o device (dispositivi), e il nome specifico del file. L’FTP non specifica ancora uno standard di convenzione per pathname. Ciascun utente deve seguire le convenzioni di nomenclatura dei file system chiamato in causa nel trasferimento. PI [N.d.T.: Protocol Interpreter – interprete del protocollo] I lati utente e server del protocollo hanno ruoli distinti implementati in un PI-utente e un PI-server. Postel & Reynolds [Page 6] RFC 959 October 1985 File Transfer Protocol Record Un file sequenziale puo’ essere strutturato come un numero di parti contigue denominate records. Le strutture di records sono supportate dal FTP ma un file necessita di non avere una struttura di record. Risposta Una risposta e’ un riconoscimento (positivo o negativo) inviato dal server all’utente tramite la connessione di controllo in risposta a comandi FTP. La forma generale di una risposta e’ un codice (compresi i codici di errore) seguito da una stringa di testo. I codici sono per un uso da parte dei programmi mentre il testo e’ normalmente inteso per gli utenti. DTP-server Il processo di trasferimento dati, nel suo normale stato “attivo”, stabilisce la connessione di dati con l’”ascolto” sulla porta dati. Esso imposta i parametri per il trasferimento e la memorizzazione, e trasferisce i dati mediante comandi dal suo interprete del protocollo. Il DTP puo’ essere messo in stato “passivo” di ascolto anziche’ iniziare una connessione sulla porta dati. Processo FTP-server Un processo o un insieme di processi che svolgono la funzione di trasferimento file in cooperazione con un processo FTP-utente e, possibilmente, con un altro server. Le funzioni consistono in un interprete di protocollo (PI) e un processo di trasferimento dati (DTP). PI-server Il server interprete di protocollo “ascolta” sulla Porta L per una connessione da un PI-utente [N.d.T.: interprete di protocollo lato client] e stabilisce una connessione di controllo. Esso riceve comandi FTP standard dal PI-utente, invia risposte e governa il DTP-server. Tipo Il tipo di rappresentazione dati usato per il trasferimento e la memorizzazione di dati. Il tipo implica alcune trasformazioni tra il tempo di memorizzazione e trasferimento dati. I tipi di rappresentazione definiti nel FTP sono descritti nella sezione relativa alla Istituzione della Connessione Dati. Postel & Reynolds [Page 7] RFC 959 October 1985 File Transfer Protocol Utente Una persona o un processo che desidera ottenere un servizio di trasferimento file. L’utente umano puo’ interagire direttamente con un processo FTP-server, tuttavia si preferisce l’uso di un processo FTP-utente dal momento che il protocollo e’ stato concepito a favore delle automazioni. DTP-utente Il processo di trasferimento dati “ascolta” sulla porta dati per una connessione da un processo FTP-server. Se sono due server che trasferiscono dati tra loro, il DTP-utente e’ inattivo. Processo FTP-utente Insieme di funzioni che comprendono un interprete di protocollo, un trasferimento dati, e un interfaccia utente, i quali eseguono insieme la funzione di trasferimento file in cooperazione con uno o piu’ processi FTP-server. L’interfaccia utente consente l’uso di un linguaggio locale nel dialogo di risposta ai comandi con l’utente. PI-utente L’interprete del protocollo utente inizia la connessione di controllo dalla sua porta U al processo FTP-server, inizia i comandi FTP e governa il DTP-utente se tale processo e’ parte del trasferimento file. Postel & Reynolds [Page 8] RFC 959 October 1985 File Transfer Protocol 2.3. IL MODELLO FTP Tenendo a mente le definizioni viste sopra, si puo’ schematizzare un servizio FTP (mostrato in Figura 1). ----------------- |/-------------\| || Interfaccia || ---------- || utente |<--->| Utente | |\-------^-----/| ---------- ---------- | | | |/------\| Comandi FTP |/-------V-----\| || PI |<---------------->| PI || ||Server|| Rispste FTP || Utente || |\--^---/| |\-------^-----/| | | | | | | -------- |/--V---\| Connessione |/-------V-----\| --------- | File |<--->| DTP |<---------------->| DTP |<--->| File | |System| ||Server|| di Dati || Utente || |System | -------- |\------/| |\-------------/| --------- ---------- ----------------- FTP-Server FTP-Utente NOTE: 1. La connessione dati puo’ essere usata in entrambe le direzioni. 2. La connessione dati non deve esistere per tutto il tempo. Figura 1 Modello FTP Nel modello rappresentato in Figura 1, l’interprete del protocollo lato utente inizia la connessione di controllo. La connessione di controllo segue il protocollo telnet. All’iniziazione utente vengono generati comandi FTP standard dal PI-utente che sono trasmessi al processo server mediante la connessione di controllo. (L’utente puo’ stabilire una connessione di controllo diretta col FTP-server, ad esempio da un terminale TAC, e generare indipendentemente i comandi FTP standard, scavalcando il processo FTP-utente). Le risposte standard vengono inviate dal PI-server al PI-utente tramite la connessione di controllo in riposta ai comandi. I comandi FTP specificano i parametri per la connessione di dati (porta, modalita’ di trasferimento, tipo di rappresentazione e struttura) e la natura delle operazioni file system (memorizzazione, richiamo, aggiunta in coda, cancellazione, ecc.). Il DTP-utente o il suo designato deve “ascoltare” sulla porta specificata, e il server inizia la connessione di dati e il trasferimento di dati secondo i parametri specificati. Postel & Reynolds [Page 9] RFC 959 October 1985 File Transfer Protocol Si noti che la porta dati non si deve trovare nello stesso hosts che inizia i comandi FTP tramite connessione di controllo, tuttavia l’utente o il processo FTP-utente deve assicurare un “ascolto” sulla porta dati specificata. Si noti inoltre che la connessione dati potrebbe essere utilizzata contemporaneamente per l’invio e la ricezione. In una situazione diversa un utente potrebbe voler trasferire files tra due hosts, nessuno dei quali e’ un host locale. L’utente stabilisce quindi connessioni di controllo ai due servers, dopodiche’ organizza una connessione dati tra i due. In questa maniera, le informazioni di controllo vengono passate al PI-utente ma i dati trasferiti tra i DTPs- server. Cio’ che segue e’ un modello di tale interazione server-server. Controllo ------------ Controllo ---------->|FTP-Utente|<----------- | | PI-Utente| | | | "C" | | V ------------ V -------------- -------------- | FTP-Server | Connessione Dati | FTP_Server | | "A" |<---------------------->| "B" | -------------- Porta (A) Porta (B)-------------- Figura 2 Il protocollo richiede che le connessioni di controllo restino aperte mentre e’ in corso il trasferimento dei dati. E’ responsabilita’ dell’utente chiudere le connessioni di controllo quando ha terminato di usare il servizio FTP e il server prende il controllo. Il server potrebbe interrompere il trasferimento dati se le connessioni di controllo venissero chiuse senza comando. Relazione tra FTP e Telnet: L’FTP utilizza il protocollo Telnet durante la connessione di controllo. Questo puo’ essere realizzato in due modi: primo, il PI- utente o il PI-server possono direttamente implementare nelle loro procedure le regole del protocollo Telnet; secondo, il PI-utente o il PI-server possono fare uso del modulo Telnet gia’ presente nel sistema. Facilita’ d’implementazione, condivisione del codice e programmazione modulare fa optare per il secondo approccio. Efficienza ed indipendenza Postel & Reynolds [Page 10] RFC 959 October 1985 File Transfer Protocol Fanno invece optare per il primo. In pratica, l’FTP conta su una piccola parte del protocollo Telnet, e per tale motivo il primo approccio non implica generalmente una grande quantita’ di codice. 3. FUNZIONI DI TRASFERIMENTO DATI I files vengono trasferiti esclusivamente mediante la connessione dati. La connessione di controllo viene usata per il trasferimento dei comandi, che indicano le funzioni da compiersi, e per le risposte a tali comandi (vedasi la sezione relativa alle Risposte FTP). Per il trasferimento di dati tra hosts vengono chiamati in causa svariati comandi. Tali comandi di trasferimento dati comprendono il comando MODE, il quale specifica come devono essere trasmessi i bit di dati, e i comandi STRU (struttura) e TYPE, che vengono invece usati per definire la modalita’ nella quale devono essere rappresentati i dati. La trasmissione e la rappresentazione sono di base indipendenti, tuttavia la trasmissione in modalita’ “Stream” dipende dagli attributi di struttura file mentre se viene utilizzata quella “Compressed”, la natura del filler-byte (byte-riempitore) dipende dal tipo di rappresentazione. 3.1. RAPPRESENTAZIONE DEI DATI E MEMORIZZAZIONE I dati vengono trasferiti da un dispositivo di archiviazione presente sull’host mittente ad un dispositivo di archiviazione presente sull’hosts ricevente. Sovente e’ necessario effettuare alcune trasformazioni sui dati poiche’ la rappresentazione dei dati memorizzati puo’ essere diversa sui due sistemi. Ad esempio, l’NVT-ASCII ha dei sistemi di rappresentazione dei dati memorizzati diversi in sistemi differenti. Il DEC TOPS-20 solitamente archivia l’NVT-ASCII come cinque caratteri ASCII a 7-bit, in una parola a 36-bit con allineamento a sinistra. I mainframes IBM, invece, memorizzano l’NVT-ASCII come codice EBCDIC a 8-bit. Il Multics, ancora, archivia l’NVT-ASCII come quattro caratteri a 9-bit in una parola a 36- bit. E’ quindi desiderabile che i caratteri siano convertiti nello standard di rappresentazione NVT-ASCII quando del testo viene trasferito tra sistemi diversi. Le unita’ mittente e ricevente dovrebbero eseguire le trasformazioni necessarie per passare dallo standard di rappresentazione al loro sistema di rappresentazione interno [N.d.T.: e viceversa]. Un problema diverso relativo alla rappresentazione sorge quando vengono trasmessi dati binari (non codici di carattere) tra sistemi hosts con lunghezze word differenti. Non sempre e’ chiaro in che modo il mittente debba inviare i dati, e il ricevente memorizzarli. Ad esempio, quando vengono trasmessi bytes 32-bit da un sistema con lunghezza word 32-bit ad un sistema con lunghezza word 36-bit, sarebbe auspicabile (per ragioni di efficienza e pieno utilizzo) memorizzare i bytes 32-bit in una word 36-bit con allineamento a destra nell’ultimo sistema. In ogni caso l’utente dovrebbe avere la facolta’ di specificare la rappresentazione dei dati e le funzioni di trasformazione. Si tenga presente che l’FTP fornisce un Postel & Reynolds [Page 11] RFC 959 October 1985 File Transfer Protocol numero molto limitato di tipi di rappresentazione dati. Le trasformazioni desiderate al di sopra di questa capacita’ limitata dovrebbero essere eseguite direttamente dall’utente. 3.1.1. TIPI DI DATI Le rappresentazioni dei dati vengono gestite nell’FTP da un utente tramite la specificazione di un tipo di rappresentazione. Tale tipo puo’ implicitamente (come per l’ASCII o l’EBCDIC) o esplicitamente (come per byte Locali) definire una grandezza dei byte per l’interpretazione, alla quale ci si riferisce come “dimensione di byte logica”. Si tenga presente che questo non ha niente a che vedere con la dimensione dei byte usata per la trasmissione nella connessione dati, chiamata “dimensione di byte di trasferimento”, e queste due non devono essere confuse. Ad esempio, l’NVT-ASCII ha una dimensione di byte logica di 8 bits. Se il tipo e’ un byte Locale, il comando TYPE (tipo) deve avere un secondo parametro obbligatorio che specifichi la dimensioni dei byte logica. La dimensione di byte di trasferimento e’ sempre 8 bits. 3.1.1.1. TIPO ASCII E’ questo il tipo di default (predefinito) e dev’essere accettato da tutte le implementazioni FTP. Viene utilizzato fondamentalmente per il trasferimento di files di testo, a meno che entrambi gli hosts non ritengano piu’ conveniente l’uso del tipo EBCDIC. Il mittente converte i dati da una rappresentazione di caratteri interna allo standard di rappresentazione a 8-bit NVT-ASCII (vedasi la specifica Telnet). Il ricevente convertira’ invece i dati dallo standard alla sua forma interna. In conformita’ allo standard NVT, la sequenza [N.d.T.: Control Return + Line Feed] dev’essere usata qualora sia necessario marcare la fine di una linea di testo. (Vedasi la discussione sulla struttura dei file al termine della sezione sulla Rappresentazione e Memorizzazione dei Dati). L’utilizzo dello standard di rappresentazione NVT-ASCII significa che i dati devono essere interpretati come bytes a 8-bit. Il parametro Format (formato) per i tipi ASCII e EBCDIC viene discusso di seguito. Postel & Reynolds [Page 12] RFC 959 October 1985 File Transfer Protocol 3.1.1.2. TIPO EBCDIC Questo tipo viene usato per trasferimenti efficienti tra host che utilizzano l’EBCDIC per le loro rappresentazioni interne dei caratteri. Per la trasmissione i dati sono rappresentati come caratteri EBCDIC a 8-bit. Il codice dei caratteri e’ la sola differenza tra le specifiche funzionalita’ dell’EBCDIC e l’ASCII. L’end-of-line (in contrapposzione all’end-of-record – vedasi la discussione sulla struttura) sara’ probabilmente usato raramente con il tipo EBCDIC per ragioni di marcazione della struttura, ma qualora sia necessario viene usato il carattere . 3.1.1.3. TIPO IMAGE (immagine) I dati vengono inviati come bits contigui che, per il trasferimento, sono impacchettati in bytes di trasferimento a 8-bit. Il ricevente deve memorizzare i dati come bits contigui. La struttura del sistema di memorizzazione potrebbe aver bisogno di riempire il file (o ciascun record, per un file strutturato a record) con qualche contorno (byte, word o block). Tale riempimento, che dev’essere fatto tutto da zero, puo’ avvenire solamente alla fine del file (o di ciascun record) e vi dev’essere un modo per identificare i bits di riempimento cosi’ che questo possano essere buttati via se il file viene richiamato. La trasformazione di riempimento dev’essere ben evidente per consentire all’utente di processare un file nel posto ove viene immagazzinato. Il tipo Image e’ progettato per un’efficiente e recuperabile memorizzazione dei files e per il trasferimento di dati binari. E’ raccomandato che tale tipo sia accettato da tutte le implementazioni FTP. 3.1.1.4. TIPO LOCAL (locale) I dati vengono trasferiti in bytes logici della dimensione specificata dal secondo parametro obbligatorio, Byte size (dimensione byte). Il valore di Byte size dev’essere un intero decimale; non vi sono valori di default. La dimensione byte logica non e’ necessariamente uguale a quella trasferimento. Se sussite una differenza tra le due, quella logica dovra’ essere impacchettata in modo contiguo, senza tener conto dei byte di trasferimento ridondanti e con un qualsiasi riempimento alla fine. Postel & Reynolds [Page 13] RFC 959 October 1985 File Transfer Protocol Quando i dati raggiungono l’host di destinazione, questi saranno trasformati in una maniera dipendente dalla dimensione byte logica e dal particolare host. Tale trasformazione dev’essere invertibile (ad es., uno stesso file puo’ essere richiamato se vengono usati gli stessi parametri) e ben evidenziata dagli implementatori FTP. Per esempio, un utente che invia numeri in virgola mobile a 36-bit ad un host con word a 32-bit potrebbe inviare tali dati come byte Locali con dimensione byte logica di 36. L’host ricevente memorizza i bytes logici cosi’ che essi possano essere facilmente manipolati; in questo esempio, mettere i bytes logici a 36-bits in doppie words a 64-bit sarebbe sufficiente. In un altro esempio, una coppia di hosts con una dimensione word di 36-bit potrebbero inviare dati ad un altro host in word usando TYPE L 36. I dati verrebbero inviati in bytes di trasmissione a 8-bit impacchettati in modo che 9 bytes di trasmissione trasportino due words degli host. 3.1.1.5. CONTROLLO DEL FORMATO I tipi ASCII e EBCDIC utilizzano anche un secondo parametro (facoltativo); questo per indicare quale controllo del formato verticale, se c’e’, e’ associato con un file. I tipi di rappresentazione di dati che seguono sono definite nell’FTP: Un file di caratteri puo’ essere trasferito ad un host per tre ragioni: per la stampa, per l’archiviazione e il successivo recupero, o per la processazione. Se un file viene inviato per la stampa, il ricevente deve conoscere come viene rappresentato il controllo del formato verticale. Nel secondo caso, dev’essere possibile memorizzare il file nell’host e recuperarlo in seguito nell’esatta forma originale. Infine, dovrebbe essere possibile spostare un file da un host ad un altro e processarlo nel secondo host senza alcun tipo di problema. Un singolo formato ASCII o EBCDIC non soddisfa tutte queste condizioni. Ne consegue che questi tipi abbiano un secondo parametro che specifichi uno dei tre formati che seguono. 3.1.1.5.1. NON-PRINT Questo e’ il formato di default che viene usato se il secondo parametro (format) viene omesso. Il formato non-print dev’essere accettato da tutte le implementazioni FTP. Postel & Reynolds [Page 14] RFC 959 October 1985 File Transfer Protocol Il file non deve contenere alcuna informazione di formato verticale. Se viene passato ad un processo stampante tale processo potrebbe assumere valori standard per i margini e la spaziatura. Di norma, questo formato sara’ utilizzato con files destinati alla processazione o solamente all’archiviazione. 3.1.1.5.2. CONTROLLI DI FORMATO TELNET Il file contiene controlli di formato verticale ASCII/EBCDIC (come , , , , ) che il processo stampante interpretera’ in maniera appropriata. , esattamente in questa sequenza, marca inoltre la end-of-line (fine della riga). 3.1.1.5.3. CARRIAGE CONTROL (ASA) Il file contiene caratteri di controllo di formato verticale ASA (FORTRAN). (Vedasi l’RFC 740 Appendice C e le Comunicazioni dell’ACM, Vol. 7, N° 10, pag. 606, Ottibre 1964). In una riga o in un record formattati secondo lo Standard ASA, il primo carattere non dev’essere stampato. Al contrario, esso dev’essere usato per determinare il movimento verticale del foglio che deve prendere posizione prima che il resto del record venga stampato. Lo Standard ASA specifica i seguenti caratteri di controllo: Carattere Spaziatura Verticale blank Muove il foglio in su di una linea 0 Muove il foglio in su di due linee 1 Muove il foglio all’inizio della riga successiva + Nessun movimento, ad es. sovrastampa E’ chiaro che vi dev’essere un qualche modo perche’ un processo stampante possa distinguere la fine di un’entita’ strutturale. Se un file ha una struttura a record (vedasi piu’ avanti) non vi sono problemi; i records saranno esplicitamente marcati durante il trasferimento e la memorizzazione. Se il file invece non ha una struttura a record, la sequenza di end-of-line viene usata per separare le righe di stampa, but questi caratteri di formattazione vengono sovrascritti dai controlli ASA. Postel & Reynolds [Page 15] RFC 959 October 1985 File Transfer Protocol 3.1.2. STRUTTURE DATI In aggiunta ai differenti tipi di rappresentazione, l’FTP consente che sia specificata la struttura di un file. Nell’FTP sono definiti tre tipi di struttura: struttura-file, per la quale non vi e’ una struttura interna e il file viene considerato essere una sequenza continua di bytes di dati, struttura-record, per la quale il file e’ costituito da record in sequenza struttura-page, per la quale il file e’ costituito da indipendenti pagine indicizzate Se il comando STRUttura non viene utilizzato la struttura-file e’ quella presunta per default, ma sia la struttura-file che quella record devono essere accettate per files di “testo” (ad es., files con TYPE ASCII o EBCDIC) da tutte le implementazioni FTP. La struttura di un file interessa sia il modo di trasferimento di un file (vedasi la sezione sui Modi di Trasmissione) sia l’interpretazione e l’archiviazione di un file. La struttura “naturale” di un file dipendera’ dall’host che lo archiviera’. Un file codice-sorgente sara’ solitamente archiviato su mainframe IBM in record di lunghezza fissata ma su DEC TOPS-20 come flusso di caratteri partizionati in righe, mediante ad esempio i . Se risulta utile il trasferimento di files tra postazioni disparate vi dev’essere un modo affinche’ una postazione possa riconoscere i presupposti dell’altra riguardo al file. Con alcune postazioni orientate-a-file per natura e altre orientate-a- record vi possono essere problemi se un file con una struttura viene spedito ad un host orientato all’altra. Se un file di testo viene inviato con una struttura-a-record ad un host orientato-a-file, tale host deve eseguire una trasformazione interna sul file basato su una struttura a record. Ovviamente, tale trasformazione risulta utile ma dev’essere anche reversibile affinche’ uno stesso file possa essere richiamato mediante una struttura a record. Nel caso in cui un file sia inviato con struttura-file ad un host orientato-a-record, nasce la questione su quale criterio l’host debba usare per dividere il file in record affinche’ possa poi essere processato internamente. Se tale divisione e’ necessaria, le implementazioni FTP dovrebbero usare la sequenza end-of.line, Postel & Reynolds [Page 16] RFC 959 October 1985 File Transfer Protocol per ASCII, o per file di testo EBCDIC, come delimitatore. Se un’implementazione FTP adotta questa tecnica dev’essere in grado di eseguire la trasformazione al contrario qualora il file venga richiamato con struttura-a-file. 3.1.2.1. STRUTTURA-A-FILE La struttura-a-file e’ quella assunta per default se il comando STRUttura non viene utilizzato. In una struttura-a-file non esiste una struttura interna e il file viene considerato essere una sequenza continua di bytes di dati. 3.1.2.2. STRUTTURA-A-RECORD Le strutture-a-record devono essere accettate per file “di testo” (ad es., files con TYPE ASCII o EBCDIC) da tutte le implementazioni FTP. In una struttura-a-record il file e’ costituito da una sequenza di records. 3.1.2.3. STRUTTURA-A-PAGE Per trasmettere files discontinui l’FTP definisce una struttura-a- page (N.d.T.: a pagina). I files di tale categoria sono a volte conosciuti come “files ad accesso random (casuale)” oppure “holey files”. In tali files vi sono a volte altre informazioni associate al file intero (ad es., una descrizione del file) o ad una sezione del file (ad es., controlli di accesso alla pagina), o ad emtrambi. Nell’FTP le sezioni del file sono chiamate pages (pagine). Per fornire varie dimensioni di pagina e informazioni associate, ciascuna pagina viene spedita con un header (intestazione) di pagina. L’header di pagina contiene i seguenti campi definiti: Lunghezza dell’header Il numero di bytes logici nell’header di pagina compreso questo byte. La lunghezza minima dell’header e’ 4. Indice di pagina Il numero di pagine logiche di questa sezione del file. Questo non e’ il numero di pagina nella sequenza di trasmissione, ma l’indice usato per identificare questa pagina nel file. Postel & Reynolds [Page 17] RFC 959 October 1985 File Transfer Protocol Lunghezza dati Il numero di bytes logici nella pagina dati. La lunghezza minima di dati e’ 0. Tipo di pagina Il tipo di pagina. Sono definiti i seguenti tipi di pagina: 0 = ultima pagina Questo e’ usato per indicare la fine di una trasmissione strutturata a pagine. La lunghezza dell’header dev’essere 4 e la lunghezza dati 0. 1 = pagina semplice Questo e’ il tipo normale per semplici file impaginati senza nessuna informazione di controllo sul livello pagina associata. La lunghezza dell’header dev’essere 4. 2 = descrittore di pagina Questo tipo viene utilizzato per trasmettere informazioni descrittive relative ad un file nella sua interezza. 3 = pagina ad accesso controllato Questo tipo include un campo d’intestazione addizionale per i files impaginati con informazioni di controllo d’accesso a livello pagine. La lunghezza dell’header dev’essere 5. Campi opzionali Ulteriori campi header possono essere usati per fornire informazioni di controllo pagina, per esempio il controllo d’accesso pagina. Ogni campo e’ in lunghezza un byte logico. La dimensione di byte logica e’ specificata dal comando TYPE. Vedasi l’Appendice I per maggiori dettagli e una specifica casistica della struttura-a-page. Una nota d’attenzione sui parametri: un file dev’essere archiviato e recuperato con gli stessi parametri se la versione recuperata e’ identica Postel & Reynolds [Page 18] RFC 959 October 1985 File Transfer Protocol a quella originale trasmessa. Le implementazioni FTP deve ritornare un file identico all’originale se i parametri usati per l’archiviazione e il recupero sono gli stessi. 3.2. STABILIRE LA CONNESSIONE DATI Il meccanismo di trasferimento dati consiste nell’impostare la connessione dati sulla porta appropriata e nel scegliere i parametri di trasferimento. Sia il DTP-utente che quello server hanno una porta dati di default. La porta dati di default del proceso-utente e’ la stessa della porta della connessione di controllo. (ad es., U). La porta dati di default del processo-server e’ invece quella adiacente alla porta della connessione di controllo (ad es., L-1). La dimensione byte di trasferimento e’ di bytes a 8-bit. Tale dimensione ha importanza solamente nel trasferimento dei dati del momento; non ha importanza nella rappresentazione dei dati all’interno di un file system dell’host. Il processo di trasferimento dati passivo (che puo’ essere un DTP-utente o un secondo DTP-server) “ascoltera’” sulla porta dati prioritaria per inviare un comando di richiesta trasferimento. Il comando di richiesta FTP determina la direzione del trasferimento dati. Il server, ricevendo la richiesta di trasferimento, iniziera’ la connesione dati sulla porta. Quando la connessione e’ stabilita, il trasferimento dati inizia tra i DTP, e il PI-server invia una risposta di conferma al PI-utente. Ogni implementazione FTP deve supportare l’uso delle porte dati di default, e solamente il PI-UTENTE puo’ iniziare l’uso di porte non di default. E’ possibile per l’utente specificare l’uso di una porta dati alternativa tramite il comando PORT. L’utente potrebbe desiderare che un file sia fatto uscire su una linea stampante TAC o recuperato da un terzo host. In quest’ultimo caso, il PI-utente imposta connessioni di controllo con entrambi i PI-servers. Un server viene quindi chiamato (da un comando FTP) ad “ascoltare” una connessione che l’altro iniziera’. Il PI-utente invia ad uno dei PI-server un comando PORT per indicare la porta dati dell’altro. Alla fine, ad entrambi vengono inviati i comandi di trasferimento appropriati. L’esatta sequenza di comandi e risposte inviate dal controller-utente e dai servers e’ definita nella sezione relativa alle Risposte FTP. In linea generale, e’ responsabilita’ del server mantenere la connessione dati, inziarla e chiuderla. Un eccezione vien fatta quando il DTP-utente Postel & Reynolds [Page 19] RFC 959 October 1985 File Transfer Protocol sta inviando I dati in una modalita’ di trasferimento che richiede che la connessione venga chiusa dall’EOF indicato. Il server DEVE chiudere la connessione dati quando vi sono le seguente condizioni: 1. Il server ha completato l’invio di dati in una modalita’ di trasferimento che richiede una chiusura all’EOF indicato. 2. Il server riceve un comando ABORT dall’utente. 3. La porta specificata viene cambiata da un comando dell’utente. 4. La connessione di controllo viene chiusa legalmente o in altro modo. 5. Si verifica un errore irreversibile. Altrimenti la chiusura e’ opzione del server, per l’esercizio della quale il server deve indicare al processo-utente solamente una risposta 250 o 226. 3.3. GESTIONE DELLA CONNESSIONE DATI Porte di Connessione Dati di Default: tuttle le implementazioni FTP devono supportare l’uso delle porte di connessione dati di default, e solmanete il PI-utente puo’ iniziare l’uso di altre porte. Negoziazione di Porte Dati Non di Default: Il PI-utente puo’ specificare una porta dati lato utente non di default mediante il comando PORT. Il PI- utente puo’ richiedere al server di identificare una porta dati lato server tramite il comando PASV. Dal momento che una connessione viene definita da una coppia di indirizzi, ciascuna di queste azioni e’ sufficiente per ottenere una connessione dati differente, anche se e’ pure consentito usare entrambi i comandi per usare nuove porte su entrambi i lati della connessione dati. Riutilizzo della Connessione Dati: quando si utilizza la modalita’ di straferimento stream la fine del file dev’essere indicata nella chiusura della connessione. Questo comporta un problema se durante la sessione sono trasmessi files multipli, in quanto il TCP deve cosi’ mantenere il registro di connessione per un tempo superiore per garantire l’affidabilita’ della comunicazione. La connessione non puo’ cosi’ essere prontamente riaperta. A questo problema vi sono due soluzioni: la prima e’ la negoziazione di una porta non di default. La seconda e’ utilizzare un’altra modalita’ di trasferimento. Un commento sulle modalita’ di trasferimento. La modalita’ di Postel & Reynolds [Page 20] RFC 959 October 1985 File Transfer Protocol trasferimento stream e’ inerentemente inaffidabile, dal momento che non si puo’ determinare se la connessione viene chiusa prematuramente o meno. Le altre modalita’ di trasferimento (block, compressed) non terminano la connessione per indicare la fine del file. Esse hanno sufficiente codifica FTP perche’ la connessione dati possa essere analizzata per determinare la fine del file. In questo modo l’uso di queste modalita’ puo’ lasciare aperta la connessione dati per trasferimenti di files multipli. 3.4. MODALITA’ DI TRASMISSIONE La considerazione successiva sul trasferimento dei dati e’ la scelta dell’appropriata modalita’ di trasmissione. Esistono tre modalita’: una che formatta i dati e consente procedure di restart; una che inoltre comprime i dati per trasferimenti efficienti; e una che passa i dati con processazioni minime o nulle. In quest’ultimo caso la modalita’ interagisce con gli attributi di struttura per determinare il tipo di processazione. Nella modalita’ compressa, il tipo di rappresentazione determina il filler byte. Tutti i trasferimenti dati devono essere completati dalla chiusura della connessione dati con un end-of-file (EOF), il quale puo’ essere esplicitamente dichiarato o implicito. Per files con struttura-a-record, tutti i marcatori end-of-record (EOR) sono espliciti, compreso quello finale. Per files trasmessi in struttura-a-page viene usato un tipo di pagina “last-pasge” (ultima pagina). NOTA: Nella parte restante della presente sezione, byte significa “byte di trasferimento” tranne ove esplicitiamente dichiarato in altro modo. Affinche’ si possa creare uno standard di trasferimento, l’host mittente deve traslare le sue denotazioni interne di end-of-line o end-of-record nelle rappresentazioni prescritte dalla modalita’ di trasferimento e dalla struttura file, mentre quello ricevente dovra’ eseguire la traslazione inversa verso la sua denotazione interna. Il campo numero record in un mainframe IBM potrebbe non essere riconosciuto in un altro host, cosi’ l’informazione end-of-record puo’ essere trasferita come un codice di controllo di due byte in modalita’ stream o come un bit di flag nel descrittore in modalita’ block o compressed. La end-of-line in un file ASCII o EBCDIC senza struttura-a-record dovrebbe essere segnata da o , rispettivamente. Dal momento che tali trasformazioni comportano lavoro extra per taluni sistemi, sistemi identici che trasferiscono file di testo strutturati non a record potrebbero voler usare una rappresentazione binaria e una modalita’ stream per il trasferimento. Postel & Reynolds [Page 21] RFC 959 October 1985 File Transfer Protocol L’FTP definisce le seguenti modalita’ di trasmissione: 3.4.1. MODALITA’ STREAM (a flusso) I dati vengono trasmessi come un flusso di bytes. Non vi sono restrizioni sui tipi di rappresentazione utilizzati; sono consentite strutture-a-record. In un file strutturato-a-record l’EOR o l’EOF saranno ciascuno indicati da un codice di controllo di 2-byte. Per entrambi, il primo byte del codice di controllo sara’ il carattere escape. Il secondo byte avra’ attivo [N.d.T.: 1] il bit piu’ basso nell’ordine e zero nei restanti per EOR e il secondo bit piu’ basso nell’ordine attivo per EOF; quindi il byte avra’ valore 1 per EOR e 2 per EOF. L’EOR e l’EOF possono essere indicati insieme dall’ultimo byte trasmesso attivando entrambi i bit piu’ bassi nell’ordine (avendo cosi’ il valore 3). Se un byte tra tutti e’ stato concepito per essere inviato come dati, dovrebbe essere ripetuto nel secondo byte del codice di controllo. Se la struttura e’ una struttura-a-file, l’EOF viene indicato dall’host mittente mediante la chiusura della connessione dati e tutti i bytes sono bytes di dati. 3.4.2. MODALITA’ BLOCK (a blocco) Il file viene trasmesso in una serie di blocchi di dati preceduti da uno o piu’ bytes d’intestazione (headers). I bytes di intestazione contengono un campo numerico (di conteggio) e un codice di descrizione. Il campo numerico indica la lunghezza totale in bytes del blocco di dati, cosi’ da marcare l’inizio del successivo blocco di dati (non vi sono filler bits – bits di completamento). Il codice di descrizione definisce: l’ultimo blocco nel file (EOF) l’ultimo blocco nel record (EOR), l’indicatore di riavvio (vedasi la sezione sul Ripristino degli Errori e Riavvio) o dati sospetti (ad esempio se i dati trasferiti possono contenere errori e non sono affidabili). Quest’ultimo codice NON e’ concepito come controllo d’errore nell’FTP. Esso e’ concepito dal desiderio che alcune postazioni che interscambiano alcuni tipi di dati (ad es., sismici o metereologici) hanno di inviare e ricevere tutti i dati malgrado errori locali (come “errori di lettura di nastri magnetici”), per indicare nella trasmissione che alcune porzioni sono sospette. In questa modalita’ sono consentite strutture-a-record e puo’ essere utilizzata qualsiasi tipologia di rappresentazione. L’intestazione (header) e’ costituita da tre bytes. Dei 24 bits dell’header, i 16 piu’ bassi nell’ordine rappresentano il contatore di byte, mentre gli 8 bits superiori rappresentano i codici di descrizione, come mostrato qui sotto. Postel & Reynolds [Page 22] RFC 959 October 1985 File Transfer Protocol Intestazione del Blocco +----------------+----------------+----------------+ | Descrizione | Contatore di Bytes | | 8 bits | 16 bits | +----------------+----------------+----------------+ I codici di descrizione sono indicati da bits di flag [N.d.T.: flag=parametro, piu’ o meno..] nel byte di descrizione. Sono stati assegnati quattro codici numerici, ciascuno dei quali e’ il valore decimale del corrispondente bit nel byte. Codice Significato 128 La fine del blocco dati e’ l’EOR 64 La fine del blocco dati e’ l’EOF 32 Vi sono errori sospetti nel blocco dati 16 Il blocco dati e’ un indicatore di riavvio Con questa codifica, vi puo’ essere piu’ di una condizione descrittiva codificata per un particolare blocco. Possono essere attaccati (flagged) tanti bits quanti necessari. L’indicatore di riavvio viene incluso nel flusso di dati con un numero integrale di bytes a 8-bits rappresentante i caratteri stampabili nel linguaggio usato nella connessioni di controllo (ad es., per default, NVT-ASCII). (‘spazio’, nel linguaggio appropriato) non deve essere usato DENTRO un indicatore di riavvio. Ad esempio, per trasmettere un indicatore di sei-caratteri, dovrebbe essere spedito il seguente: +----------+----------+----------+ |Codice di | Contatore di byte | |descr.= 16| = 6 | +----------+----------+----------+ +----------+----------+----------+ |Indicatore|Indicatore|Indicatore| | 8 bits | 8 bits | 8 bits | +----------+----------+----------+ +----------+----------+----------+ |Indicatore|Indicatore|Indicatore| | 8 bits | 8 bits | 8 bits | +----------+----------+----------+ Postel & Reynolds [Page 23] RFC 959 October 1985 File Transfer Protocol 3.4.3. MODALITA’ COMPRESSED (compressa) Vi possono essere tre categorie di informazioni inviabili: dati normali, inviati in una stringa di byte; dati compressi, consistenti in repliche o riempimenti; infine informazioni di controllo, inviate in una sequenze escape di due-byte. Se vengono inviati n>0 bytes (fino a 127) di dati normali, questi n bytes sono preceduti da un byte con il bit piu’ a sinistra impostato su 0 e i 7 bit a destra conenenti il numero n. Stringa del byte: 1 7 8 8 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ |0| n | | d(1) | ... | d(n) | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ ^ ^ |---n bytes---| di dati Stringa di n bytes di dati d(1),..., d(n) Il contatore n dev’essere positivo Per comprimere una stringa di n ripetizioni del byte di dati d, vengono inviati i seguenti 2 bytes: Byte replicato: 2 6 8 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ |1 0| n | | d | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ Una stringa di n bytes di riempimento puo’ essere compresso in un singolo byte, dove il byte di riempimento varia a seconda del tipo di rappresentazione. Se il tipo e’ l’ASCII o l’EBCDIC il byte di riempimento (filler byte) e’ (Spazio, codice ASCII 32, codice EBCDIC 64). Se il tipo e’ Image (Immagine) o Byte locale il byte di riempimento e’ un byte zero. Stringa di riempimento: 2 6 +-+-+-+-+-+-+-+-+ |1 1| n | +-+-+-+-+-+-+-+-+ La sequenza di escape e’ un doppio byte, il primo dei quali e’ Postel & Reynolds [Page 24] RFC 959 October 1985 File Transfer Protocol Il byte escape (tutti zero) e il secondo contiene codici di descrizione come definiti nella modalita’ Block. I codici di descrizione assumono lo stesso significato come nella modalita’ Block e si applicazno alla stringa di bytes riuscita. La modalita’ Compressa e’ utile per ottenere un incremento di banda su notevoli trasmissioni di rete con un piccolo extracosto di CPU. Puo’ essere utilizzata molto efficacemente per ridurre la dimensione di file stampabili come quelli generati da hosts RJE. 3.5. RIPRISTINO DI ERRORI E RIAVVIO Non vi sono misure per il rilevamento di bits persi o mal ricevuti in un trasferimento dati; questo livello di controllo d’errore viene gestito dal TCP. Ad ogni modo, e’ prevista una procedura di riavvio per proteggere gli utenti da gravi guasti di sistema (compresi errori di un host, di un processo-FTP o di un sottolivello di rete). La procedura di riavvio viene definita solamente per le modalita’ di trasferimento dati Block e Compressa. Essa richiede che il mittente dei dati inserisca uno speciale codice marcatore nel flusso di dati con qualche informazione indicativa. L’informazione di demarcazione ha significato solamente per il mittente, ma deve consistere in caratteri stampabili nel linguaggio di defualt o negoziato della connessione di controllo (ASCII o EBCDIC). L’indicatore di demarcazione puo’ rappresentare un contatore-bit, un contatore-record o qualsiasi altra informazione attraverso la quale un sistema possa identificare un checkpoint (punto di verifica) di dati. Il ricevente, se implementa la procedura di riavvio, potrebbe allora voler marcare la posizione corrispondente di questo marcatore nel sistema ricevente, e ritornare tale informazione all’utente. Nell’evento di un insuccesso di sistema (failure), l’utente puo’ riavviare il trasferimento dei dati mediante l’identificazione dell’indicatore di demarcazione con la procedura FTP di riavvio. L’esempio che segue illustra l’uso della procedura di riavvio. Il mittente dei dati inserisce un appropriato marcatore nel flusso dei dati in un punto conveniente. L’host ricevente marca il corrispondente punto di dati nel suo file system e porta le informazioni sull’ultimo mittente conosciuto e il marcatore ricevente all’utente, direttamente o mediante la connessione di controllo in una risposta 110 (a seconda di chi sia il mittente). Con un insuccesso di sistema l’utente o il processo di controllo riavvia il server all’ultimo marcatore server inviando un comando restart (riavvio) con argomento il codice del marcatore server. Postel & Reynolds [Page 25] RFC 959 October 1985 File Transfer Protocol Il comando restart viene trasmesso tramite la connessione di controllo ed e’ seguito immediatamente dal comando che e’ stato eseguito quando e’ avvenuto l’intoppo del sistema (come RETR, STOR o LIST). 4. FUNZIONI DI TRASFERIMENTO FILE Il canale di comunicazione dal PI-utente al PI-server viene stabilito come un connessione TCP dall’utente alla porta standard del server. L’interprete di protocollo utente (PI-utente) e’ responsabile dell’invio dei comandi FTP e dell’interpretazione delle risposte ricevute; il PI-server interpreta i comandi, invia le risposte e dirige il proprio DTP a impostare la connessione dati e il trasferimento degli stessi. Se la seconda parte del trasferimento dati (il processo di trasferimento passivo) e’ il DTP-utente, esso viene governato attravero il protocollo interno dell’host dell’utente-FTP; se esso invece e’ un secondo DTP-server, viene governato dal proprio PI su comando del PI-utente. Le risposte FTP sono trattate nella sezione successiva. Nella descrizione di questa sezione di alcuni comandi, e’ di ausilio essere espliciti sulle possibile risposte. 4.1. COMANDI FTP 4.1.1. COMANDI DI CONTROLLO D’ACCESSO I comandi che seguono sono identificatori di controllo d’accesso (i comandi sono mostrati tra parentesi). NOME UTENTE (USER) Il campo d’argomento e’ una stringa Telnet che identifica l’utente. L’identificazione utente e’ richiesta dal server per accedere al suo file system. Questo comando e’ solitamente il primo che viene trasmesso dall’utente dopo che sono state effettuate le connessioni di controllo (alcuni servers possono richiederlo). Alcuni servers possono inoltre richiedere informazioni di identificazioni aggiuntive come una password e/o un comando account. I servers possono consentire che venga inserito un nuovo comando USER in qualsiasi punto in modo che sia cambiato il controllo d’accesso e/o le informazioni d’account. Questo ha l’effetto di resettare qualsiasi informazione utente, password e account gia’ fornite e iniziare una nuova sequenza di login. Tutti i parametri di trasferimento rimangono inalterati e qualsiasi trasferimento di file in corso viene completato sotto i vecchi parametri di controllo d’accesso. Postel & Reynolds [Page 26] RFC 959 October 1985 File Transfer Protocol PASSWORD (PASS) Il campo d’argomento e’ una stringa Telnet che indica la password dell’utente. Questo comando deve essere immediatamente preceduto dal comando USER e, per alcune postazioni, completa l’identificazione dell’utente per il controllo d’accesso. Dal momento che l’informazione password e’ pittusto delicata, e’ bene che venga “mascherata” o disabilitata la visibilita’ dell’output. Sembra che il server non abbia un metodo infallibire per compiere tale operazione. E’ percio’ responsabilita’ del processo FTP-utente nascondere la delicata informazione password. ACCOUNT (ACCT) Il campo d’argomento e’ una stringa Telnet che identifica l’account dell’utente. Il comando non e’ necessariamente correlato al comando USER, e alcune postazioni potrebbero richiedere un account per il login e altri esclusivi per specifici accessi, come l’archiviazione di files. In quest’ultimo caso il comando puo’ arrivare in qualsiasi momento. Vi sono codici di risposta per differenziare queste casistiche per l’automazione: quando un’informazione account viene richiesta per il login, la risposta ad un comando PASSword avvenuto con successo e’ il codice 332. Dal verso opposto, se un’informazione account NON e’ richiesta per il login, la risposta ad un positivo comando PASS e’ la 230; e se un’informazione account e’ necessaria per un comando fornito nel dialogo in seguito, il server dovrebbe ritornare una risposta 332 o 532 a seconda che accetti o rifiuti il comando, rispettivamente. CAMBIARE LA CARTELLA DI LAVORO (CWD) Questo comando consente all’utente di lavorare con una directory o dataset differente per l’archiviazione o il recupero di file senza alterare le sue informazioni di login o d’account. I parametri di trasferimento sono allo stesso modo inalterati. L’argomento e’ un percorso che specifica una directory o un altro sistema di raggruppamento di files. PORTARSI ALLA CARTELLA SUPERIORE (CDUP) Questo comando e’ un caso speciale di CWD ed e’ incluso per semplificare l’implementazione di programmi per il trasferimento di alberi di directory tra sistemi operativi che hanno sintassi Postel & Reynolds [Page 27] RFC 959 October 1985 File Transfer Protocol differente per il richiamo delle cartelle superiori. I codici di risposta sono identici a quelli per il CWD. Vedasi l’Appendice II per maggiori dettagli. MONTARE UNA STRUTTURA (SMNT) Questo comando consente all’utente di montare una struttura dati file system diversa senza modificare le sue informazioni di login o di account. I parametri di trasferimento sono allo stesso modo inalterati. L’argomento e’ un percorso che specifica una cartella o un altro sistema di raggruppamento di files. REINIZIALIZZARE (REIN) Questo comando termina uno USER, resettando tutte le informazioni di I/O [N.d.T.: Input/Output] e d’account, ad esculsione di qualsiasi trasferimento ancora in corso che dev’essere completato. Tutti i parametri vengono resettati alle impostazioni di default (predefinite) e viene lasciata aperta la connessione di controllo. Questo stato e’ identico a quello in cui si trova un utente subito dopo che la connessione di controllo viene aperta. Ci si puo’ aspettare ora un comando USER. LOGOUT (QUIT) Questo comando termina un USER e, se non vi e’ in corso un trasferimento di files, il server chiude la connessione di controllo. Se vi e’ un trasferimento in corso, la connessione rimarra’ aperta per risposte conseguenti e poi verra’ terminata. Se il processo-utente sta trasferendo files per diversi utenti e non desidera che la connessione venga chiusa e che vengano poi riaperte connessioni per ciascuno di loro, sara’ bene usare il comando REIN anziche’ il comando QUIT. Una terminazione inaspettata della connessione di controllo comportera’ un effettivo ABORT e logout (QUIT) da parte del server. 4.1.2. COMANDI CHE SPECIFICANO I PARAMETRI DI TRASFERIMENTO Tutti i parametri per il trasferimento dei dati hanno valori di default (predefiniti), ed e’ richiesto che i comandi specifichino i parametri di trasferimento dati solamente se questi sono diversi da quelli di default. Il valore di default e’ l’ultimo valore specificato o, se non specificato, il valore standard qui riportato. Questo implica che il server deve “ricordare” i valori di default applicabili. I comandi possono trovarsi in un qualsiasi ordine, ad esclusioni di quelli che devono precedere una richiesta di servizio FTP. I comandi che seguono specificano i parametri di trasferimento dati: Postel & Reynolds [Page 28] RFC 959 October 1985 File Transfer Protocol PORTA DATI (PORT) L’argomento e’ una specificazione della PORTA-HOST che dev’essere usata come porta dati nella connessione dati. Vi sono valori di default sia per la porta dati utente che server, e in circostanze normali questo comando e la sua risposta non sono necessari. Se tale comando viene utilizzato, l’argomento e’ una concatenazione indirizzi host internet a 32-bit e un indirizzo di porta TCP a 16- bit. Queste informazioni di indirizzo sono fatte scaturire in un campo a 8-bit e il valore di ciacun campo viene trasmesso come un numero decimale (in stringa di rappresentazione dei caratteri). I campi sono separati da virgole. Un comando port potrebbe essere: PORT h1,h2,h3,h4,p1,p2 dove h1 e’ l’8-bits piu’ alto nell’ordine dell’indirizzo internet host. PASSIVO (PASV) Questo comando richiede al DTP-server di “ascoltare” su una porta dati (che non e’ quella di default) e attendere per una connessione anziche’ iniziarne una appena ricevuto un comando di trasferimento. La risposta a tale comando include l’host e l’indirizzo di porta sul quale sta ascoltando questo server. TIPO DI RAPPRESENTAZIONE (TYPE) L’argomento specifica il tipo di rappresentazione come descritto nella sezione relativa all’Archiviazione e Rappresentazione dei Dati. Diversi tipi hanno un secondo parametro. Il primo parametro e’ evidenziato da un singolo carattere Telnet, come e’ il secondo parametro di Formato per ASCII ed EBCDIC; il secondo parametro per byte locale e’ un intero decimale per indicare la dimensione-byte. I parametri sono separati da un (Spazio, codice ASCII 32). Per il tipo di rappresentazione sono assegnati i seguenti codici: \ / A - ASCII | | N - Non-print |-><-| T - Telnet format effectors E - EBCDIC| | C - Carriage Control (ASA) / \ I - Image L - dimensione byte per Byte Locale Postel & Reynolds [Page 29] RFC 959 October 1985 File Transfer Protocol Il tipo di rappresentazione di default e’ l’ASCII Non-print. Se il parametro di Formato viene modificato, e poi viene modificato solamente il primo argomento, il Formato torna quindi al Non-print di default. STRUTTURA DEL FILE (STRU) L’argomento e’ un singolo codice di carattere Telnet che specifica la struttura del file descritta nella sezione sull’Archiviazione e Rappresentazione dei Dati. Per la struttura sono assegnati i seguenti codici: F - File (non struttura-a-record) R – Struttura-a-record P – Struttura-a-pagina (page) La struttura di default e’ File. MODALITA’ DI TRASFERIMENTO (MODE) L’argomento e’ un singolo codice di carattere Telnet che specifica le modalita’ di trasferimento file descritta nella sezione sulle Modalita’ di Trasferimento. Per le modalita’ di trasferimento sono assegnati i seguenti codici: S – Stream (flusso) B – Block (a blocco) C – Compressed (compressa) La modalita’ di trasferimento di default e’ la Stream. 4.1.3. COMANDI DI SERVIZIO FTP I comandi di servizio FTP definiscono il trasferimento del file o le funzioni di file system richieste dall’utente. L’argomento di un comando di servizio FTP e’ di norma un pathname (percorso). La sintassi del pathname dev’essere conforme alle convenzioni della postazione server (con gli applicabili defaults standard) e alle convenzioni di linguaggio della connessione di controllo. L’utilizzo dei default suggeriti e’ usare l’ultimo dispositivo, directory o nome-file specificato o lo standard di default definito per utenti locali. I comandi possono trovarsi in un ordine qualsiasi tranne per il comando “rename from” (rinomina da) che dev’essere seguito da un “rename to” (rinomina a) e per il comando restart che dev’essere seguito dal comando che ha interrotto il servizio (ad es., STOR o RETR). I dati, quando trasferiti in risposta a comandi di servizio FTP, saranno Postel & Reynolds [Page 30] RFC 959 October 1985 File Transfer Protocol sempre inviati sulla connessione dati, tranne che per alcune risposte informative. I comandi che seguono specificano richieste di servizio FTP: RECUPERO (RETR) Questo comando fa si’ che il DTP-server trasferisca una copia del file, specificato nel percorso [N.d.T.:comprensivo di nome file] al DTP-server o user sull’altro lato della connessione dati. Lo stato e i contenuti del file sul server saranno inalterati. ARCHIVIAZIONE (STOR) Questo comando fa si’ che il DTP-server accetti i dati trasferiti mediante la connessione dati e li memorizzi come file sul server. Se il file specificato nel percorso esiste sul server il suo contenuto sara’ sostituito dai dati trasferiti. Se invece non esiste, verra’ creato un nuovo file sul server. ARCHIVIAZIONE UNIVOCA (STOU) Questo comando si comporta come lo STOR tranne per il fatto che il file risultante dev’essere creato nella directory corrente sotto un nome univoco per quella cartella. La risposta 250 Trasferimento Iniziato deve includere il nome generato. ARCHIVIAZIONE IN CODA (con creazione) (APPE) Questo comando fa si’ che il DTP-server accetti i dati trasferiti mediante la connessione dati e li memorizzi in un file sul server. Se il file specificato nel percorso esiste sul server i dati verranno accodati a quel file; in caso contrario il file specificato sara’ creato sul server. ALLOCAZIONE (ALLO) Questo comando puo’ essere richiesto da alcuni servers per riservare sufficiente spazio di archiviazione per accomodare il nuovo file che viene trasferito. L’argomento sara’ un intero decimale che rappresenta il numero di bytes (usando la dimensione dei bytes logica) d’archiviazione che devono essere riservati per il file. Per file inviati con strutture a-record o a-page puo’ essere necessaria anche una dimensione massima di record o pagina (in bytes logici); questa viene indicata da un intero decimale in un secondo campo Postel & Reynolds [Page 31] RFC 959 October 1985 File Transfer Protocol d’argomento del comando. Il secondo argomento e’ facoltativo, ma se presente dev’essere separato dal primo tramite i tre caratteri Telnet R . Questo comando sara’ seguito da un comando STOR (archivia) o APP (archivia in coda). Il comando ALLO dev’essere gestito come un NOOP (nessuna operazione) da quei servers che non richiedono che la dimensione massima del file sia dichiarata in anticipo, and those servers interested in only the maximum record or page size should accept a dummy value in the first argument and ignore it. RIAVVIO (REST) Il campo d’argomento rappresenta il marcatore server dal quale il trasferimento del file dev’essere riavviato. Questo comando non comporta il trasferimento del file ma scavalca il file allo specificato checkpoint dati. Tale comando sara’ immediatamente seguito da un appropriato comando di servizio FTP che comportere’ il resume (ripresa) del trasferimento del file. RINOMINA DA (RNFR) Questo comando specifica il vecchio pathname del file che dev’essere rinominato. Tale comando dev’essere immediatamente seguito da un comando “rinomina in” che specifica il nuovo pathname del file. RINOMINA IN (RNTO) Questo comando specifica il nuovo pathname del file specificato nel comando “rinomina da” immediatamente precedente. Insieme i due comandi fanno si’ che un file sia rinominato. TERMINAZIONE (ABOR) Questo comando dice al server di terminare il precedente comando di servizio FTP e qualsiasi trasferimento di dati associato. Il comando di terminazione puo’ richiedere una “speciale azione”, come discusso nella sezione sui Comandi FTP, che forzi il riconoscimento dal server. Nessuna azione dev’essere eseguita se il comando precedente e’ stato completato (compreso il trasferimento di dati). La connessione di controllo non dev’essere chiusa dal server, ma quella dati si. Vi sono due casi per il server, una volta ricevuto questo comando: (1) il comando di servizio FTP era gia’ stato completato oppure (2) il comando di servizio FTP e’ ancora in corso. Postel & Reynolds [Page 32] RFC 959 October 1985 File Transfer Protocol Nel primo caso, il server chiude la connessione dati (se aperta) e risponde con una risposta 226, a indicare che il comando ABOR e’ stato processato con successo. Nel secondo caso, il server termina il servizio FTP in corso e chiude la connessione dati, ritornando una risposta 426 per indicare che il servizio richiesto e’ terminato in maniera anomala. Il server invia quindi una risposta 226 per indicare che il comando ABOR e’ stato processato con successo. CANCELLARE (DELE) Questo comando fa si’ che il file specificato nel pathname sia cancellato sul server. Se e’ desiderabile un extra livello di protezione (come la richiesta “Vuoi veramente cancellare il file?”) esso dev’essere fornito dal processo FTP-utente. RIMUOVERE UNA CARTELLA (RMD) Questo comando fa si’ che la cartella specificata nel pathname sia rimossa come directory (se il pathname e’ assoluto) o come sottodirectory della directory di lavoro corrente (se il pathname e’ relativo). Vedasi Appendice II. CREA CARTELLA (MKD) Questo comando fa si’ che la directory specificata nel pathname sia creata come cartella (se il pathname e’ assoluto) o come sottocartella della cartella di lavoro corrente (se il pathname e’ relativo). Vedasi Appendice II. RITORNA LA CARTELLA DI LAVORO (PWD) Questo comando fa si’ che il nome della cartella di lavoro corrente sia ritornato in risposta. Vedasi Appendice II. ELENCA (LIST) Questo comando fa si’ che un elenco sia inviato da un server ad un DTP passivo. Se il pathname specifica una directory o un altro gruppo di files, il server dovrebbe trasferire una lista di files nella cartella specificata. Se il pathname specifica un file il server dovrebbe inviare le attuali informazioni relative al file. Un argomento nullo sottintende la directory di lavoro corrente o quella di default dell’utente. Il trasferimento dei dati avviene mediante la connesione dati secondo il tipo ASCII o EBCDIC. (L’utente deve Postel & Reynolds [Page 33] RFC 959 October 1985 File Transfer Protocol assicurarsi che il TYPE sia appropriatamente ASCII o EBCDIC). Poiche’ le informazioni su un file possono ampiamente variare da sistema a sistema, tali informazioni possono essere difficilmente usate automaticamente da un programma, tuttavia possono risultare piuttosto utile per un utente umano. ELENCA NOMI (NLST) Questo comando fa si’ che una directory sia listata e sia spedita da un server alla postazione utente. Il pathname dovrebbe specificare una directory o un altro gruppo di file specifico di sistema; un argomento nullo sottintende la cartella corrente. Il server tornera’ un elenco di nomi di files e nessun’altra informazione. I data verranno trasferiti in tipo ASCII o EBCDIC tramite la connessione dati come stringhe pathname valide separate da o . (Anche in questo caso l’utente deve assicurarsi che il TYPE sia corretto). Questo comando e’ concepito per ritornare informazioni che possono essere utilizzate da un programma per elaborare ulteriormente i files automaticamente. Ad esempio, per l’implementazione di una funzione “multiple get”. PARAMETRI DI POSTAZIONE (SITE) Questo comando viene usato dal server per fornire specifici servizi al proprio sistema, i quali sono essenziali per il trasferimento di file ma non sufficientemente universali per essere inclusi come comandi nel protocollo. La natura di tali servizi e la specifica della loro sintassi viene postata in risposta al comando HELP SITE. SISTEMA (SYST) Questo comando viene usato per conoscere il tipo di sistema operativo che gira sul server. La risposta avra’ nel suo primo termine uno dei nomi di sistema elencati nell’attuale versione del documento dei Numeri Assegnati [4]. STATO (STAT) Questo comando fa si’ che una risposta di stato sia inviata mediante la connessione di controllo sotto forma di risposta. Il comando puo’ essere inviato durante un trasferimento di file nel qual caso il server rispondera’ con lo stato dell’operazione in corso, oppure puo’ essere inviato tra trasferimenti di files. In quest’ultimo caso il comando dovrebbe avere un campo d’argomento. Se l’argomento e’ un pathname (percorso) il comando diventa analogo al comando “list” tranne il fatto che i dati saranno inviati sulla connessione di Postel & Reynolds [Page 34] RFC 959 October 1985 File Transfer Protocol controllo. Se viene dato un pathname parziale, il server risponde con un elenco di nomi di file o attributi associati a quanto specificato. Se non viene dato alcun argomento il server ritorna delle informazioni di stato generiche relative al processo FTP- server. Queste possono includere i valori correnti di tutti i parametri di trasferimento e lo stato delle connessioni. AIUTO (HELP) Questo comando fa si’ che il server invii all’utente informazioni utili relative al suo stato di implementazione, tramite la connessione di controllo. Il comando puo’ essere accompagnato da un argomento (ad es., il nome di un qualsiasi comando) e verranno ritornate in risposta informazioni piu’ specifiche. La risposta e’ un tipo 211 o 214. Si consiglia che il comando HELP sia inviabile anche prima di un comando USER. Il server puo’ utilizzare questa risposta per specificare i propri parametri di postazione, in risposta ad un HELP SITE. NESSUNA OPERAZIONE (NOOP) Questo comando non ha effetto su alcun parametro o comando inviato in precedenza. Esso non richiede nessun’altra azione che l’invio dal server di una risposta OK. Il Protocollo di Trasferimento File (FTP) segue le specifiche del protocollo Telnet per tutte le comunicazioni sulla connessione di controllo. Poiche’ il linguaggio usato per comunicazioni Telnet puo’ essere un opzione negoziata, tutti i riferimenti nelle seguenti due sezioni saranno al “linguaggio Telnet” e al corrispondente “codice end-of-line Telnet”. Attualmente, questo significa NVT-ASCII e . Nessun’altra specifica al protocollo Telnet verra’ citata. I comandi FTP sono “stringhe Telnet” terminate dal “codice di EOL Telnet”. I codici di comando stessi sono caratteri alfabetici terminati dal carattere (spazio) se seguono parametri o altrimenti EOL-Telnet. I codici di comando e la relativa semantica vengono descritti in questa sezione; la sintassi dettagliata dei comandi viene specificata nella sezione sui Comandi, mentre le sequenze di risposta sono discusse nella sezione sulle Sequenze dei Comandi e Risposte, infine alcuni esempi sull’uso dei comandi si trovano nella sezione sugli Scenari FTP Tipici. I comandi FTP possono essere suddivisi in identificatori di controllo d’accesso, parametri di trasferimento dati o richieste di servizio FTP. Alcuni comandi (come ABOR, STAT, QUIT) possono essere inviati tramite la connessione di controllo mentre un trasferimento di dati e’ in corso. Postel & Reynolds [Page 35] RFC 959 October 1985 File Transfer Protocol Alcuni server possono non essere in grado di monitorare simultaneamente le connessioni dati e di controllo, e in questo caso sono necessarie alcune azioni speciali per ottenere l’attenzione del server. La seguente scaletta e’ raccomandata a titolo di prova: 1. Il sistema utente inserisce il segnale Telnet di ”Interrupt Process – Processo d’Interruzione” (IP) nel flusso Telnet. 2. Il sistema utente invia il segnale Telnet “Synch”. 3. Il sistema utente inserisce il comando (ad es., ABOR) nel flusso Telnet. 4. Il PI-server, dopo aver ricevuto l’”IP”, scansiona il flusso Telnet per trovare ESATTAMENTE UN comando FTP. (Per altri servers questo puo’ non essere necessario ma le azioni sopra elencate non dovrebbero avere strani effetti). 4.2. RISPOSTE FTP Le risposte ai comandi FTP sono implementate per assicurare la sincronizzazione di richieste ed azioni nel processo di trasferimento di file, e per garantire che il processo utente conosca sempre lo stato del server. Ogni comando deve generare almeno una risposta, sebbene ve ne possano essere piu’ di una; in quest’ultimo caso, le risposte devono essere facilmente distinte. In piu’, alcuni comandi devono verificarsi in gruppi sequenziali, come USER, PASS e ACCT, oppure RNFR e RNTO. Le risposte mostrano l’esistenza di uno stato intermedio se tutti i comandi precedenti hanno avuto successo. Un insuccesso (failure) in un qualsiasi punto nella sequenza necesita la ripetizione dall’inizio dell’intera sequenza. I dettagli delle sequenze comando-risposta sono resi espliciti nell’insieme di diagrammi di stato piu’ avanti. Una risposta FTP consiste in un numero di 3 cifre (trasmesso nella forma di tre caratteri alfanumerici) seguito da del testo. Il numero e’ implementato per l’uso da parte di automazioni per determinare cosa dev’essere inviato di seguito; il testo server invece all’utente umano. E’ concepito che le tre cifre contengano informazioni codificate sufficienti perche’ il processo-utente (il PI-utente) non debba aver bisogno di esamire il testo e possa abbandonarlo o passarlo all’utente, come piu’ appropriato. In particolare, il testo puo’ essere server-dipendente, e puo’ cosi’ variare per uno stesso codice di risposta. Una risposta e’ definita per contenere il codice a 3-cifre, seguito da Postel & Reynolds [Page 36] RFC 959 October 1985 File Transfer Protocol uno spazio , seguito da una linea di testo (per cui e’ stata specificata una lunghezza massima) e terminato dal codice di end-of-line Telnet. Vi saranno casi, tuttavia, in cui il testo sara’ piu’ lungo di una singola linea. In questi casi il testo completo dev’essere inquadrato in modo che il processo-utente sappia deve terminare la lettura della risposta (ad es., un input di termine processazione sulla connessione di controllo) e fare qualcosa d’altro. Questo richiede che la prima linea abbia un formato speciale che indichi che stanno per arrivare piu’ di una linea, cosi’ l’ultima per indicare che e’ l’ultima linea. Almeno una di queste linee deve contenere l’appropriato codice di risposta per indicare lo stato della transazione. Per soddisfare tutti, e’ stato deciso che sia il primo che l’ultimo codice di linea sia lo stesso. Il formato per risposte multi-linea deve quindi inizia con l’esatto codice di risposta all’inizio della prima linea, seguito immediatamente da un trattino “-“ e seguito poi dal testo. L’ultima linea dovra’ iniziare con lo stesso codice, seguito immediatamente dallo spazio , dal testo (facoltativo) e dall’end-of-line Telnet. Esempio: 123-Prima linea Seconda linea 234 Una linea che inizia con dei numeri 123 Ultima linea Il processo-utente dovra’ quindi cercare semplicemente il codice di risposta ripetuto per la seconda volta seguito da (spazio) all’inizio di una linea ed ignorare tutte le linee intermedie. Se una delle linee intermedie inizia con un numero di 3 cifre il server deve riempire la parte anteriore per evitare confusione. Il presente schema consente che siano usate procedure di sistema standard per informazioni di risposta (come ad esempio per la risposta STAT), con la prima e l’ultima linea “artificiale” viste sopra. In casi piu’ rari, quando tali routines sono in grado di generare tre cifre e uno spazio all’inizio di una qualsiasi linea, l’inizio di ciascuna linea di testo dovrebbe essere distinta da del testo neutrale, come uno spazio. Questo schema presuppone che non vengano annidate risposte multi-linea. Le tre cifre di una risposta hanno tutte un significato particolare. Questo e’ voluto per consentire al processo-utente un range molto semplice di risposte molto sofisticate. La prima cifra indica se la risposta e’ buona, non buona o incompleta (riferirsi al diagramma di condizione), un processo-utente non sofisticato sara’ in grado di determinare la sua prossima azione (procedere come pianificato, rifare, ecc.) Postel & Reynolds [Page 37] RFC 959 October 1985 File Transfer Protocol semplicemente esaminando la prima cifra. Un processo-utente che desideri conoscere approssimativamente la sorta d’errore verificatosi (ad esempio, errore nel file system, errori di sintassi del comando, ecc.) puo’ esaminare la seconda cifra, infine la terza cifra esplicita informazioni maggiori (ad esempio, un comando RNTO senza un precedente RFNR). Per la prima cifra di un codice di risposta vi sono cinque valori: 1yz Risposta positiva preliminare L’azione richiesta sta per essere iniziata; e’ attesa un’altra risposta prima che si possa procedere con un nuovo comando. (Il processo-utente che invia un altro comando prima che della risposta di completamento viola il protocollo; ad ogni modo i processi FTP-server dovrebbero mettere in coda qualsiasi comando che arrivi mentre un comando precedente e’ in corso). Questo tipo di risposta puo’ essere usata per indicare che il comando e’ stato accettato e il processo-utente puo’ ora porre attenzione sulle connessioni dati, per quelle implementazioni dove e’ difficoltoso il monitoraggio simultaneo. Il processo FTP-server puo’ inviare al massimo una risposta 1yz per comando. 2yz Risposta positiva di completamento L’azione richiesta e’ stata completata con successo. Una nuova richiesta puo’ essere inviata. 3yz Risposta positiva intermedia Il comando e’ stato accettato, ma l’azione richiesta e’ tenuta in sospeso, nell’attesa di ulteriori informazioni. L’utente dovrebbe inviare un altro comando che specifichi tali informazioni. Questa risposta viene usata con i gruppi di comandi in sequenza. 4yz Risposta negativa transitoria di completamento Il comando non e’ stato accettato e l’azione richiesta non e’ andata a buon fine, ma la condizione di errore e’ temporanea e l’azione puo’ essere richiesta nuovamente. L’utente dovrebbe reinserire la sequenza di comando dall’inizio, se c’e’. E’ difficile dare significato al termine “transitorio”, in particolar modo quando due postazioni distinte (i processi – server e –utente) devono trovarsi in accordo sull’interpretazione. Ciascuna risposta della categoria 4yz puo’ avere allo stesso tempo piu’ significati diversi, ma lo scopo principale e’ che il processo-utente sia incoraggiato a riprovare Postel & Reynolds [Page 38] RFC 959 October 1985 File Transfer Protocol nuovamente. Una regola pratica nella determinazione se una risposta rientra nella 4yz o nella 5yz (negativa permanente) categoria e’ che le risposte sono della 4yz se i comandi possono essere ripetuti senza alcuna modifica nella forma del comando o nelle proprieta’ dell’Utente o del Server (ad esempio il comando viene analizzato allo stesso modo con gli stessi argomenti utilizzati; l’utente non modifica il suo accesso o il suo nome utente; il server non mette su una nuova esecuzione). 5yz Risposta negativa permanente di completamento Il comando non e’ stato accettato e l’azione richiesta non e’ andata a termine. Il processo-utente e’ scoraggiato dal ripetere la richiesta esattamente allo stesso modo (nella stessa sequenza). Alcune condizioni di errore “permanente” possono anche essere corrette, in modo che l’utente umano possa voler dirigere il suo processo-utente a reiniziare la sequenza di comando mediante un’azione diretta in qualche punto in futuro (ad es., dopo che l’ortografia e’ stata modificata, o l’utente ha alterato il suo directory status). I raggruppamenti di funzione che seguono si trovano nella seconda cifra: x0z Sintassi - Queste risposte si riferiscono ad errori di sintassi, comandi sintatticamente corretti che non rientrano in alcuna categoria funzionale, oppure comandi superflui o non implementati. x1z Informazione - Sono queste risposte a richieste di informazioni, come status o help. x2z Connessioni - Risposte riferite alle connessioni dati e di controllo. x3z Autenticazione ed account – Risposte per il processo di login e le procedure di account. x4z Non ancora specificato. x5z File system - Queste risposte indicano lo stato del file system Server di fronte al trasferimento o altra azione file system richiesti. La terza cifra raffina il significato di ciascuna categoria di funzione, specificato dalla seconda cifra. Questo viene illustrato dall’elenco delle risposte riportato piu’ avanti. Si noti che il testo Postel & Reynolds [Page 39] RFC 959 October 1985 File Transfer Protocol associato a ciascuna risposta e’ raccomandato, piu’ che obbligatorio, e puo’ essere modificato a seconda del comando al quale e’ associato. I codici di risposta, invece, devono seguire alla lettera le specifiche postate nell’ultima sezione; per questo, le implementazioni server non devono inventare nuovi codici per situazioni leggermente diverse da quelle qui descritte, ma accettare i codici gia’ definiti. Un comando come TYPE o ALLO le cui esecuzioni avvenute con successo non offrono alcuna nuova informazione al processo-utente faranno si’ che sia tornata una risposta 200. Se un comando non e’ implementato da un particolare processo Server-FTP perche’ non ha rilevanza in quel sistema, come ad esempio ALLO in una postazione TOPS-20, una risposta Positiva di Completamento e’ tuttavia desiderata in modo che il processo-utente sappia che puo’ procedere con altre azioni. Una risposta 202 viene usata in questo caso con, ad esempio, il testo: “Nessuna allocazione necessaria”. Se, d’altro canto, il comando richiede un’azione non-specifica-di-postazione e non e’ implementato, la risposta e’ la 502. Un perfezionamento di quello e’ una risposta 504 per un comando che e’ implementato, ma che richiede un parametro non implementato. 4.2.1 Codici di risposta per Gruppi di Funzione 200 Comando valido. 500 Errore di sintassi, comando non riconosciuto. Questo puo’ comprendere errori quali ad esempio linea di comando troppo lunga. 501 Errore di sintassi nei parametri o negli argomenti 202 Comando non implementato, superfluo in questa postazione. 502 Comando non implementato. 503 Sequenza di comandi errata. 504 Comando non implementato per quel parametro. Postel & Reynolds [Page 40] RFC 959 October 1985 File Transfer Protocol 110 Risposta di identificazione di un riavvio. In questo caso, il testo e’ esatto e non lasciato a particolari implementazioni; dev’essere: MARK yyyy = mmmm dove yyyy e’ l’identificatore del flusso di dati del processo- utente, e mmmm e’ l’equivalente del server (si notino gli spazi tra gli identificatori e “=”). 211 Stato del sistema o risposta d’aiuto di sistema. 212 Stato della directory. 213 Stato del file. 214 Messaggio d’aiuto. Su come utilizzare il server o sul significato di un particolare comando non-standard. Tale risposta e’ utile solamente per un utente umano. 215 Tipo di NOME (NAME) di sistema. dove NAME e’ un sistema di nomenclatura di sistema ufficiale contenuto nell’elenco presente nel documento dei Numeri Assegnati. 120 Servizio pronto in nnn minuti. 220 Servizio pronto per un nuovo utente. 221 Il servizio sta per chiudere la connessione di controllo. Logout se necessario. 421 Servizio non disponibile, in chiusura la connessione di controllo. Questa risposta puo’ essere per un qualsiasi comando, se il servizio sa che deve eseguire lo shut down. 125 Connessione dati gia’ aperta, inizio trasferimento. 225 Connessione dati aperta, nessun trasferimento in corso. 425 Impossibile aprire la connessione dati. 226 In chiusura la connessione dati. L’azione sul file richiesta ha avuto successo (ad esempio, trasferimento di un file) 426 Connessione chiusa, trasferimento interrotto. 227 Modalita’ passiva in entrata (h1,h2,h3,h4,p1,p2). 230 Utente loggato, procedere. 530 Non sei loggato. 331 Nome utente valido, serve ora la password. 332 Serve l’account per il login. 532 Serve l’account per l’archiviazione di files. Postel & Reynolds [Page 41] RFC 959 October 1985 File Transfer Protocol 150 Stato del file okay; in prossimita’ di apertura della connessione dati. 250 Azione sul file richiesta completata. 257 "PERCORSO" creato. 350 L’azione sul file richiesta attende ulteriori informazioni. 450 L’azione sul file richiesta non e’ andata a buon fine. File non disponibile (ad esempio, occupato, in uso). 550 L’azione richiesta non e’ stata presa. File non disponibile (ad esempio, file non trovato). 451 L’azione richiesta e’ stata interrotta. Errore locale nell’elaborazione. 551 L’azione richiesta e’ stata interrotta. Tipo di page (pagina) sconosciuto. 452 L’azione richiesta non e’ stata presa. Spazio d’archiviazione sul sistema insufficiente. 552 L’azione richiesta e’ stata interrotta. Superamento dello spazio d’archiviazione allocato (per directory o dataset correnti) 553 L’azione richiesta non e’ stata presa. Nome del file non consentito. 4.2.2 Elenco ordinato dei codici di risposta 110 Risposta di identificazione di un riavvio. In questo caso, il testo e’ esatto e non lasciato a particolari implementazioni; dev’essere: MARK yyyy = mmmm dove yyyy e’ l’identificatore del flusso di dati del processo- utente, e mmmm e’ l’equivalente del server (si notino gli spazi tra gli identificatori e “=”). 120 Servizio disponibile in nnn minuti. 125 Connessione dati gia’ aperta, inizio trasferimento. 150 Stato del file okay; in prossimita’ di apertura della connessione dati. Postel & Reynolds [Page 42] RFC 959 October 1985 File Transfer Protocol 200 Commando valido. 202 Comando non implementato, superfluo in questa postazione. 211 Stato del sistema o risposta d’aiuto di sistema. 212 Stato della directory. 213 Stato del file. 214 Messaggio d’aiuto. Su come utilizzare il server o sul significato di un particolare comando non-standard. Tale risposta e’ utile solamente per un utente umano. 215 Tipo di NOME (NAME) di sistema. dove NAME e’ un sistema di nomenclatura di sistema ufficiale contenuto nell’elenco presente nel documento dei Numeri Assegnati. 220 Servizio pronto per un nuovo utente. 221 Il servizio sta per chiudere la connessione di controllo. Logout se necessario. 225 Connessione dati aperta, nessun trasferimento in corso. 226 In chiusura la connessione dati. L’azione sul file richiesta ha avuto successo (ad esempio, trasferimento di un file) 227 Modalita’ passiva in entrata (h1,h2,h3,h4,p1,p2). 230 Utente loggato, procedere. 250 Azione sul file richiesta completata. 257 "PERCORSO" creato. 331 Nome utente valido, serve ora la password. 332 Serve l’account per il login. 350 L’azione sul file richiesta attende ulteriori informazioni. 421 Servizio non disponibile, in chiusura la connessione di controllo. Questa risposta puo’ essere per un qualsiasi comando, se il servizio sa che deve eseguire lo shut down. 425 Impossibile aprire la connessione dati. 426 Connessione chiusa, trasferimento interrotto. 450 L’azione sul file richiesta non e’ andata a buon fine. File non disponibile (ad esempio, occupato, in uso). 451 L’azione richiesta e’ stata interrotta. Errore locale nell’elaborazione. 452 L’azione richiesta non e’ stata presa. Spazio d’archiviazione sul sistema insufficiente. Postel & Reynolds [Page 43] RFC 959 October 1985 File Transfer Protocol 500 Errore di sintassi, comando non riconosciuto. Questo puo’ comprendere errori quali ad esempio linea di comando troppo lunga. 501 Errore di sintassi nei parametri o negli argomenti 502 Comando non implementato. 503 Sequenza di comandi errata. 504 Comando non implementato per quel parametro. 530 Non sei loggato. 532 Serve l’account per l’archiviazione di files. 550 L’azione richiesta non e’ stata presa. File non disponibile (ad esempio, file non trovato). 551 L’azione richiesta e’ stata interrotta. Tipo di page (pagina) sconosciuto. 552 L’azione richiesta e’ stata interrotta. Superamento dello spazio d’archiviazione allocato (per directory o dataset correnti) 553 L’azione richiesta non e’ stata presa. Nome del file non consentito. 5. SPECIFICHE DICHIARATIVE 5.1. IMPLEMENTAZIONE MINIMA Per poter rendere l’FTP lavorabile senza inutili messaggi d’errore, la seguente minima implementazione e’ richiesta per tutti i servers: TIPO - ASCII Non-print MODALITA’ – Stream (flusso) STRUTTURA - File, Record COMMANDI - USER, QUIT, PORT, TYPE, MODE, STRU, per valori di default RETR, STOR, NOOP. I valori di default per i parametri di trasferimento sono: TYPE - ASCII Non-print MODE - Stream STRU - File Tutti gli hosts devono accettare questi valori come standard di default. Postel & Reynolds [Page 44] RFC 959 October 1985 File Transfer Protocol 5.2. CONNESSIONI L’interprete di protocollo lato server “ascolta” sulla Porta L. L’utente, o l’interprete di protocollo utente, inizia la connessione di controllo full-duplex. I processi –server e –utente dovrebbero seguire le convenzioni del protocollo Telnet come specificato nell’ARPA-Internet Protocol Handbook [1]. I servers non sono obbligati a fornire un editing di linea di comando e possono richiedere che questo sia assolto dall’host utente. La connessione di controllo viene chiusa dal server dietro richiesta dell’utente dopo che tutti i trasferimenti e le risposte sono stati completati. Il DTP-utente deve “ascoltare” sulla porta dati specificata; questa puo’ essere la porta di default utente (U) oppure una porta specificata col comando PORT. Il server iniziera’ la connessione dati dalla sua porta dati di default (L-1) usando la porta dati utente specificata. La direzione del trasferimento e la porta usata verranno determinate mediante i comandi di servizio FTP. Si noti che tutte le implementazioni FTP devono supportare il trasferimento dati usando la porta di default, e che solamente il PI- utente puo’ iniziare l’uso di porte non-di-default. Quando dei dati vengono trasferiti tra due servers, A e B (in riferimento alla Figura 2), il PI-utente, C, imposta le connessioni di controllo con entrambi i PI-server. Ad uno dei server, poniamo A, viene quindi inviato un comando PASV che gli indica di “ascoltare” sulla sua porta dati piuttosto che iniziare una connessione quando riceve un comando di servizio di trasferimento. Quando il PI-utente riceve un riconoscimento al comando PASV, il quale includa l’identita’ dell’host e la porta su cui ascoltare, il PI-utente invia quindi la porta di A, a, a B tramite un comando PORT; viene tornata una risposta. Il PI-utente puo’ quindi inviare i servizi di comando corrispondenti ad A e B. Il server B inizia la connessione e il trasferimento procede. La sequenza comando-risposta viene elencata di seguito, dove i messaggi sono verticalmente sincroni ma orizzontalmente asincroni: Postel & Reynolds [Page 45] RFC 959 October 1985 File Transfer Protocol PI-utente - Server A PI-utente - Server B -------------------- -------------------- C->A : Connect C->B : Connect C->A : PASV A->C : 227 Entering Passive Mode. A1,A2,A3,A4,a1,a2 C->B : PORT A1,A2,A3,A4,a1,a2 B->C : 200 Okay C->A : STOR C->B : RETR B->A : Connect to HOST-A, PORT-a Figura 3 La connessione dati verra’ chiusa dal server secondo le condizioni descritte nella sezione relativa a Stabilire le Connessioni Dati. Se la connessione dati dev’essere chiusa a seguito di un trasferimento dove la chiusura della connessione non e’ richiesta per indicare l’end-of-file, il server deve farlo immediatamente. Aspettare fin dopo un nuovo comando di trasferimento non e’ consentito poiche’ il processo-utente avra’ gia’ esaminato la connessione dati per vedere se essa necessita di fare un “ascolto”; (si ricordi che l’utente deve “ascoltare” su una porta dati chiusa PRIMA che invii la richiesta di trasferimento). Per evitare in questo ambito una ‘race condition’ [N.d.T.: condizione in cui entra in gioco il fattore tempo] il server invia una risposta (226) dopo la chiusura della connessione dati (o se la connessione viene lasciata aperta, una risposta (250) “trasferimento file completato” e il PI-utente deve aspettare una di queste risposte prima prima di inoltrare un nuovo comando di trasferimento). Ogni volta che l’utente o il server vede che la connessione sta per essere chiusa dall’altro lato, esso dovrebbe subito leggere qualsiasi dato rimasto in coda sulla connessione e chiuderla sul proprio lato. 5.3. COMANDI I comandi sono stringhe di caratteri Telnet trasmesse mediante le connessioni di controllo come descritto nella sezione relativa ai Comandi FTP. Le funzioni di comando e la semantica sono descritte nella sezione relativa ai Comandi di Controllo d’Accesso, Comandi di Parametri di Trasferimento, Comandi di Servizio FTP e Comandi Vari. La sintassi di comando viene specificata qui. I comandi iniziano con un codice di comando seguito da un campo d’argomento. I codici di comando sono quattro o meno caratteri alfabetici. I caratteri alfabetici maiuscoli e minuscoli sono trattati devono essere trattati allo stesso modo. Cosi’, tutti i seguenti possono rappresentare i comandi richiamati: Postel & Reynolds [Page 46] RFC 959 October 1985 File Transfer Protocol RETR Retr retr ReTr rETr Questo si applica anche a qualsiasi simbolo che rappresenti un valore di parametro, come una A o a per il TIPO ASCII. I codici di comando e i campi d’argomento sono separati da uno o piu’ spazi. Il campo d’argomento consiste in una stringa di caratteri di lunghezza variabile che termina con la sequenza (Carriage Return, Line Feed) per la rappresentazione NVT-ASCII; per altri linguaggi negoziati puo’ essere utilizzata una diversa end-of-line. Si noti che il server non deve prendere iniziative finche’ non riceve il codice di end-of-line. La sintassi viene sotto specificata in NVT-ASCII. Tutti i caratteri nel campo d’argomento sono caratteri ASCII comepreso qualsiasi numero intero decimale rappresentato in ASCII. Le parentesi quadre denotano un campo d’argomento facoltativo. Se l’opzione non viene usata, questo implica l’appropriato default. Postel & Reynolds [Page 47] RFC 959 October 1985 File Transfer Protocol 5.3.1. COMANDI FTP Quelli che seguono sono i comandi FTP: USER PASS ACCT CWD CDUP SMNT QUIT REIN PORT PASV TYPE STRU MODE RETR STOR STOU APPE ALLO [ R ] REST RNFR RNTO ABOR DELE RMD MKD PWD LIST [ ] NLST [ ] SITE SYST STAT [ ] HELP [ ] NOOP Postel & Reynolds [Page 48] RFC 959 October 1985 File Transfer Protocol 5.3.2. ARGOMENTI DEI COMANDI FTP La sintassi dei suddetti campi d’argomento(usando la notazione BNF ove applicabile) e’: ::= ::= ::= ::= | ::= qualsiasi caratteri tra I 128 ASCII ad esclusione di e ::= ::= | ::= caratteri stampabili, qualsiasi codice ASCII dal 33 al 126 ::= ::= , ::= ,,, ::= , ::= qualsiasi numero intero decimale da 1 a 255 ::= N | T | C ::= A [ ] | E [ ] | I | L ::= F | R | P ::= S | B | C ::= ::= qualsiasi numero intero decimale Postel & Reynolds [Page 49] RFC 959 October 1985 File Transfer Protocol 5.4. SEQUENZE DI COMANDI E RISPOSTE La comunicazione tra utente e server e’ concepita per essere una dialogo alternato. Come tale, l’utente fornisce un comando FTP e il server risponde con una pronta risposta primaria. L’utente dovrebbe aspettare la risposta primaria di successo o insuccesso prima di inviare ulteriori comandi. Alcuni comandi richiedono una seconda risposta per la quale l’utente potrebbe anche aspettare. Tali risposte possono, ad esempio, riportare informazioni sull’avanzamento o il completamento del trasferimento di file o sulla chiusura della connessione dati. Queste sono risposte secondarie ai comandi di trasferimento file. Un importante gruppo di risposte informative sono i “saluti(?)” di connessione. In circostanze normali, un server inviera’ una risposta 220, “in attesa di input”, quando la connessione viene completata. L’utente dovrebbe attendere questo messaggio di “saluto” prima di inviare qualsiasi altro comando. Se il server non e’ in grado di accettare subito input, una risposta 120 “previsto ritardo” dovrebbe essere inviata immediatamente e una risposta 220 quando pronto. L’utente sapra’ quindi di non interferire se vi e’ un ritardo. Risposte Spontanee Alcune volte “il sistema” ha spontaneamente un messaggio che dev’essere inviato ad un utente (normalmente a tutti gli utenti). Ad esempio, “il sistema termina entro 15 minuti”. Nel FTP non vi sono misure affinche’ tali informazioni spontanee siano inviate dal server all’utente. E’ raccomandabile che tali informazioni siano accodate nel PI-server e distribuite al PI-utente nella risposta successiva (possibilmente in una risposta multi-linea). La tabella di sotto elenca risposte alternative di successo o insuccesso per ogni comando. A queste ci si deve attenere strettamente; un server puo’ sostituire il testo delle risposte, ma il significato e l’azione implicata dal numero di codice e dalla specifica sequenza comando-risposta non possono essere alterati. Sequenze comando-risposta In questa sezione viene presentata la sequenza comando-risposta. Ciascun comando viene elencato con le sue possibili risposte; i gruppi di comando sono elencati insieme. Per prima cosa vengono riportate le risposte, poi i completamenti positivi o negativi, e infine le risposte Postel & Reynolds [Page 50] RFC 959 October 1985 File Transfer Protocol intermedie con u comandi rimanenti dalle sequenze seguenti. Questa elencazione costituisce le basi dei diagrammi di stato, che vengono presentati separatamente. Stabilire la connessione 120 220 220 421 Login USER 230 530 500, 501, 421 331, 332 PASS 230 202 530 500, 501, 503, 421 332 ACCT 230 202 530 500, 501, 503, 421 CWD 250 500, 501, 502, 421, 530, 550 CDUP 200 500, 501, 502, 421, 530, 550 SMNT 202, 250 500, 501, 502, 421, 530, 550 Logout REIN 120 220 220 421 500, 502 QUIT 221 500 Postel & Reynolds [Page 51] RFC 959 October 1985 File Transfer Protocol Parametri di trasferimento PORT 200 500, 501, 421, 530 PASV 227 500, 501, 502, 421, 530 MODE 200 500, 501, 504, 421, 530 TYPE 200 500, 501, 504, 421, 530 STRU 200 500, 501, 504, 421, 530 Comandi di azione sui file ALLO 200 202 500, 501, 504, 421, 530 REST 500, 501, 502, 421, 530 350 STOR 125, 150 (110) 226, 250 425, 426, 451, 551, 552 532, 450, 452, 553 500, 501, 421, 530 STOU 125, 150 (110) 226, 250 425, 426, 451, 551, 552 532, 450, 452, 553 500, 501, 421, 530 RETR 125, 150 (110) 226, 250 425, 426, 451 450, 550 500, 501, 421, 530 Postel & Reynolds [Page 52] RFC 959 October 1985 File Transfer Protocol LIST 125, 150 226, 250 425, 426, 451 450 500, 501, 502, 421, 530 NLST 125, 150 226, 250 425, 426, 451 450 500, 501, 502, 421, 530 APPE 125, 150 (110) 226, 250 425, 426, 451, 551, 552 532, 450, 550, 452, 553 500, 501, 502, 421, 530 RNFR 450, 550 500, 501, 502, 421, 530 350 RNTO 250 532, 553 500, 501, 502, 503, 421, 530 DELE 250 450, 550 500, 501, 502, 421, 530 RMD 250 500, 501, 502, 421, 530, 550 MKD 257 500, 501, 502, 421, 530, 550 PWD 257 500, 501, 502, 421, 550 ABOR 225, 226 500, 501, 502, 421 Postel & Reynolds [Page 53] RFC 959 October 1985 File Transfer Protocol Comandi informativi SYST 215 500, 501, 502, 421 STAT 211, 212, 213 450 500, 501, 502, 421, 530 HELP 211, 214 500, 501, 502, 421 Comandi vari SITE 200 202 500, 501, 530 NOOP 200 500 421 Postel & Reynolds [Page 54] RFC 959 October 1985 File Transfer Protocol 6. DIAGRAMMI DI STATO Presentiamo qui i diagrammi di stato per una implementazione FTP molto semplice. Viene utilizzata solamente la prima cifra per i codici di risposta. Vi e’ un diagramma di stato per ciascun gruppo di comandi o sequenze di comandi FTP. I raggruppamenti dei comandi sono determinati mediante la costruzione di un modello per ciascun comando e il raccoglimento seguente dei comandi con modelli strutturalmente identici. Per ciascun comando o sequenza di comandi vi sono tre possibili risultati: successo (S), insuccesso (I) ed errore (E). Nel diagramma di stato qui sotto utilizziamo il simbolo P per “partenza”, e il simbolo A per “in attesa di risposta”. Presentiamo per primo il diagramma che rappresenta il piu’ grande insieme di comandi FTP: 1,3 +---+ ----------->| E | | +---+ | +---+ cmd +---+ 2 +---+ | P |---------->| A |---------->| S | +---+ +---+ +---+ | | 4,5 +---+ ----------->| I | +---+ Questo schema modella i comandi: ABOR, ALLO, DELE, CWD, CDUP, SMNT, HELP, MODE, NOOP, PASV, QUIT, SITE, PORT, SYST, STAT, RMD, MKD, PWD, STRU, e TYPE. Postel & Reynolds [Page 55] RFC 959 October 1985 File Transfer Protocol Gli altri grandi gruppi di comandi sono rappresentati da un diagramma molto simile: 3 +---+ ----------->| E | | +---+ | +---+ cmd +---+ 2 +---+ | P |---------->| A |---------->| S | +---+ --->+---+ +---+ | | | | | | 4,5 +---+ | 1 | ----------->| I | ----- +---+ Questo diagramma modella i comandi: APPE, LIST, NLST, REIN, RETR, STOR, e STOU. Si noti che questo secondo modello potrebbe anche essere usato per rappresentare il primo gruppo di comandi, la sola differenza sta nel fatto che nel primo gruppo le risposta della serie 100 sono inaspettate e quindi trattate come errore, mentre il secondo gruppo prevede (a volte puo’ richiedere) risposte della serie 100. Si ricordi che e’ consentita al massimo una risposta della serie 100 per comando. I diagrammi rimanenti modellano le sequenze di comando, forse il piu’ semplice di queste e’ la sequenza “rinomina”: +---+ RNFR +---+ 1,2 +---+ | P |---------->| A |---------->| E | +---+ +---+ -->+---+ | | | 3 | | 4,5 | -------------- ------ | | | | +---+ | ------------->| S | | | 1,3 | | +---+ | 2| -------- | | | | V | | | +---+ RNTO +---+ 4,5 ----->+---+ | |---------->| A |---------->| I | +---+ +---+ +---+ Postel & Reynolds [Page 56] RFC 959 October 1985 File Transfer Protocol Il diagramma successivo e’ un modello semplice del comando Restart (Riavvio): +---+ REST +---+ 1,2 +---+ | P |---------->| A |---------->| E | +---+ +---+ -->+---+ | | | 3 | | 4,5 | -------------- ------ | | | | +---+ | ------------->| S | | | 3 | | +---+ | 2| -------- | | | | V | | | +---+ cmd +---+ 4,5 ----->+---+ | |---------->| A |---------->| I | +---+ -->+---+ +---+ | | | 1 | ------ dove "cmd" sta per APPE, STOR, o RETR. Notiamo che i tre modelli sopra presentati sono simili. Il Restart differisce dal Rename due solamente nella gestione delle risposte della serie 100 nella seconda fase, mentre il secondo gruppo prevede (a volte richiede) risposte della serie 100. Si ricordi che e’ consentita al massimo una risposta della serie 100 per comando. Postel & Reynolds [Page 57] RFC 959 October 1985 File Transfer Protocol Il diagramma piu’ complesso e’ quello per la sequenza di Login: 1 +---+ UTENTE +---+------------->+---+ | P |---------->| A | 2 ---->| E | +---+ +---+------ | -->+---+ | | | | | 3 | | 4,5 | | | -------------- ----- | | | | | | | | | | | | | | --------- | | 1| | | | V | | | | +---+ PASS +---+ 2 | ------>+---+ | |---------->| A |------------->| S | +---+ +---+ ---------->+---+ | | | | | 3 | |4,5| | | -------------- -------- | | | | | | | | | | | | ----------- | 1,3| | | | V | 2| | | +---+ ACCT +---+-- | ----->+---+ | |---------->| A | 4,5 -------->| I | +---+ +---+------------->+---+ Postel & Reynolds [Page 58] RFC 959 October 1985 File Transfer Protocol Presentiamo infine un diagramma generico che puo’ essere usato per modellare lo scambio comando risposta: ------------------------------------ | | Partenza | | | V | | +---+ cmd +---+ 2 +---+ | -->| |------->| |---------->| | | | | | A | | S |-----| -->| | -->| |----- | | | | +---+ | +---+ 4,5 | +---+ | | | | | | | | | | | 1| |3 | +---+ | | | | | | | | | | | | ---- | ---->| I |----- | | | | | | | | +---+ ------------------- | | V Fine Postel & Reynolds [Page 59] RFC 959 October 1985 File Transfer Protocol 7. TIPICO SCENARIO FTP L’utente dell’host U vuole trasferire files a/da l’host S: In generale, l’utente comunichera’ col server per mezzo di un processo utente-FTP mediatore. Quello che segue potrebbe essere uno scenario FTP tipico. I richiami al FTP-utente sono mostrati fra parentesi, '---->' rappresenta comandi dall’host U all’host S, mentre '<----' rappresenta risposte dall’host S all’host U. COMANDI LOCALI DELL’UTENTE AZIONI COINVOLTE ftp (host) multics Connette all’host S, porta L, stabilendo connessioni di controllo. <---- 220 Servizio pronto . username Doe USER Doe----> <---- 331 Nome utente valido, inserire la password. password mumble PASS mumble----> <---- 230 Utente loggato. retrieve (tipo locale) ASCII (percorso locale) test 1 FTP-utente apre file locale in ASCII. (for. pathname) test.pl1 RETR test.pl1 ----> <---- 150 stato file okay; in apertura la connessione dati. Il server fa una connessione dati alla porta U. <---- 226 In chiusura la connessione dati, trasferimento file avvenuto con successo. type Image TYPE I ----> <---- 200 Comando OK store (tipo locale) image (percorso locale) file dump FTP-utente apre file locale in Image. (for.pathname) >udd>cn>fd STOR >udd>cn>fd ----> <---- 550 Accesso non consentito terminate QUIT ----> Il server chiude tutte le connessioni. 8. ISTITUZIONE DELLA CONNESSIONE La connessione di controllo FTP viene stabilita via TCP tra la porta U del processo utente e quella L del processo lato server. A questo protocollo viene assegnata la porta di servizio 21 (25 ottale), percui L=21. Postel & Reynolds [Page 60] RFC 959 October 1985 File Transfer Protocol APPENDICE I - STRUTTURA A PAGE (PAGINA) La necessita’ per l’FTP di supportare strutture a pagina deriva principalmente dalla necessita’ di supportare trasmissioni di files efficienti tra sistemi TOPS-20, in particolare per i file usati dal NLS. Il file system del TOPS-20 e’ basato sul concetto di pagina. Il sistema operativo e’ piu’ efficiente con la manipolazione dei files come pagine. Il sistema operativo fornisce un’interfaccia al file system in modo che molte applicazioni vedono i files come flussi sequenziali di caratteri. Alcune applicazioni, ad ogni modo, usano le strutture a pagina direttamente, e alcune di queste creano holey files (vuoti?). Un file TOPS-20 su disco consiste in quattro cose: un percorso, un tavola di pagine, un insieme (possibilmente vuoto) di pagine, e un set di attributi. Il percorso viene specificato con i comandi RETR o STOR. Esso comprende il nome della directory, il nome del file, l’estensione del file, e il numero di generazione. La tavola delle pagine contiene fino a 2**18 valori. Ciascun valore puo’ essere VUOTO, o puo’ puntare ad una pagina. Se non e’ vuoto, vi sono anche alcuni bits di accesso ad una pagina-specifica; non tutte le pagine di un file necessitano di avere la stessa protezione d’accesso. Un pagina (page) e’ un insieme contiguo di 512 parole di 36 bits ciascuna. Gli attributi del file, nel File Descriptor Block (FDB – Blocco Descrittore del File), contengono cose come la data di creazione, la data di scrittura, quella di lettura, il puntatore di end-of-file, il contatore di letture e scritture, i numeri del nastro di backup di sistema, ecc. Si noti che NON vi e’ la necessita’ che i valori nella tabella delle pagine siano contigui. Vi possono essere campi vuoti tra quelli occupati. Non e’ infatti richiesto che un valore punti all’”ultimo” riferimento nel file. Le chiamate sequenziali ordinarie in TOPS-20 comporteranno che il puntatore di end-of-file sia lasciato dopo l’ultimo riferimento scritto, tuttavia altre operazioni potrebbero fare in modo che non sia cosi’, se un particolare sistema di programmazione lo richiede. Difatti, in entrambi questi speciali casi, “holey” files e puntatori di end- of-file NON alla fine del file, si hanno con file di dati NLS. Postel & Reynolds [Page 61] RFC 959 October 1985 File Transfer Protocol I file paginati TOPS-20 possono essere inviati con i parametri di trasferimento FTP: TYPE L 36, STRU P, e MODE S (infatti, puo’ essere usata qualsiasi modalita’). Ciascuna pagina di informazione ha un header (intestazione). Ciascun campo header, che e’ un byet logico, e’ una parola TOPS-20, dal momento che TYPE e’ L 36. I campi dell’header sono: Word 0: Lunghezza dell’Header. La lunghezza dell’header e’ 5. Word 1: Indice delle Pagine. Se I dati sono un file page su disco, questo e’ il numero delle pagine nella mappa delle pagine del file. Le pagine vuote nel file semplicemente non vengono inviate. Si noti che un vuoto NON e’ uguale ad una pagine di zero. Word 2: Lunghezza dei Dati. Il numero di data-words in questa pagina, che segue l’header. Cosi’, la lunghezza totale dell’unita’ di trasmissione e’ la Lunghezza dell’Header piu’ la Lunghezza dei Dati. Word 3: Tipo di Pagina. Un codice per sapere il tipo della pagina. Una pagina di dati e’ type 3, la pagina FDB e’ type 2. Word 4: Controllo d’Accesso Pagina. I bits d’accesso associati alla pagina nella mappa delle pagine del file. (Questa quantita’ e’ messa nell’AC2 di uno SPACS dalla lettura di programma dalla rete al disco). Dopo l’header viene la Lunghezza Dati. Essa e’ attualmente di 512 per una pagina di dati o 31 per un FDB. Tirarsi dietro gli zero in una pagina di un file su disco puo’ essere scartato, rendendo in questo caso la Lunghezza Dati inferiore di 512. Postel & Reynolds [Page 62] RFC 959 October 1985 File Transfer Protocol APPENDICE II - COMANDI RELATIVI ALLE CARTELLE [N.d.T.: il materiale di questa appendice e’ stato in gran parte preso dalla RFC 775 “Comandi FTP orientati alle cartelle” (1980), che forniva il risultato della prima implementazione di tali comandi] [N.d.T.: il TOPS-20 e il Multics sono sistemi operativi usati in passato. Il Multics (acronimo di Multiplexed Information and Computing Service) in particolare, e’ uno dei primi sistemi operativi multiutente: parliamo degli anni sessanta. Fu usato per una ventina d’anni ma non si divulgo’ mai in larga scala; fu tuttavia la musa ispiratrice per lo sviluppo di diversi altri sistemi operativi.] Dal momento che UNIX ha una struttura di directory ad albero nella quale le directory sono facilmente manipolabili come files ordinari, risulta utile espandere i servers FTP su tali macchine in modo da includere comandi che abbiano a che fare con la creazione di directory. E dal momento che vi sono altri host sull’ARPA-Internet dotati di una struttura ad albero (compresi il TOPS-20 e il Multics), questi comandi devono essere il piu’ generale possibile. Al FTP sono stati aggiunti quattro comandi relativi alle directory: MKD percorso [MaKe Directory – Crea cartella] Crea la cartella con il nome “percorso” RMD percorso [ReMove Directory – Rimuovi cartella] Rimuovi la cartella con il nome “percorso” PWD [Print Working Directory – Visualizza la cartella corrente] Visualizza il nome della cartella di lavoro corrente CDUP [Change to Directory UP (?) – Vai alla cartella superiore] Vai alla cartella superiore all’attuale cartella di lavoro L’argomento “percorso” dovrebbe essere creato (rimosso) come una sottocartella della cartella di lavoro corrente, a meno che la stringa “percorso” contenga informazioni sufficienti per specificare al server diversamente, ad es. “percorso” e’ un percorso assoluto (in UNIX e Multics), oppure percorso e’ qualcosa del tipo “” sotto TOPS-20. CODICI DI RISPOSTA Il comando CDUP e’ un caso speciale di CWD, ed e’ incluso per semplificare l’implementazione di programmi per il trasferimento di alberi di directory tra sistemi operativi aventi sintassi diverse per la nomenclatura delle parent directory (cartelle madri, superiori). I codici di risposta per CDUP sono identici a quelli per CWD. I codici di risposta per RMD sono identici a quelli del suo analogo, DELE. I codici di risposta per MKD, tuttavia, sono leggermente piu’ complessi. Una cartella creata di recente sara’ probabilmente oggetto di un futuro Postel & Reynolds [Page 63] RFC 959 October 1985 File Transfer Protocol comando CWD. Sfortunatamente, l’argomento di MKD non sempre puo’ essere adatto anche per CWD. Questo e’ il caso, ad esempio, quando una sottocartella TOPS-20 viene creata dando solamente il nome della stessa. Percui, con un server FTP TOPS-20, la sequenza di comando MKD MIACARTELLA CWD MIACARTELLA non andra’ a buon fine. Alla nuova cartella ci si potra’ riferire solamente con il suo nome “assoluto”; ad es., se il comando MKD e’ stato inserito mentre connessi alla cartella , alla nuova sottocartella ci si potra’ riferire solamente con il nome . Sempre sotto UNIX e Multics, comunque, l’argomento dato a MKD puo’ non essere adatto. Se esso e’ un percorso “relativo” (ad es., un percorso interpretato relativo alla cartella attuale), l’utente potrebbe aver la necessita’ di stare nella stessa cartella corrente per poter raggiungere la sottocartella. A seconda dell’applicazione, questo potrebbe essere un inconveniente. In alcun caso non e’ molto robusto. Per risolvere questi problemi, e avere un comando MKD di pieno successo, il server dovrebbe tornare una linea della forma: 257"" Cosi’, il server dira’ all’utente quale stringa utilizzare per riferirsi alla cartella creata. Il nome della cartella puo’ contenere qualsiasi carattere; le virgolette all’interno dovrebbero essere fatte uscire dalle virgolette (convenzione di “virgolettatura”). Per esempio, un utente si connette alla cartella /usr/dm, e crea una sottocartella chiamata ‘percorso’: CWD /usr/dm 200 cartella cambiata in /usr/dm MKD percorso 257 "/usr/dm/percorso" directory creata Esempio con virgolette incluse: MKD foo"bar 257 "/usr/dm/foo""bar" directory creata CWD /usr/dm/foo"bar 200 directory cambiata in /usr/dm/foo"bar Postel & Reynolds [Page 64] RFC 959 October 1985 File Transfer Protocol La precedente esistenza di una sottocartella con lo stesso nome e’ un errore, e il server deve tornare in questo caso una risposta d’errore di “accesso negato”. CWD /usr/dm 200 directory cambiata in /usr/dm MKD percorso 521-"/usr/dm/pathname" la cartella esiste gia’; 521 nessuna azione intrapresa. Le risposte di insuccesso per MKD sono analoghe al suo cugino STOR. Inoltre, un ritorno di “accesso negato” viene dato anche se un nome di file uguale al nome di una sottocartella generera’ conflitto con la creazione della sottocartella (questo e’ un problema sotto UNIX, ma non dovrebbe esserlo sotto TOPS-20). Essenzialmente, poiche’ il comando PWD ritorna lo stesso tipo di informazione di un comando MKD riuscito, il comando PWD riuscito usa anch’esso il codice di risposta 257. SUBTLETIES Siccome questi comandi sono per lo piu’ utili nel trasferimento di sottoalberi da una macchina ad un altra, si osservi con attenzione che l’argomento di MKD dev’essere interpretato come una sottocartella della cartella di lavoro corrente, a meno che non contenga informazioni sufficienti per dire diversamente all’host di destinazione. Un esempio ipotetico del suo utilizzo nel mondo del Tops-20: CWD 200 Cartella di lavoro cambiata MKD overrainbow 257 "" directory creata CWD overrainbow 431 Cartella non trovata CWD 200 Cartella di lavoro cambiata CWD 200 Cartella di lavoro cambiata in MKD 257 "" directory creata CWD Si noti che il primo esempio risulta in una sottocartella della cartella connessa. In contrasto, l’argomento nel secondo esempio contiene informazioni sufficienti sotto Tops-20 per dire che la cartella Postel & Reynolds [Page 65] RFC 959 October 1985 File Transfer Protocol e’ una cartella di primo livello (top-level). Si noti anche che nel primo esempio l’utente “ha violato” il protocollo tentando di accedere alla cartella appena creata con un nome diverso da quello tornato dal Tops-20. I problemi che potrebbero essere risultati in questo caso sono stati una cartella ; questa e’ un’ambiguita’ inerente a qualche implementazione Tops-20. Simili considerazioni si applicano al comando RMD. Il punto e’ questo: a meno che non voglia violare la convenzione di un host per la denotazione relativa contro percorsi assoluti, l’host dovrebbe trattare gli operandi dei comandi MKD e RMD come sottocartelle. La risposta 257 al comando MKD deve sempre contenere il percorso assoluto della cartella creata. Postel & Reynolds [Page 66] RFC 959 October 1985 File Transfer Protocol APPENDICE III - RFCs relative al FTP Bhushan, Abhay, "A File Transfer Protocol", RFC 114 (NIC 5823), MIT-Project MAC, 16 April 1971. Harslem, Eric, and John Heafner, "Comments on RFC 114 (A File Transfer Protocol)", RFC 141 (NIC 6726), RAND, 29 April 1971. Bhushan, Abhay, et al, "The File Transfer Protocol", RFC 172 (NIC 6794), MIT-Project MAC, 23 June 1971. Braden, Bob, "Comments on DTP and FTP Proposals", RFC 238 (NIC 7663), UCLA/CCN, 29 September 1971. Bhushan, Abhay, et al, "The File Transfer Protocol", RFC 265 (NIC 7813), MIT-Project MAC, 17 November 1971. McKenzie, Alex, "A Suggested Addition to File Transfer Protocol", RFC 281 (NIC 8163), BBN, 8 December 1971. Bhushan, Abhay, "The Use of "Set Data Type" Transaction in File Transfer Protocol", RFC 294 (NIC 8304), MIT-Project MAC, 25 January 1972. Bhushan, Abhay, "The File Transfer Protocol", RFC 354 (NIC 10596), MIT-Project MAC, 8 July 1972. Bhushan, Abhay, "Comments on the File Transfer Protocol (RFC 354)", RFC 385 (NIC 11357), MIT-Project MAC, 18 August 1972. Hicks, Greg, "User FTP Documentation", RFC 412 (NIC 12404), Utah, 27 November 1972. Bhushan, Abhay, "File Transfer Protocol (FTP) Status and Further Comments", RFC 414 (NIC 12406), MIT-Project MAC, 20 November 1972. Braden, Bob, "Comments on File Transfer Protocol", RFC 430 (NIC 13299), UCLA/CCN, 7 February 1973. Thomas, Bob, and Bob Clements, "FTP Server-Server Interaction", RFC 438 (NIC 13770), BBN, 15 January 1973. Braden, Bob, "Print Files in FTP", RFC 448 (NIC 13299), UCLA/CCN, 27 February 1973. McKenzie, Alex, "File Transfer Protocol", RFC 454 (NIC 14333), BBN, 16 February 1973. Postel & Reynolds [Page 67] RFC 959 October 1985 File Transfer Protocol Bressler, Bob, and Bob Thomas, "Mail Retrieval via FTP", RFC 458 (NIC 14378), BBN-NET and BBN-TENEX, 20 February 1973. Neigus, Nancy, "File Transfer Protocol", RFC 542 (NIC 17759), BBN, 12 July 1973. Krilanovich, Mark, and George Gregg, "Comments on the File Transfer Protocol", RFC 607 (NIC 21255), UCSB, 7 January 1974. Pogran, Ken, and Nancy Neigus, "Response to RFC 607 - Comments on the File Transfer Protocol", RFC 614 (NIC 21530), BBN, 28 January 1974. Krilanovich, Mark, George Gregg, Wayne Hathaway, and Jim White, "Comments on the File Transfer Protocol", RFC 624 (NIC 22054), UCSB, Ames Research Center, SRI-ARC, 28 February 1974. Bhushan, Abhay, "FTP Comments and Response to RFC 430", RFC 463 (NIC 14573), MIT-DMCG, 21 February 1973. Braden, Bob, "FTP Data Compression", RFC 468 (NIC 14742), UCLA/CCN, 8 March 1973. Bhushan, Abhay, "FTP and Network Mail System", RFC 475 (NIC 14919), MIT-DMCG, 6 March 1973. Bressler, Bob, and Bob Thomas "FTP Server-Server Interaction - II", RFC 478 (NIC 14947), BBN-NET and BBN-TENEX, 26 March 1973. White, Jim, "Use of FTP by the NIC Journal", RFC 479 (NIC 14948), SRI-ARC, 8 March 1973. White, Jim, "Host-Dependent FTP Parameters", RFC 480 (NIC 14949), SRI-ARC, 8 March 1973. Padlipsky, Mike, "An FTP Command-Naming Problem", RFC 506 (NIC 16157), MIT-Multics, 26 June 1973. Day, John, "Memo to FTP Group (Proposal for File Access Protocol)", RFC 520 (NIC 16819), Illinois, 25 June 1973. Merryman, Robert, "The UCSD-CC Server-FTP Facility", RFC 532 (NIC 17451), UCSD-CC, 22 June 1973. Braden, Bob, "TENEX FTP Problem", RFC 571 (NIC 18974), UCLA/CCN, 15 November 1973. Postel & Reynolds [Page 68] RFC 959 October 1985 File Transfer Protocol McKenzie, Alex, and Jon Postel, "Telnet and FTP Implementation - Schedule Change", RFC 593 (NIC 20615), BBN and MITRE, 29 November 1973. Sussman, Julie, "FTP Error Code Usage for More Reliable Mail Service", RFC 630 (NIC 30237), BBN, 10 April 1974. Postel, Jon, "Revised FTP Reply Codes", RFC 640 (NIC 30843), UCLA/NMC, 5 June 1974. Harvey, Brian, "Leaving Well Enough Alone", RFC 686 (NIC 32481), SU-AI, 10 May 1975. Harvey, Brian, "One More Try on the FTP", RFC 691 (NIC 32700), SU-AI, 28 May 1975. Lieb, J., "CWD Command of FTP", RFC 697 (NIC 32963), 14 July 1975. Harrenstien, Ken, "FTP Extension: XSEN", RFC 737 (NIC 42217), SRI-KL, 31 October 1977. Harrenstien, Ken, "FTP Extension: XRSQ/XRCP", RFC 743 (NIC 42758), SRI-KL, 30 December 1977. Lebling, P. David, "Survey of FTP Mail and MLFL", RFC 751, MIT, 10 December 1978. Postel, Jon, "File Transfer Protocol Specification", RFC 765, ISI, June 1980. Mankins, David, Dan Franklin, and Buzz Owen, "Directory Oriented FTP Commands", RFC 776, BBN, December 1980. Padlipsky, Michael, "FTP Unique-Named Store Command", RFC 949, MITRE, July 1985. Postel & Reynolds [Page 69] RFC 959 October 1985 File Transfer Protocol RIFERIMENTI [1] Feinler, Elizabeth, "Internet Protocol Transition Workbook", Network Information Center, SRI International, March 1982. [2] Postel, Jon, "Transmission Control Protocol - DARPA Internet Program Protocol Specification", RFC 793, DARPA, September 1981. [3] Postel, Jon, and Joyce Reynolds, "Telnet Protocol Specification", RFC 854, ISI, May 1983. [4] Reynolds, Joyce, and Jon Postel, "Assigned Numbers", RFC 943, ISI, April 1985. Postel & Reynolds [Page 70]