Network Working Group

Request for Comments: 959

Category: Standard

J. Postel, J. Reynolds
ISI
Octobre 1985

French translation by V.G. FREMAUX / Ecole Internationale des Sciences du

Traitement de l'Information
(International Graduate School of Computer Sciences)

Remplace RFC: 765 (IEN 149)

File Transfer Protocol (FTP)

INTERNET
STANDARDS & OFFICIAL DOCUMENTS

RFC959

Standard

Informational

Proposal

Note du Traducteur :
Le texte suivant est la traduction intgrale de la spcification FTP, telle qu'dite par
les auteurs originaux du protocole, sans ajouts, commentaires, ni omissions. Ce
document a valeur normative, selon la procdure courante d'enregistrement des
documents au sein du W3C.

Statut de ce Mmo
Ce mmo est la spcification officielle du Protocole de Transfert de Fichiers (FTP).
La distribution de ce mmo est illimite.
Les nouvelles commandes optionnelles suivantes sont inclues dans la prsente
dition de la spcification:
CDUP (Change to Parent Directory), SMNT (Structure Mount), STOU (Store
Unique), RMD (Remove Directory), MKD (Make Directory), PWD (Print Directory), et
SYST (System).
Notez que cette spcification est compatible avec la prcdente dition.

0. TABLE DES MATIERES

1. INTRODUCTION

2. VUE D'ENSEMBLE

2.1. HISTORIQUE

2.2. TERMINOLOGIE

2.3. LE MODELE FTP

3. FONCTIONS DE TRANSFERT DE DONNEES

10

3.1. REPRESENTATION DES DONNEES ET STOCKAGE

3.1.1. TYPES DE DONNEES
3.1.2. STRUCTURES DE DONNEES

11
11
14

3.2. ETABLISSEMENT DU CANAL DE DONNEES

17

3.3. GESTION DU CANAL DE DONNEES

18

3.4. MODES DE TRANSMISSION

3.4.1. MODE "FLUX"
3.4.2. MODE BLOC
3.4.3. MODE COMPRESSE

19
19
20
21

3.5. RECUPERATION D'ERREUR ET REPRISE DE TRANSMISSION

22

4. FONCTIONS DE TRANFERT DE FICHIERS

23

4.1. COMMANDES FTP

4.1.1. COMMANDES DE CONTROLE D'ACCES
4.1.2. COMMANDES DE PARAMETRAGE DU TRANSFERT

23
24
26

RFC959

4.1.3. COMMANDES DE SERVICE FTP

28

4.2. REPONSES FTP

4.2.1 CODES DE REPONSE PAR GROUPES DE FONCTIONS
4.2.2 CODES REPONSE PAR ORDRE NUMERIQUE

33
36
38

5. SPECIFICATIONS DECLARATIVES

39

5.1. IMPLEMENTATION MINIMALE

39

5.2. CONNEXIONS

39

5.3. COMMANDES
5.3.1. COMMANDES FTP
5.3.2. ARGUMENTS DE COMMANDES FTP

41
41
42

5.4. SEQUENCEMENT DES COMMANDES ET REPONSES

43

6. DIAGRAMMES D'ETAT

46

7. SCENARIOS FTP TYPIQUE

50

8. ETABLISSEMENT DE LA CONNEXION

50

APPENDICE I - STRUCTURE DE PAGE

50

APPENDICE II - COMMANDES DE REPERTOIRE

52

APPENDICE III - RFC PROPOS DE FTP

55

REFERENCES

58

1. INTRODUCTION
Les objectifs de FTP sont 1) de promouvoir le partage de fichiers (programmes
informatiques et/ou donnes), 2) d'encourager l'utilisation indirecte ou implicite (via
des programmes) d'ordinateurs distants, 3) de prmunir l'utilisateur contre les
variations de formats de stockage de donnes entre les diffrents htes, et 4) de
transfrer les donnes d'une faon efficace et fiable. FTP, bien que directement
utilisable par un utilisateur depuis un terminal, est nanmoins conu essentiellement
pour tre utilis par des programmes.
Cette spcification tente de satisfaire les besoins varis d'utilisateurs de
mainframes, minis, et stations personnelles, et TACs, grce un protocole au
design simple et facile de mise en oeuvre.
Ce document suppose une bonne connaissance du protocole Transmission
Control Protocol (TCP) [2] et du protocole Telnet [3]. Ces documents font partie du
livre de protocoles ARPA-Internet [1].

2. VUE D'ENSEMBLE
Dans cette section, l'historique, la terminologie, et le modle FTP sont traits.
Les termes dfinis dans cette section sont seulement ce qui ont une signification
particulire pour FTP. Certaines terminologies sont trs spcifiques au modle FTP;

RFC959

certains lecteurs prfreront passer immdiatement la dfinition du modle FTP,

quitte revoir la terminologie par la suite.
2.1. HISTORIQUE
FTP a subi une grande volution au fil des ans. L'appendice III est une
compilation chronologique des RFC se rapportant FTP. Elle inclue la premire
proposition de mcanisme de transfert de fichiers de 1971 qui avait t dveloppe
pour une application sur les htes du M.I.T. (RFC 114), plus des commentaires et
discussions dans la RFC 141. La RFC 172 proposait un protocole de niveau
utilisateur pour le transfert de fichiers entre ordinateurs (y compris des terminaux
IMPs). Une rvision de celui-ci (RFC 265), redonnait un tat du FTP pour volution
ultrieure, tandis que la RFC 281 suggrait encore d'autres modifications. L'usage
d'une transaction "Set Data Type" a t propose dans la RFC 294 en Janvier 1982.
La RFC 354 a rendu les RFC 264 et 265 obsoltes. Le File Transfer Protocol tait
dsormais dfini comme un protocole de transfert de fichiers entre des htes d'un
ARPANET, et dont la fonction premire tait dfinie comme le transfert efficace et
fiable entre des htes pour profiter de l'utilisation d'une capacit de stockage de
donnes distante. La RFC 385 apporte un correctif certaines erreurs, dveloppe
certains points, et ajoute certaines notions au protocole, tandis que la RFC 414
dfinit le rapport d'tat sur le serveur de travail et les "clients" FTP. La RFC 430 de
1973, (parmi d'autres trop nombreuses pour tre mentionnes toutes) donnait des
commentaires supplmentaires quant FTP. Finalement, une documentation
"officielle" FTP a t publie sous la rfrence RFC 454.
Depuis Juillet 1973, des changements considrables sont intervenus, mais la
structure globale est reste la mme. La RFC 542 a t publie comme une
nouvelle spcification "officielle" pour reflter certains changements. Cependant, de
nombreuses implmentations bases sur l'ancienne spcification n'taient pas
remises jour. En 1974, les RFC 607 et 614 apportent de nouveaux commentaires
propos de FTP. La RFC 624 propose des changements nouveaux et autres
modifications mineures. En 1975, la RFC 686 intitule, "Leaving Well Enough Alone"
tait une discussion sur les diffrences entre toutes les anciennes versions de FTP
et la dernire en date. La RFC 691 est une rvision mineure de la RFC 686,
concernant les possibilits d'impression de fichiers.
Motive par le passage du NCP (Network Communication Protocol) TCP
comme protocole sous-jacent, un phoenix est ren partir de tous les efforts cidessus par la RFC 765 comme une nouvelle spcification de FTP base sur le
protocole rseau TCP.
Cette dition de la spcification FTP est crite pour corriger quelques erreurs
mineures de la RFC 765, tout en tendant les explications de certaines
fonctionnalits du protocole, et enfin en ajoutant la dfinition de quelques
commandes supplmentaires. En particulier, les nouvelles commandes optionnelle
suivantes sont inclues dans cette dition de la spcification:
CDUP - Change to Parent Directory
SMNT - Structure Mount

RFC959

STOU - Store Unique

RMD - Remove Directory
MKD - Make Directory
PWD - Print Directory
SYST - System
Cette spcification est compatible avec la version prcdente. Un programme
implment conformment la prcdente spcification devrait naturellement tre
conforme la prsente.
2.2. TERMINOLOGIE
ASCII
Le jeu de caractres ASCII est celui dfini par l'ARPA-Internet Protocol
Handbook. Pour FTP, les caractres ASCII sont dfinis comme la moiti de
l'ensemble donne par un codage huit bits (le bit de poids fort est toujours 0).
Contrle d'accs
Le contrle d'accs dfinit les privilges utilisateur ncessaires pour utiliser un
systme, et pour accder des fichiers dans ce systme. Le contrle d'accs est
ncessaire pour viter un usage accidentel ou non autoris de ressources fichiers. Il
est dans les prrogatives d'un processus serveur FTP d'invoquer ce contrle
d'accs.
Tailles d'octets
Deux tailles d'octets intressent FTP: la taille des octets logiques du fichier, et la
taille utilise pour la transmission des donnes. La taille d'octet pour le transfert est
toujours de 8 bits. Cette taille de transfert n'est pas ncessairement l'unit
d'enregistrement logique du fichier dans le systme, ni la taille des units logiques
permettant l'interprtation des structures de donnes.
Canal de contrle
Le chemin de communication entre le USER-PI et le SERVER-PI pour l'change
de commandes et de rponses commandes. Cette connexion utilise le protocole
Telnet.
Canal de donnes
Une connexion bidirectionnelle (full duplex) sur laquelle les donnes sont
transfres, dans un mode et sous un type particuliers. Les donnes transfres
peuvent tre une partie d'un fichier, un fichier entier, ou plusieurs fichiers. Cette

RFC959

connexion s'tablit entre un SERVER-DTP et un USER-DTP, ou entre deux

SERVER-DTPs.
Port de donnes
Un processus de transfert passif "coute" sur le port de donnes un ordre de
connexion de la part d'un processus de transfert actif mis dans le but d'ouvrir un
canal de donnes.
DTP
Le processus de transfert de donnes DTP (data transfer process) procde
l'tablissement et la gestion de la connexion. Un DTP peut tre passif ou actif.
End-of-Line
La squence de fin-de-ligne qui dfinit la sparation entre deux lignes
d'impression. Cette squence est en gnral compose d'un Retour Chariot (CR =
Carriage Return), suivi d'un saut de ligne (LF = Line Feed).
EOF
La condition end-of-file dtermine la fin du fichier en cours de transfert.
EOR
La condition end-of-record marque la fin d'un enregistrement de donnes en
cours de transfert.
correction d'erreur
Une procdure qui permet un utilisateur de se rcuprer suite certaines
erreurs telles qu'une faute du systme serveur ou du processus de transfert luimme. Pour FTP, la correction d'erreurs ncessitera un redmarrage de la
transmission d'un fichier partir d'un point de contrle donn.
Commandes FTP
Un ensemble de commandes comprenant le contrle des informations transitant
entre le USER-FTP et le SERVER-FTP.
file
Une suite ordonne (squentielle) de donnes informatiques (y compris des
programmes), d'une longueur arbitraire, et dfinies parfaitement par un "chemin
d'accs".
mode
Le mode dans lequel les donnes doivent tre transmises. Le mode dfinit le
format des donnes pendant la transmission, y compris les conditions EOR et EOF.
Les modes de transfert dfinis par FTP sont dcrits dans la section traitant des
Modes de Transmission.

RFC959

NVT
Le Network Virtual Terminal dfini par le protocole Telnet.
NVFS
Le Network Virtual File System. Un concept qui dfinit un systme de fichiers
standard vu travers le rseau utilisant des conventions standardises de
commandes et de syntaxe de noms de chemins d'accs.
page
Un fichier peut tre structur comme un ensemble de parties indpendantes
appeles pages. FTP supporte la transmission de fichiers discontinus comme une
suite de pages indexes indpendantes.
Chemin d'accs
Le chemin d'accs est dfini comme la chane de caractres qui doit tre
prsente par un utilisateur un systme de fichier pour localiser une ressource. Le
chemin d'accs contient normalement une indication de l'unit logique et/ou des
noms de rpertoires, et enfin un nom de fichier. FTP ne spcifie aucune convention
particulire pour le chemin d'accs. Chaque utilisateur devra se conformer aux
conventions utilises sur les systmes de fichiers impliqus dans le transfert.
PI
Le Protocol Interpreter (interprteur de protocole). Les cts serveur (SERVER)
et utilisateur (USER)
d'un protocole ont des "rles" distincts implments
respectivement dans un SERVER-PI et un USER-PI.
enregistrement
Un fichier accs squentiel peut tre structur comme un certain nombre de
portions contigus appels enregistrements. Les structures en Enregistrements sont
supports par FTP bien qu'un fichier n'ait nul besoin d'tre organis de cette faon.
rponse
Une rponse est un acquittement ou une dngation envoye par un serveur
l'utilisateur via la connexion de contrle en rponse une commande FTP. La forme
gnrale d'une rponse est un code de rsultat (pouvant tre un code d'erreur)
suivi d'une chane de caractres. Les codes sont destination d'agents logiciels, le
texte est plus naturellement destin des utilisateurs humains.
SERVER-DTP
Le processus qui transmet les donnes, dans son tat "actif" normal, tablit le
canal de donnes sur le port "en coute". Il tablit des paramtres pour le transfert
et le stockage, et transfre les donnes sur commande de son PI. Le DTP peut
entrer dans un tat "passif" pour attendre, plutt qu'initier une communication.

RFC959

Processus serveur FTP

Un processus ou ensemble de processus qui prennent en charge la fonction de
transfert de fichiers en coopration avec un processus USER-FTP et, certainement
un autre serveur. La fonction rassemble un interprteur de protocole (PI) coupl
un processus de transfert de donnes (DTP).
SERVER-PI
L'interprteur de protocole serveur "coute" sur le Port L une communication
arrivant d'un USER-PI et tablit la connexion pour le canal de contrle. Il reoit par
celui-ci les commandes FTP de l'USER-PI, y rpond, et pilote le SERVER-DTP.
type
Le type de reprsentation de donnes utilis pour la transmission et le stockage.
Le type implique certaines diffrences entre le temps d'enregistrement et le temps
de transfert. Les types de reprsentation de donnes dfinis dans FTP sont dcrits
dans la Section traitant de l'tablissement des canaux de donnes.
Utilisateur (USER)
Une personne ou un processus sous contrle d'une personne dsirant obtenir
des fichiers distants par transfert. L'utilisateur "humain" peut directement agir en
interactivit avec un processus SERVER-FTP, mais le passage par un processus
USER-FTP est conseill dans la mesure o le protocole FTP a t conu sur un
concept d'automate.
USER-DTP
Le processus de transfert de donnes "coute" le port de donnes en attendant
la connexion un processus SERVER-FTP. Si deux serveurs transfrent des
donnes entre eux, le processus USER-DTP est inactif.
Processus USER-FTP
Un ensemble de processus et de fonctions incluant un interprteur de protocole,
un processus de transfert de donnes et une interface utilisateur par laquelle la
fonction de transfert de fichier peut tre effectue en coopration avec un ou
plusieurs processus SERVER-FTP. L'interface utilisateur met disposition de
l'utilisateur un langage local de commande-rponse.
USER-PI
L'interprteur de protocole utilisateur instaure le canal de contrle via son port U
avec le processus SERVER-FTP, met des commandes FTP, et gouverne le USERDTP si ce dernier est impliqu dans le processus de transfert.

RFC959

2.3. LE MODELE FTP

Avec les dfinitions ci-dessus l'esprit, le modle suivant (montr en Figure 1)
peut tre explicit pour la mise en oeuvre d'un service FTP.
------------|/---------\|
||
User ||
-------||Interface|<--->| User |
|\----^----/|
----------------|
|
|
|/------\| Commandes FTP |/----V----\|
||Server|<---------------->|
User ||
|| PI ||
Rponses FTP ||
PI
||
|\--^---/|
|\----^----/|
|
|
|
|
|
|
-------|/--V---\|
Connexion
|/----V----\|
-------| File |<--->|Server|<--------------->|
USER
|<--->| File |
|System|
|| DTP ||
Data
||
DTP
||
|System|
-------|\------/|
|\---------/|
-----------------------------

SERVER-FTP

USER-FTP

NOTES: 1. La connexion de donnes peut tre utilise dans les deux directions.
2. Il n'est pas ncessaire que le canal de donnes soit maintenue en permanence.

Figure 1 Modle d'usage de FTP

Dans le modle dcrit en Figure 1, l'interprteur de protocole utilisateur (USERPI) instaure le canal de contrle. Ce circuit de communication utilise le protocole
Telnet. A l'instauration de cette connexion, des commandes FTP standard sont
gnres par le USER-PI et transmises au processus serveur via le canal de
contrle. (L'utilisateur pourra nanmoins tablir une liaison de contrle directe avec
le SERVER-FTP, partir d'un terminal TAC par exemple, et gnrer les commandes
standard indpendamment, en se substituant au processus USER-FTP). Des
rponses standardises sont mises en retour par le SERVER-PI au USER-PI via le
canal de contrle alors tablie.
Les commandes FTP spcifient les paramtres du canal de donnes (port de
donnes, mode de transfert, type pour la reprsentation, et structure des donnes)
ainsi que la nature du fonctionnement des systmes de fichiers (enregistrement,
lecture, ajout, suppression, etc.). Le USER-DTP ou son dlgu se mettra en
"coute" sur le port de donnes spcifi, et le serveur instaurera le canal de
donnes et effectuera le transfert de fichiers selon les paramtres spcifis. Il doit
tre not que le port de donnes n'est pas ncessairement sur le mme hte que
celui qui a mis les premires commandes FTP par son canal de contrle, bien que
l'utilisateur ou le USER-FTP doive continuer assurer "l'coute" sur le port spcifi.
Il doit tre ici signal en outre que le canal de donnes mis en place peut servir
simultanment la lecture et l'criture de donnes.
Une autre situation peut consister en un utilisateur qui souhaite transfrer des
fichiers entre deux htes, les deux tant des htes distants diffrents de celui de

RFC959

l'utilisateur. L'utilisateur tablit alors un canal de contrle vers chacun des deux
serveurs et utilise ces canaux pour crer un canal de donnes entre ces deux htes.
De cette faon, les informations de contrle passent par le USER-PI bien que les
donnes soient transmis ente deux processus serveurs de transfert. Ce qui suit est
un modle de cette interaction entre serveurs.
Contrle
-----------Contrle
---------->| USER-FTP |<----------|
| USER-PI |
|
|
|
"C"
|
|
V
-----------V
--------------------------| SERVER-FTP |
canal de donnes
| SERVER-FTP |
|
"A"
|<---------------------->|
"B"
|
-------------- Port (A)
Port (B) --------------

Figure 2
Le protocole demande ce que les canaux de contrle soient ouvert tant que
dure le transfert de donnes. Il est de la responsabilit de l'utilisateur de demander
la fermeture des canaux de contrle lorsque l'utilisation du service FTP est termine.
C'est nanmoins le processus serveur qui prend en charge la rupture. Le serveur
peut arrter un transfert de donnes si le canal de contrle est coup sans
commande pralable.
Relations entre FTP et Telnet:
FTP s'appuie sur le protocole Telnet pour le dialogue du canal de contrle. Ceci
est effectif en deux sens: premirement, le USER-PI ou le SERVER-PI devront
suivre les rgles du protocole Telnet directement dans leur propres procdures; ou
bien, le USER-PI ou le SERVER-PI peuvent faire appel un module Telnet existant
et disponible dans le systme d'exploitation.
La facilit d'implmentation, les principes de rutilisabilit, et la programmation
modulaire font pencher en faveur de la deuxime solution. L'efficacit et
l'indpendance vis vis de la plate-forme sont des argument en faveur de la
premire. En pratique, FTP n'utilise qu'un tout petit sous ensemble du protocole
Telnet, et de ce fait, la premire approche n'induit pas un travail de programmation
insurmontable.

3. FONCTIONS DE TRANSFERT DE DONNEES

Seul le canal de donnes permet le transfert effectif des fichiers. La canal de
contrle n'est utilis que pour le contrle des commandes, qui indiquent les
fonctions qui doivent tre excutes, ainsi que les rponses ces commandes (voir
la Section traitant des Rponses FTP). Plusieurs commandes concernent le transfert
de donnes entre htes. Ces commandes de transfert incluent la commande MODE
qui spcifie comment les bits de donnes doivent tre transmis, ainsi que les
commandes STRUcture et TYPE, qui sont utilises pour dfinir la manire avec
laquelle sont reprsentes les donnes. La transmission et la reprsentation sont

RFC959

10

des notions indpendantes. Cependant le mode de transmission "Stream" reste

dpendant des attributs de structure des fichiers et si le mode de transmission
"Compressed" est utilis, la nature des octets de remplissage dpendra de la
reprsentation des donnes utilise.
3.1. REPRESENTATION DES DONNEES ET STOCKAGE
Les donnes sont transfres partir d'un espace de stockage dans l'hte
metteur vers l'espace de stockage de l'hte rcepteur. Il est souvent ncessaire
d'effectuer certaines transformations sur les donnes du fait de la diffrence de la
reprsentation de ces dernires dans deux systmes de nature diffrente. par
exemple, le format NVT-ASCII est stock sous diverses reprsentations selon le
systme. Les DEC TOPS-20 enregistrent gnralement le format NVT-ASCII sous la
forme de cinq caractres ASCII codes sur 7 bits, dans un mot de 36-bit cal sur la
gauche. Les mainframes IBM enregistre ce mme format sous forme de codes
EBCDIC sur 8 bits. Le systme Multics stocke le format NVT-ASCII sous la forme de
quatre caractres sur 9-bits dans un mot de 36-bits. Il est souhaitable de convertir
les caractres entre les diverses reprsentation du format NVT-ASCII lorsque des
transmissions sont effectues entre systmes distincts, en passant par une
reprsentation standard. Les sites metteurs et rcepteurs devront effectuer les
transformations ncessaires entre la reprsentation standard commune et leur
propre reprsentation interne.
Un autre problme de reprsentation apparat lors du transfert de donnes
binaires (codes non assimilables du texte) entre deux systmes travaillant avec
des largeurs de mots distinctes. La faon dont l'metteur envoie les donnes n'est
pas toujours exprime explicitement, pas plus que la faon dont le rcepteur les
stocke. Par exemple, lors de la transmission de "mots" de 32-bits partir d'un
systme 32-bits vers un systmes fonctionnant en 36-bits, il peut tre souhaitable
(pour des raisons de performance) de stocker les mots de 32-bits cals droite du
mot de 36-bits du systme rcepteur. Dans tous les cas, l'utilisateur doit avoir accs
l'option qui lui permettra de spcifier la reprsentation des donnes, et les
transformations ncessaires. Il doit tre not que FTP n'admet qu'un nombre limit
de formats de donnes. Les transformations en dehors du contexte limit propos
par FTP devront tre prises en charge par l'utilisateur.
3.1.1. TYPES DE DONNEES
Les reprsentations de donnes sont gres dans FTP par la spcification par
l'utilisateur d'un type. Ce type peut tre implicite (comme pour l'ASCII ou l'EBCDIC)
ou explicite (comme le type Local), et dfinit une taille de mot dont l'interprtation
correspond celle de la "taille de mot logique". Notez que ceci n'a rien voir avec
la taille du mot utilis dans la transmission dans le canal de donnes, appele la
"taille de transfert", la confusion entre les deux notions devant tre soigneusement
vite. Par exemple, le format NVT-ASCII a une taille logique de 8 bits. Si le type est
le type Local, alors la commande TYPE aura un deuxime paramtre obligatoire
spcifiant cette taille logique. La taille de transfert est toujours gale 8 bits.

RFC959

11

3.1.1.1. TYPE ASCII

C'est le type par dfaut et doit tre reconnu par toutes les implmentations FTP.
Il est l'origine mis en place pour le transfert de fichiers texte, sauf lorsque les deux
htes considreront que le type EBCDIC convient mieux.
L'metteur convertit les donnes depuis la reprsentation interne des caractres
vers le format 8-bit NVT-ASCII standardis (voir les spcifications Telnet). Le
rcepteur convertira cette reprsentation standard en sa propre reprsentation
interne.
Conformment au standard NVT, la squence <CRLF> doit tre utilise chaque
fois que ncessaire pour marquer une fin de ligne de texte. (Voir la discussion
propos des structures de fichiers la fin de la Section traitant des Reprsentations
de donnes et stockage). Le fait d'utiliser la reprsentation standard NVT-ASCII en
8 bits signifie que les donnes doivent tre interprtes selon des "mots" de 8-bits.
Les valeurs du paramtre Format pour les types ASCII et EBCDIC sont dtailles ciaprs.
3.1.1.2. TYPE EBCDIC
Ce type est destin des transferts plus efficaces entre deux htes qui admettent
l'EBCDIC comme standard de reprsentation interne des caractres de texte.
Pour la transmission, les donnes sont reprsentes comme des codes EBCDIC
sous 8-bits. Le codage des caractres est la seule diffrence qui distingue les
spcifications des types EBCDIC et de l'ASCII.
La fin de ligne (EOL quivalent la squence CRLF) (par opposition la fin
d'enregistrement (EOR)voir la discussion sur les structures) sera rarement
utilise avec le type EBCDIC pour des raisons de reconnaissances de structure,
mais lorsqu'une telle information est ncessaire, le caractre <NL> pourra tre
utilis.
3.1.1.3. TYPE IMAGE
Les donnes sont transmises comme un champ de bits continu qui, pour le
transfert, sont "empaquets" dans des structures de transfert de 8-bits. Le site
rcepteur doit quant lui enregistrer les donnes comme un champ continu de bits.
La structure du systme de stockage ncessite parfois l'utilisation de bits de
"bourrage" pour le fichier (ou pour chaque enregistrement, dans le cas d'un fichier
structur sur une base d'enregistrements logiques) tablissant ainsi un "calage" des
donnes sur une frontire conventionnelle (octet, mot ou bloc). Ce bourrage doit
toujours tre fait par des bits nuls, peut intervenir la fin d'un fichier (ou la fin de
chaque enregistrement) et il doit exister un moyen de les identifier afin qu'ils
puissent tre limins lorsque le fichier est rcupr. La transformation de bourrage
devra faire l'objet d'une large et claire documentation pour permettre tout
utilisateur d'implmenter les traitements ncessaires la reconstitution du fichier
original dans le site rcepteur.

RFC959

12

Le type image est destin un transfert et un enregistrement optimal de fichiers

binaires. Il est recommand que ce type soit reconnu par toutes les implmentations
FTP.
3.1.1.4. TYPE LOCAL
Les donnes sont transfres par mots logiques dont la taille est ncessairement
spcifie par un second paramtre obligatoire, "Byte size". La valeur du paramtre
"Byte size" doit tre un entier dcimal; il n'existe pas de valeur par dfaut. La taille
de mot logique n'est pas ncessairement la mme que celle du mot de transfert. Si
les deux tailles sont diffrentes, alors les mots logiques devront tre empaquets
selon une trame continue de bits, indpendamment des limites formes par le mot
de transfert et avec le bourrage ncessaire ajout la fin.
Lorsque les donnes sont reues sur l'hte rcepteur, elles seront transformes
selon la taille des mots logiques du fichier transfr et la taille de la reprsentation
interne du rcepteur. Cette transformation doit tre rversible (c--d, un fichier
identique doit pouvoir tre rcupr dans l'autre sens avec les mmes paramtres)
et devra faire l'objet d'une documentation prcise et complte de la part des
implmenteurs FTP.
Par exemple, un utilisateur envoyant des nombres virgule flottante en 36-bits
vers un hte travaillant en 32-bits pourrait envoyer ces donnes sous le type Local
selon une taille Locale de 36. L'hte rcepteur pourrait par exemple rcuprer ces
mots logiques et les enregistrer d'une faon ce qu'ils puissent tre manipuls
facilement; dans notre exemple, une solution consiste stocker les mots de 36-bits
dans un double mot de 64-bits.
Autre exemple : le cas d'une paire d'htes travaillant sous 36-bits pourraient se
communiquer des donnes en utilisant le TYPE L 36. Les donnes seraient alors
transmises empaquetes dans le format 8-bits de la transmission, 9 octets transmis
tant ncessaires pour transfrer deux "mots" entre deux tels systmes.
3.1.1.5. CONTROLE DE FORMAT
Les types ASCII et EBCDIC prennent un second paramtre (optionnel); il indique
quel type de contrle de format vertical , s'il existe, est associ un fichier. Les
types de reprsentation de donnes suivantes sont dfinis dans FTP:
Un fichier caractres peut tre transfr vers un hte dans l'un des trois buts
suivants : pour impression, pour stockage et rcupration ultrieure, ou pour
traitement. Si un fichier est envoy pour impression, l'hte rcepteur doit connatre
comment le contrle de format vertical format est reprsent. Dans le second cas, il
doit tre possible d'enregistrer un fichier pour usage ultrieur dans sa forme
originale. Enfin, il doit tre possible de dplacer un fichier d'un hte vers un autre, et
de traiter ce fichier sur l'hte rcepteur sans ennui. Un format ASCII ou EBCDIC
lmentaire ne satisfait pas ces conditions. De ce fait, un second paramtre a t
adjoint au paramtre de type, pour coder trois situations possibles :

RFC959

13

3.1.1.5.1. NON PRINT

C'est le format par dfaut utiliser si le second paramtre (format) est omis. Le
format NON-PRINT doit tre accept par toutes les implmentations de FTP.
Le fichier ne contient pas ncessairement des informations de contrle vertical.
Si un tel fichier est pass un processus d'impression, ce dernier devra prendre des
valeurs standard pour les espaces et les marges. Ce format sera usuellement utilis
pour des fichiers destins du traitement de donnes ou tre juste stocks.
3.1.1.5.2. TELNET FORMAT CONTROLS

Le fichier contient des codes ASCII/EBCDIC de contrle de format vertical (c-d., <CR>, <LF>, <NL>, <VT>, <FF>) qu'un processus d'impression peut
immdiatement interprter. <CRLF>, dans cet ordre prcis, signale une fin de ligne.
3.1.1.5.2. CARRIAGE CONTROL (ASA)

Le fichier contient des caractres de contrle de format vertical conformes

l'ASA (FORTRAN). (Voir RFC 740 Appendice C; et "Communications of the ACM,
Vol. 7, No. 10, p. 606, October 1964".) Dans une ligne, ou un enregistrement au
format conforme au standard ASA, le premier caractre ne doit pas tre imprim. Au
lieu de cela, il doit tre utilis pour dterminer le mouvement vertical du papier
effectuer avant que l'impression du reste de l'enregistrement ne soit effectu.
Le standard ASA spcifie les caractres de contrle suivants :
Caractre
Espace
0
1
+

Espacement vertical
Avance le papier d'une ligne
Avance le papier de deux lignes
Avance le papier en dbut de la
page suivante
Pas de mouvement (surimpression)

Il doit exister un moyen simple pour un processus d'impression de dtecter la fin

d'une entit structurale. Si un fichier est enregistr selon une structure
d'enregistrement (voir ci-dessous), il n'y a aucun problme; les enregistrements
seront explicitement marqus pendant le transfert et l'enregistrement. Si le fichier n'a
aucune structure d'enregistrement sous-jacente, la squence de fin de ligne
<CRLF> est utilise pour sparer les lignes d'impression, bien que l'effet produit par
ces deux caractres soit masqu par la signification des contrles ASA.
3.1.2. STRUCTURES DE DONNEES
En plus des diffrents types de reprsentation de donnes, FTP permet que la
structure d'un fichier soit explicite. Trois structures de fichiers sont connues de
FTP:

RFC959

14

Structure fichier,

dans laquelle le fichier est considr comme une

squence continue d'octets contigus, sans structure sousjacente induite.

Structure-enregistrement, dans laquelle un fichier peut tre vu comme une

squence d'enregistrements,
Structure-page,

dans laquelle le fichier peut tre considr comme une

suite de pages indpendantes indexes.

La "structure-fichier" est la structure par dfaut et doit tre considre si la

commande STRUcture n'a pas t utilise, bien que les deux structures "fichier" et
"enregistrement" dussent tre acceptes pour les fichiers "texte" (c--d., fichiers
affichant un TYPE ASCII ou EBCDIC) par toutes les implmentations FTP. La
structure d'un fichier affectera la fois la faon de transmettre le fichier (voir la
Section traitant du Mode de Transmission) et l'interprtation de l'enregistrement sur
le support de stockage.
La structure "naturelle" d'un fichier dpend de l'hte qui l'enregistre. Du code
source sera gnralement enregistr sur un mainframe IBM comme une suite
d'enregistrements de longueur fixe, et au contraire comme un flux de caractres
spar en lignes par une squence <CRLF> par exemple, sur un DEC TOPS-20. Si
le transfert de fichiers entre des sites aussi diffrents s'avre utile, il doit exister un
moyen de diffrencier les stratgies de codage de chaque ct de la transaction.
Entre des sites naturellement orients vers une structure "fichier" et d'autres
utilisant naturellement une structure "enregistrements", on pourra rencontrer des
problmes transfrer un fichier bas sur une des deux structures vers un systme
s'appuyant sur l'autre. Si un fichier texte organis en "enregistrements" est envoy
vers un hte naturellement orient "fichier", alors ce dernier devra appliquer une
transformation interne pour l'enregistrer. Cette transformation est videmment utile,
mais doit tre de plus totalement rversible pour assurer une rcupration "
l'identique".
Dans le cas inverse de fichiers de type "fichier", vers un hte travaillant en
structures "enregistrement", se pose le problme de savoir quel sera le critre utilis
pour recomposer le fichier selon une structure d'enregistrements. Si cette division
est ncessaire, l'implmentation FTP devrait utiliser la squence fin-de-ligne,
<CRLF> pour l'ASCII, ou <NL> pour les fichiers texte EBCDIC, comme dlimiteur
d'enregistrement. Si une implmentation FTP adopte cette technique, elle doit tre
prte pouvoir procder la transformation inverse au cas o le fichier devrait tre
rapatri vers son support original de type "fichier".
3.1.2.1. STRUCTURE FICHIER
La structure "fichier" est considrer par dfaut si la commande STRUcture n'est
pas employe.
Dans une structure-fichier, il n'y a en fait aucune structure sous-jacente et le
fichier doit tre considr comme une suite continue de caractres.

RFC959

15

3.1.2.2. STRUCTURE ENREGISTREMENT

La structure-enregistrement doit tre accepte pour tout fichier "texte" (c--d.,
fichiers affichant un TYPE ASCII ou EBCDIC) par toutes les implmentations FTP.
Le fichier est alors reconnu comme une suite ordonne d'enregistrements
successifs.
3.1.2.3. STRUCTURE PAGINEE
Pour transmettre des fichiers discontinus, FTP dfinit une structure en pages.
Les fichiers de ce type sont aussi connus comme des "fichiers accs alatoire" par
opposition aux "fichiers accs squentiel". Dans ces fichiers, il existe souvent un
certain nombre d'informations annexes, associes au fichier lui mme (ex., un
descripteur du fichier), ou l'une de ses parties (ex., des contrles d'accs aux
diffrentes pages), ou les deux. Pour FTP, chaque section squentielle d'un tel
fichier est appele page.
Afin d'exploiter des tailles et des attributs de page diffrents, chaque page est
envoye avec une en-tte. L'en-tte contient une slection des paramtres suivants:
Header Length
(Longueur d'en-tte)

Page Index
(Index de page)

Data Length
(Longueur des donnes)

Page Type
(Type de page)

0 = Last Page
(Dernire page)

1 = Simple Page
(Page simple)

2 = Descriptor Page
(Descripteur)

3 = Access Controlled Page

(Page accs contrle)

Champs optionnels

RFC959

Le nombre d'octets logiques dans l'en-tte y compris

lui-mme. La longueur minimale d'en-tte est de 4.
L'index de cette section du fichier (numro de page
logique). Ceci n'est pas le numro de page
transmise, mais plutt l'index qui permet d'identifier
cette page.
Le nombre d'octets logiques dans la page. La
longueur de page peut tre nulle.
Le type de page dont il s'agit. Sont dfinis les types
qui suivent :
Utilis pour indiquer la fin d'une transmission
structure en pages. La longueur d'en-tte de cette
page est 4, et la longueur de page ncessairement 0.
Type d'une page normale du fichier ne disposant pas
d'information de contrle hirarchique. La longueur
d'en-tte doit tre de 4.
Type utilis pour transmettre en un bloc toute la
description externe du fichier.
Ce type inclut un paramtre supplmentaire destin
l'accs des pages organises selon une structure
hirarchique plusieurs niveaux. L'en-tte est de
longueur 5.
Des champs optionnels peuvent tre ajouts pour
fournir une information spcifique sur la page ellemme, par exemple un contrle d'accs individuel.

16

Tous les champs sont de longueur gale un octet logique. La taille de l'octet
logique est dfini par le paramtrage de la commande TYPE. Voir l'Appendice I pour
plus de dtails.
Note d'avertissement concernant les paramtres : un fichier doit tre tlcharg,
enregistr et rcupr avec les mmes paramtres si l'on souhaite rcuprer une
version identique l'original. A l'inverse, les implmentations de FTP doivent
renvoyer un fichier identique l'original si les paramtres utiliss pour
l'enregistrement et la rcupration du fichier sont identiques.
3.2. ETABLISSEMENT DU CANAL DE DONNEES
Le mcanisme de transfert de donnes consiste en l'tablissement d'un canal de
donnes entre les ports appropris et de ce fait en le choix des paramtres de
transfert. Le USER et SERVER-DTP disposent tous deux d'un port de donnes par
dfaut. Le port "donnes" par dfaut du processus utilisateur est identique celui
utilis pour le contrle de la connexion (c--d., U). Le port "donnes" par dfaut du
processus serveur est le port adjacent celui utilis pour le contrle de la connexion
(c--d., L-1).
La taille de l'octet transfr est toujours de 8-bits. Cette taille n'a de signification
que pendant le processus effectif de transfert des donnes; elle ne prsume en rien
de la taille des units logiques ncessaires pour reprsenter les donnes
l'intrieur du systme.
Le processus de transfert de donnes l'tat passif (ceci peut tre un USERDTP ou un deuxime SERVER-DTP) devra "couter" son port de donnes avant de
pouvoir mettre une commande de requte de transfert. La commande FTP de
requte de transfert dtermine le sens du transfert de donnes. Le serveur, sur
rception de la requte, tablira la connexion au port "donnes". Lorsque cette
dernire est tablie, le transfert de donnes dbute entre les deux DTP, et le
SERVEUR-PI met une confirmation destination du USER-PI.
Toute implmentation FTP doit accepter l'utilisation des ports par dfaut, et seul
le USER-PI peut invoquer une migration de la connexion vers des ports non
standards.
Le processus utilisateur peut demander l'usage d'un autre port "donnes" par
l'intermdiaire de la commande PORT. Par exemple, un utilisateur demande
l'impression d'un fichier sur une imprimante en ligne TAC lequel fichier doit tre
rcupr depuis un troisime hte. Dans le dernier cas, le USER-PI tablit un canal
de contrle avec les deux SERVER-PI. Il est alors demand un serveur (par une
commande FTP) "d'couter" une connexion qu'une troisime entit va initier. Le
USER-PI met destination d'un des SERVER-PI une commande PORT indiquant
le port "donnes" de l'autre connexion. Enfin, il est envoy aux deux serveurs les
commandes de transfert appropries. La squence exacte de commandes et de
rponses envoyes entre le contrleur de l'utilisateur et les serveurs est dfinie
dans la Section traitant des Rponses FTP.
En gnral, il est de la responsabilit des serveurs de maintenir le canal de
donnes actifde l'initialiser et de le clore. L'exception cette rgle est lorsque le

RFC959

17

USER-DTP envoie des donnes dans un mode qui implique que la fin de fichier
(EOF) correspond la fermeture de la transmission. Le serveur DOIT fermer le
canal de donnes sous les conditions suivantes :
1. Le serveur termin la transmission de donnes dans un mode ou la fin de
fichier est signale par une fermeture du canal.
2. Le serveur reoit une commande ABORT de l'utilisateur.
3. La spcification du port "donnes" est change par une commande de
l'utilisateur.
4. Le canal de contrle est ferm par une procdure normale ou pour toute autre
raison.
5. Une condition d'erreur irrcuprable est apparue.
Dans tous les autres cas la fermeture est une prrogative du serveur, l'exercice
de la quelle doit tre signale au processus utilisateur par un code de rponse 250
ou 226 seulement.
3.3. GESTION DU CANAL DE DONNEES
Ports de donnes standard : Toute implmentation FTP doit accepter l'usage des
ports de donnes standard, seul un USER-PI pouvant initialiser un canal sur un port
autre que standard.
Ngociation des ports autres que par dfaut : Le USER-PI peut spcifier un port
de donnes non standard "viser" par le serveur via la commande PORT. Le
USER-PI peut demander au serveur de s'identifier au serveur "cible" exprim par ce
port non standard via la commande PASV. La connexion tant dfinie comme une
paire d'adresse, ces deux actions sont suffisantes pour obtenir chaque fois un
canal de donnes diffrent, bien qu'il soit admis de pouvoir dclencher deux fois ces
commandes pour raccorder deux ports non standard chaque extrmit d'un canal
de donnes.
Rutilisation du canal de donnes : Lorsque le mode de transfert en "flux" est
utilis, la fin de fichier est indique implicitement par une fermeture du canal. Ceci
pose un problme vident lorsque plusieurs fichiers doivent tre transfrs au cours
de la mme session, dans la mesure o TCP doit "bloquer" la connexion qui vient
d'tre utilise pendant un certain temps fix pour des raisons de fiabilit. De ce fait,
une connexion ouverte sous ce mode ne peut pas tre rutilise immdiatement.
On donnera deux solutions ce problme. La premire est de ngocier un autre
canal sur des ports non standard. La premire est de changer le mode de transfert.
Commentaire sur les modes de transfert. Le mode de transfert en "flux" est par
nature non fiable, dans la mesure o il est impossible de dterminer si un canal est
ferm normalement ou non. Les autres modes de transfert (Bloc, Compress) ne
ferment pas le canal aprs transmission du fichier. Le niveau d'encodage de FTP est
suffisant pour que le canal puisse tre "surveill" et que la fin de fichier puisse tre

RFC959

18

dtecte. Ces modes sont donc tout fait exploitables pour la transmission de
multiples fichiers.
3.4. MODES DE TRANSMISSION
La considration suivante prendre en compte pour transfrer des fichiers est le
choix d'un mode de transmission. FTP dfinit trois modes : un qui formate les
donnes est permet de recommencer la transmission si ncessaire; une qui
compresse en plus les donnes pour un transfert plus efficace; et un dernier mode
qui laisse passer les donnes avec le moins d'encodage possible. Dans ce dernier
cas, le mode interagit avec les attributs de structure pour dterminer le type de
traitement. En mode compress, le type de reprsentation dtermine
essentiellement la nature du bourrage.
Tous les transferts de donnes doivent s'achever par la transmission d'une
squence de fin-de-fichier (EOF), la quelle peut tre explicite, ou implicitement
dduite de la fermeture du canal. Pour les fichiers de structure de type
"enregistrement", tous les marqueurs de fin d'enregistrement (EOR) sont explicites,
y compris le dernier. Pour les fichiers transmis selon une structure de pages, la page
de type "last-page" sera utilise pour marquer la fin de la transmission.
NOTE: Dans le reste de cette section, octet signifiera "l'octet de transfert" sauf
mention contraire explicite.
Dans le but d'obtenir un transfert standardis, l'hte metteur devra traduire sa
reprsentation interne d'une fin de fichier ou fin d'enregistrement dans la
reprsentation prconise par le protocole pour le mode de transfert et la structure
de fichier donns, l'hte rcepteur effectuant la transcription duale vers sa propre
reprsentation interne. Le champ de comptage d'enregistrements d'un mainframe
IBM peut ne pas tre reconnu par un autre hte, l'information de fin d'enregistrement
devant alors tre transfr comme un code de contrle deux octets en mode "flux"
ou par marquage de bits dans les descripteurs des modes Bloc ou Compress. La
fin de ligne dans un fichier ASCII ou EBCDIC sans structure d'enregistrement devrait
tre indiqu par une squence <CRLF> ou <NL>. Comme ces transformation
impliquent un travail supplmentaire dans les htes, des systmes identiques ou
similaires s'changeant des fichiers prfreront utiliser un transfert binaire dans un
mode de type "flux".
Les modes de transmission suivants sont reconnus par FTP :
3.4.1. MODE "FLUX"
Les donnes sont transmises comme un flux d'octets. Il n'y a dans ce cas aucune
restriction sur la reprsentation des donnes utilise; Des structures-enregistrement
sont autorises.
Dans un fichier d'enregistrements, les squences EOR et EOF seront toutes
deux marques par un code de contrle deux octets. Le premier octet vaudra
0xFF, le caractre d'chappement. Le second octet aura sont bit de poids faible 1
et des 0 ailleurs pour la marque EOR (le second bit 1 pour la marque EOF); en
somme, l'octet aura la valeur 1 pour l'EOR et 2 pour l'EOF. EOR et EOF peuvent
tre marqu simultanment dans la dernire squence en marquant les deux bits

RFC959

19

dans le mme octet (donc, une valeur 3 pour le dernier enregistrement). Si un octet
de donnes devait avoir la valeur OxFF, il devra tre rpt dans le second octet du
code de contrle.
Si la structure est de type "fichier", la squence EOF sera implicitement marque
par la fermeture du canal. Tous les octets transmis sont donc des octets de
donnes.
3.4.2. MODE BLOC
Le fichier est transmis comme une suite de blocs de donnes prcds d'un ou
plusieurs octets d'en-tte. L'en-tte contient un champ de comptage de blocs, et un
code de description. Le champ de comptage indique la longueur totale du bloc de
donnes en octets, et indique donc le dbut du bloc suivant (il n'y a pas de bits de
bourrage). Le code de description indique : le dernier bloc du fichier (EOF) le
dernier bloc de l'enregistrement (EOR), le marqueur de reprise (voir la Section
traitant de la Rcupration d'Erreurs et Reprise de Transmission) ou de donnes
suspectes (c--d. qu'il est possible que les donnes transfres soient errones et
non fiables). Ce dernier code N'EST PAS destin implmenter une fonction de
contrle d'erreur sous FTP. Il est motiv par la demande de certains sites
d'changer des classes particulires de donnes (ex., donnes sismiques ou
mtorologiques) en dpit d'erreurs locales qui peuvent survenir (telles que des
erreurs de lecture sur des supports magntiques), pour indiquer que certaines
donnes transmises peuvent tre suspectes pour des raisons autres que la
transmission. Des structures-enregistrement sont admises dans ce mode, et toute
forme de reprsentation de donnes peut tre utilise.
L'en-tte consiste en trois octets. Sur ces 24 bits d'information d'en-tte, les 16
bits de poids faible reprsentent le compte d'octets, les 8 bits de poids fort donnent
le code de description selon les dfinitions ci-dessous.
Bloc d'en-tte
+----------------+----------------+----------------+
|
Descripteur |
Compte d'octets
|
|
8 bits
|
16 bits
|
+----------------+----------------+----------------+

Le descripteur est form de bits indicateurs. Quatre codes sont actuellement

reconnus, dont le nombre reprsente la valeur dcimale du masque.

RFC959

20

Codes de description
Valeu Description
r
Le bloc est le dernier d'un enregistrement (EOR
128
en fin de bloc)
Le bloc est le dernier de la transmission (EOF
64
en fin de bloc)
Erreurs probables dans les donnes de ce bloc
32
Le bloc de donnes est le premier d'une reprise
16
Grce cet encodage, plusieurs situations simultanes peuvent tre codes
dans un seul bloc. Autant de bits du descripteur que ncessaire peuvent tre
marqus.
Le marqueur de reprise est mis comme des donnes d'un multiple entier
d'octets de 8-bits reprsentant des caractres imprimables selon le langage utilis
sur le canal de contrle (ex., par dfaut--NVT-ASCII). <SP> (Espace, dans le
langage appropri) ne doit JAMAIS tre employ dans un marqueur de reprise.
Par exemple, pour transmettre un marqueur de reprise de six caractres, la
squence suivante serait mise :
+-----------+-----------+-----------+
|Descripteur|
Compte
|
| code=16 |
= 6
|
+-----------+-----------+-----------+
+-----------+-----------+-----------+
| Marqueur | Marqueur | Marqueur |
|
8 bits |
8 bits |
8 bits |
+-----------+-----------+-----------+
+-----------+-----------+-----------+
| Marqueur | Marqueur | Marqueur |
|
8 bits |
8 bits |
8 bits |
+-----------+-----------+-----------+

3.4.3. MODE COMPRESSE

Trois classes d'informations doivent tre envoyes : des donnes "littrales",
envoyes comme des chanes d'octets; des donnes compresses, consistant en
des octets "rpliqus" ou des octets de bourrage; et des informations de contrle,
mis selon des squences d'chappement deux octets. Si n>0 octets (jusqu' 127)
littraux sont mis, ces n octets doivent tre prcds d'un octet dont le bit de poids
fort est nul, les 7 autres bits contenant ce nombre n.

RFC959

21

Chane d'octets :
1
7
8
8
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
|0| n
| |
d(1)
| ... |
d(n)
|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
^
^
|-------- n octets de donnes---------|

Chane de n octets de donnes d(1),..., d(n)

Le compte n doit tre positif .
Octets rpliqus :
Pour compresser une chane comportant n rpliques de l'octet de donnes d, les
deux octets suivants sont mis :
2
6
8
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|1 0|
n
| |
d
|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+

Chane de bourrage :
Une chane de n octets de bourrage peut tre compresse en seulement deux
octets, dans lesquels l'octet indiquant la valeur de bourrage change selon le type de
reprsentation de donnes. Si le type est l'ASCII ou EBCDIC l'octet de bourrage est
l'espace <SP> (ASCII code 32, EBCDIC code 64). Si le type est Image ou Local la
valeur de bourrage vaut 0.
2 6
+-+-+-+-+-+-+-+-+
|1 1|
n
|
+-+-+-+-+-+-+-+-+

Squence de contrle :
Une squence de contrle est un octet double, dont le premier est le caractre
d'chappement (octet nul) et le deuxime contient les codes de description tels que
dfinis dans le mode Bloc. Le descripteur a la mme signification que dans le mode
Bloc, et s'applique la chane qui le suit.
Le mode compress est particulirement utile pour gagner de la bande passante
lors de transferts de gros volumes de donnes, et ce pour un cot CPU assez faible.
Il peut tre utilis de faon trs efficace pour transmettre des fichiers de sortie
d'impression directement formats.
3.5. RECUPERATION D'ERREUR ET REPRISE DE TRANSMISSION
Il n'existe pas de mcanisme permettant de dtecter des bits perdus ou errons
d'un fichier transfr; ce niveau d'erreur est gr au niveau de TCP. Cependant, une
procdure de reprise est prvue pour protger les utilisateurs de dfaillances
majeures des systmes (incluant le crash d'un hte, d'un processus FTP, ou d'un
protocole rseau sous-jacent).

RFC959

22

La procdure de reprise n'est dfinie que dans les modes de transfert par bloc ou
compress. Elle demande l'metteur des donnes d'envoyer un marquer
particulier dans le flux de donnes incluant des informations de reprise. Ces
informations du marqueur n'ont de signification que pour l'metteur, mais doivent
consister en des caractres imprimables au sens du langage utilis pour le contrle
de la connexion (ASCII ou EBCDIC). Le marqueur peut reprsenter un comptage de
bits, d'enregistrements, ou tout autre information pouvant coder un "point de
contrle". Le rcepteur des donnes, s'il implmente la procdure de reprise, notera
la position de ce point au niveau de l'hte rcepteur, et renvoie cette information
l'utilisateur.
Dans le cas d'une faute systme, l'utilisateur peut alors enclencher la procdure
de reprise en notifiant le point de contrle. L'exemple suivant illustre l'utilisation de
la procdure de reprise.
L'metteur des donnes insre un bloc de marquage appropri dans le flux de
donnes en un point donn. Le rcepteur des donnes marque le point de contrle
dans son systme de fichiers local et indique les derniers points mis et reus
l'utilisateur, soit directement, soit en utilisant la rponse de code 110 du protocole de
contrle (suivant qui est l'metteur). Lors d'une faute systme, l'utilisateur ou le
contrleur requiert un nouveau transfert partir du dernier marqueur en mettant le
bloc de reprise avec ce marqueur comme argument. La commande de reprise est
transmise via le canal de contrle et est immdiatement suivi de la commande (telle
que RETR, STOR ou LIST) qui tait en excution avant la faute systme.

4. FONCTIONS DE TRANFERT DE FICHIERS

Le canal de communication entre le USER-PI et le SERVER-PI est tabli comme
une connexion TCP entre l'utilisateur et le port standard FTP du serveur.
L'interprteur de protocole est responsable de l'mission des commandes FTP et de
l'interprtation des rponses; le SERVER-PI interprte les commandes, envoie les
rponses, et pilote le DTP pour tablir le canal de donnes et transfrer les fichiers.
Si le correspondant du processus de transfert (le processus passif) est un USERDTP, alors celui-ci est lui-mme pilot par l'intermdiaire de l'interprteur de
protocole de l'hte USER-FTP; s'il s'agit d'un second SERVER-DTP, alors son
contrle se fait via son propre PI sur commande du USER-PI. Les rponses FTP
sont dcrites dans la section suivante. Dans la description des quelques
commandes de la section prsente, il nous est apparu utile d'tre explicite sur les
rponses attendre.
4.1. COMMANDES FTP
Le protocole FTP suit les recommandations du protocole Telnet pour toutes les
communications sur le canal de contrle. Comme le langage choisi pour la
communication sous Telnet peut tre une option ngocie, toutes les rfrences
dans les deux prochaines section se font par rapport au "langage Telnet" et le "code
de fin de ligne Telnet" correspondant. De faon courante, on considrera qu'il s'agit
du NVT-ASCII et de la squence respective <CRLF>. Aucune autre spcification du
protocole Telnet ne sera cite ici.

RFC959

23

Les commandes FTP sont des chanes de caractres "Telnet" termines par le
"code de fin de ligne Telnet". Les codes de commande sont eux-mmes des
caractres alphabtiques suivis du caractre <SP> (Espace) si d'autres paramtres
suivent, et Telnet-EOL dans le cas contraire. Les codes et smantique des
commandes sont dcrites dans cette section; la syntaxe dtaille est dcrite dans la
Section traitant des Commandes, les squences de rponse sont explicites dans la
Section traitant du Squencement des Commandes et Rponses, et les scnarios
illustrant l'usage typique d'une commande sont donns en Section traitant des
Scnarios FTP Typiques.
Les commandes FTP peuvent tre divises en commandes de contrle d'accs,
commandes de paramtrage de transfert, et des commandes de service FTP.
Certaines commandes (telles qu'ABOR, STAT, QUIT) peuvent tre mises via le
canal de contrle y compris lorsqu'un transfert est en cours. Certains serveur ne
pourront simultanment grer le canal de contrle et celui de donnes, auquel cas
certaines actions spciales devront tre faites pour attirer l'attention du serveur. La
procdure suivante doit tre employe dans cet ordre:
1. Le systme de l'utilisateur insre un signal "Interrupt Process" Telnet (IP) dans
le flux Telnet.
2. Le systme utilisateur envoie un signal "Synch" Telnet.
3. Le systme utilisateur tente une commande d'avortement (ex., ABOR) dans le
flux de commande Telnet.
4. Le SERVER-PI, aprs rception de "l'IP", inspecte le flux Telnet en attendant
EXACTEMENT UNE commande FTP.
(Sur certains serveurs, cette procdure n'est pas indispensable, mais son
activation ne produira pas d'effets inattendus).
4.1.1. COMMANDES DE CONTROLE D'ACCES
Les commandes qui suivent traitent du paramtrage du contrle d'accs (les codes
numriques de commande sont donns entre parenthses).
USER NAME (USER)

NOM D'UTILISATEUR

Le champ argument est une chane Telnet identifiant l'utilisateur.

L'identifiant de l'utilisateur est celui qui est requis par le serveur pour
permettre l'accs au systme de fichiers de l'hte serveur. Cette commande
est normalement la premire tre envoye ds que le canal de contrle est
mis en place (certains serveurs l'imposent). Des informations d'identification
supplmentaires telles qu'un mot de passe et/ou un nom de compte
utilisateur peuvent tre aussi requis par certains serveurs. Les serveurs
doivent accepter une nouvelle commande USER tout moment en vue de
changer les droits et privilges d'accs, ou le compte. Ceci aura l'effet
d'annuler toute rfrence l'utilisateur, au mot de passe, et au compte
prcdent en recommenant la squence d'ouverture de session depuis le

RFC959

24

dbut. Tous les paramtres de transfert restent cependant inchangs et tout

transfert de fichier en cours se termine normalement avec les anciens
paramtres de session.
PASSWORD (PASS)

MOT DE PASSE

Le champ argument est une chane Telnet indiquant le mot de passe

attribu cet utilisateur. Cette commande doit immdiatement suivre la
commande prcdente, et, sur certains sites, complte les donnes
d'identification de l'utilisateur pour lui permettre un accs au systme de
fichiers. Comme le mot de passe est une information dite "sensible", il est
prfrable de le "masquer" lors de son entre, voire d'en viter l'impression
en clair l'cran. Cependant, il apparat que le serveur n'a aucun moyen de
s'opposer sa divulgation. Il est donc de la responsabilit des USER-FTP
d'viter le stockage explicite du mot de passe et son affichage.
ACCOUNT (ACCT)

COMPTE UTILISATEUR

Le champ argument est une chane Telnet qui spcifie le "compte" de

l'utilisateur. Cette commande n'est pas ncessairement couple une
commande USER, et certains site pourront imposer la spcification d'un
compte l'ouverture de session tandis que d'autre ne le demanderont que
pour des accs spcifiques, par exemple pour enregistrer des fichiers. Dans
ce dernier cas, il est admis que cette commande puisse arriver tout
moment.
Des codes de rponse existent pour diffrencier ces cas pour un
automate : lorsque l'infirmation de compte est requise l'ouverture de
session, la rponse une commande PASSword excute avec succs est
de code 332. Dans l'autre cas o le compte utilisateur n'est pas requis
l'ouverture de session, la rponse donne une commande PASSword
concluante est de code 230; enfin, si le compte utilisateur est requis la
suite d'une commande excute plus loin dans le processus, le serveur
rpondra par un code 332 ou 532 suivant que la commande prcdente est
complte (attente de la commande ACCounT) ou respectivement avorte.
CHANGE WORKING DIRECTORY (CWD)

CHANGEMENT DE REPERTOIRE

Cette commande permet de changer le rpertoire distant de travail

(rcupration ou tlchargement de fichiers) sans modifier les paramtres
en cours de la session. Les paramtres de transfert restent eux aussi
inchangs. L'argument est un chemin d'accs valide dans le langage du
systme de fichier local.
CHANGE TO PARENT DIRECTORY (CDUP)

ACCES AU REPERTOIRE PERE

Il s'agit d'un cas particulier de la commande CWD, et est dfinie pour

simplifier l'implmentation de programmes transfrant des structures
entires de rpertoires entre des systmes d'exploitation utilisant des
syntaxes diffrentes pour l'accs au rpertoire pre. Les codes de rponse

RFC959

25

attendus sont identiques ceux attendus pour la commande CWD. Voir

l'Appendice II pour plus de dtails.
STRUCTURE MOUNT (SMNT)

MONTAGE DE VOLUME

Cette commande permet de monter un volume sous un systme de

fichier diffrent sans changer de contexte pour la session. Les paramtres
de transfert sont de mme inchangs. L'argument est un chemin d'accs
valide du systme local.
REINITIALIZE (REIN)

REINITIALISATION

Cette commande tue une connexion USER, librant toute les ressources
d'entres/sorties et les informations de session, sauf pour l'opration de
transfert en cours qui est acheve normalement. Tous les paramtres sont
rtablis dans leurs valeurs par dfaut et le canal de contrle est laiss
ouvert. L'tat obtenu est identique l'tat dans lequel serait un canal de
contrle juste aprs son tablissement. Une commande USER est en
gnral attendue.
LOGOUT (QUIT)

FERMETURE DE SESSION

Cette commande termine une session USER et si aucun transfert n'est en

cours, ferme le canal de contrle. Si un fichier est en cours de transfert, la
connexion restera ouverte jusqu' recevoir le code de rsultat de l'opration,
puis sera ferme par le serveur. Un processus utilisateur qui transfre des
fichiers multiples pour des USER distincts sans tre oblig de couper puis
de rouvrir chaque fois une nouvelle session, utilisera plutt une commande
REIN.
Une fermeture inopine du canal de contrle sera considr par un
serveur comme la succession implicite d'un commande d'avortement
(ABOR) suivi d'une fermeture de session (QUIT).
4.1.2. COMMANDES DE PARAMETRAGE DU TRANSFERT
Tous les paramtres de transfert ont des valeurs par dfaut, et l'usage des
commandes de paramtrage du transfert ne sont utiliser que dans le cas ou des
valeurs non standard sont requises pour la connexion. Les valeurs "par dfaut" sont
usuellement les dernires utilises, ou, si aucune n'a t spcifie, la valeur par
dfaut "standard". Ceci implique que le serveur doit se "rappeler" des valeurs par
dfaut applicables. Ces commandes peuvent apparatre dans n'importe quel ordre,
mais doivent toujours prcder les requtes de service FTP. Les commandes
suivantes spcifient les paramtres de transfert :
DATA PORT (PORT)

PORT DU CANAL DE DONNEES

L'argument est une spcification de port hte indiquant le port de

donnes utiliser pour l'tablissement du canal de donnes. Il existe des
valeurs standard pour les ports USER et SERVER, et, dans une situation
normale, cette commande et ses rponses associes ne sont pas exploites.

RFC959

26

Si cette commande est utilise, l'argument doit tre not comme la

concatnation d'une adresse TCP/IP compltement qualifie, soit une
adresse Internet en 32-bits et une adresse de port TCP en 16-bits . Cette
adresse est dcoupe en champs de 8-bits dont la valeur est transmise
comme un nombre dcimal (dans une reprsentation sous forme chane de
caractres). Les champs sont spars par des virgules . Une commande
PORT aurait l'allure suivante :
PORT h1,h2,h3,h4,p1,p2
dans laquelle h1 contient les 8 bits de poids fort de l'adresse Internet de
l'hte spcifi.
PASSIVE (PASV)

MODE PASSIF

Cette commande demande au SERVER-DTP de se mettre " l'coute"

d'un port de donnes (diffrent du port par dfaut) et d'attendre une
demande de connexion plutt que de prendre l'initiative d'en tablir une sur
rception d'une commande de transfert. La rponse cette commande
prcise l'adresse et le port sur lesquels le serveur s'est mis en coute.
REPRESENTATION TYPE (TYPE)

TYPE DE REPRESENTATION

L'argument de cette commande spcifie le type de reprsentation des

donnes utilise conformment la Section traitant des Reprsentation de
Donnes et Stockage. Plusieurs types admettent un second paramtre. Le
premier paramtre est exprim comme un seul et unique caractre Telnet,
tout comme le second paramtre Format dans le cas des types ASCII et
EBCDIC; le second paramtre dans le cas du type LocalByte est un entier
dcimal indiquant la taille de l'octet logique. Les paramtres sont spars
par des <SP> (Espace, ASCII code 32).
Les codes suivants sont rservs pour les types :
A - ASCII

|
| N - Non-print
|-><-| T - Telnet format effectors
E - EBCDIC |
| C - Carriage Control (ASA)
I - Image
L <byte size> - taille d'octet logique locale

La reprsentation des donnes utilise par dfaut est l'ASCII "Non-print".

Si le paramtre de Format est modifi, puis le premier argument est son
tour chang, le Format retourne la valeur "Non-print" par dfaut.

RFC959

27

FILE STRUCTURE (STRU)

STRUCTURE DE FICHIER

L'argument est donn sous forme d'un caractre Telnet unique spcifiant
la structure de fichier conformment la Section traitant des
Reprsentations de Donnes et Stockage.
Les codes suivant sont actuellement rservs pour l'encodage des
structures :
F - structure-fichier (pas de structure sous-jacente)
R - structure-enregistrement
P - structure-pages
La structure par dfaut est la structure-fichier.
TRANSFER MODE (MODE)

MODE DE TRANSFERT

L'argument est donn sous forme d'un caractre Telnet unique spcifiant
les modes de transfert de donnes dcrits dans la Section traitant des
Modes de Transmission.
Les codes suivants sont rservs pour l'encodage du mode de
transmission :
S - flux (stream)
B - Bloc
C - Compress
Le mode de transfert par dfaut est le mode flux.
4.1.3. COMMANDES DE SERVICE FTP
Les commandes de service FTP rassemblent toutes les commandes
oprationnelles de transfert ou systme qui peuvent tre invoques par l'utilisateur.
L'argument d'une commande de service FTP est en gnral un chemin d'accs. La
syntaxe de ce chemin doit se conformer aux conventions adoptes par le site
serveur (avec une valeur par dfaut applicable), et aux conventions de langage
adopte par le canal de contrle. La valeur par dfaut conseille est soit la dernire
combinaison d'unit logique, chemin d'accs et nom de fichier, soit un chemin
complet dfini comme dfaut par l'utilisateur. Les commandes peuvent tre
invoques dans n'importe quel ordre except pour le couple "rename from", "rename
to" qui doit tre excut dans cette ordre et subsquemment, et le cas de la
commande "restart" qui doit tre suivie de la dernire commande avorte (ex., STOR
ou RETR). Les donnes, lorsqu'elles sont mises en rponse une commande de
service FTP, devront toujours l'tre via le canal de donnes, sauf pour certaines
rponses caractre informatif. Les commandes suivantes dont partie de la classe
"commandes de service FTP" :

RFC959

28

RETRIEVE (RETR)

TRANSMISSION

Cette commande provoque la transmission par le SERVER-DTP d'une

copie du fichier spcifi par son chemin d'accs complet, destination du
SERVER- ou USER-DTP l'autre extrmit du canal de donnes. Le statut
et le contenu du fichier ct metteur doit rester inchang.
STORE (STOR)

ENREGISTREMENT

Cette commande provoque l'acceptation par le SERVER-DTP des

donnes transfres via le canal de donnes, lesquelles seront enregistres
dans un fichier sur le serveur rcepteur. Si le fichier entirement spcifi
existe sur le serveur avant la transmission, alors son contenu sera remplac
par le contenu transmis. Dans l'alternative, un nouveau fichier est cr.
STORE UNIQUE (STOU)

ENREGISTREMENT UNIQUE

Cette commande provoque le mme comportement que la commande

STOR except le fait que le fichier doit tre cr dans le rpertoire courant
sous un nom unique. La rponse de code 250 (Transfer Started) doit inclure
le nom de fichier gnr par le site rcepteur.
APPEND (with create) (APPE)
Cette commande provoque l'acceptation par le SERVER-DTP des
donnes transmises sur le canal de donnes, lesquelles seront enregistres
dans un fichier sur le site de rception. La diffrence avec la commande
STOR rside dans le fait que si le fichier spcifi existe dj sur le site de
rception, les donnes transmises viennent s'ajouter au fichier existant.
ALLOCATE (ALLO)

ALLOCATION

Cette commande peut tre ncessaire sur certains serveurs pour

rserver un espace de stockage suffisant pour permettre le stockage des
donnes transfrer. L'argument est un entier donnant la taille en octets
rserver (la taille est relative l'octet logique). Pour des fichiers transfrs
en mode enregistrement ou par pages, un
nombre maximal
d'enregistrement ou une taille maximale de page (compte en octets
logiques) peut tre ncessaire; ces valeurs sont indiques par l'usage d'un
deuxime paramtre entier dcimal. Ce second argument est optionnel, et
doit tre spar du premier, lorsqu'utilis, par les trois caractres Telnet
<SP> R <SP>. Cette commande doit tre usuellement suivie d'une
commande STORe ou APPEnd. La commande ALLO doit tre traite comme
une commande NOOP (no operation) par tous les serveurs ne ncessitant
pas une prdclaration de la taille de fichiers enregistrer, ceux qui
ncessitent seulement une mention de la taille maximale d'enregistrement
ou de taille maximale de page peuvent accepter une absence de valeur pour
le premier paramtre, ou ignoreront la valeur si spcifie.

RFC959

29

RESTART (REST)

REPRISE

Le champ argument contient une expression du marqueur de contrle

partir duquel le transfert doit tre repris. Cette commande ne provoque pas
explicitement de transfert de donnes, mais dplace simplement le point de
lecture du fichier interrompu jusqu'au point de contrle spcifi. Cette
commande sera immdiatement suivie de la commande de service FTP
ncessaire relancer le processus de transfert.
RENAME FROM (RNFR)

RENOMMER...

Cette commande indique l'ancien chemin d'accs complet du fichier qui

doit tre renomm. Cette commande doit tre immdiatement suivie d'une
commande "rename to" spcifiant le nouveau nom du fichier en question.
RENAME TO (RNTO)

RENOMMER VERS...

Cette commande indique le nouveau nom du fichier spcifi dans le

commande "rename from" prcdente. L'usage subsquent de ces deux
commandes provoque le changement du nom du fichier sur le systme
distant.
ABORT (ABOR)

AVORTEMENT

Cette commande provoque l'interruption immdiate de la dernire

commande de service FTP et tout transfert de donnes associ. Cette
commande peut demander une "action spciale", comme il est discut dans
le Section traitant des Commandes FTP, pour en forcer la reconnaissance
asynchrone par le serveur. Aucune action n'est a effectuer si la commande
prcdent a t acheve (y compris un transfert de donnes). Le canal de
contrle ne doit pas tre coup par le serveur, mais le canal de donnes doit
tre ferm.
Le serveur doit prendre en compte deux situations sur rception de cette
commande : (1) toute commande de service FTP est acheve, ou (2) une
commande de service FTP est en cours. Dans le premier cas, le serveur
ferme le canal de donnes (s'il est encore ouvert) et rpond par un code
226, indiquant que la commande d'avortement a t correctement traite.
Dans le second cas, le serveur interrompt le service FTP en cours, coupe
le canal de donnes, et renvoie un code 426 pour indiquer que la dernire
commande s'est acheve anormalement. Le serveur envoie la suite un
code 226, indiquant que la commande d'avortement elle-mme s'est bien
droule.
DELETE (DELE)

SUPPRESSION

Cette commande provoque la suppression sur le site serveur du fichier

prcis par le chemin d'accs complet. Si une tape supplmentaire de
protection est ncessaire (telle qu'une confirmation ventuelle du type

RFC959

30

"Supprimer rellement ce fichier?"), elle doit tre fournie par le processus

USER-FTP.
REMOVE DIRECTORY (RMD)

SUPPRESSION DE REPERTOIRE

Cette commande provoque la suppression du chemin d'accs spcifi au

titre de rpertoire (si le chemin est absolu) ou de sous rpertoire du
rpertoire courant (si le chemin est relatif). Voir l'appendice II.
MAKE DIRECTORY (MKD)

CREATION DE REPERTOIRE

Cette commande provoque la cration d'un rpertoire (si le chemin est

absolu) ou d'un sous rpertoire du rpertoire courant (si le chemin est relatif)
selon le chemin spcifi. Voir l'appendice II.
PRINT WORKING DIRECTORY (PWD)IMPRESSION DU REPERTOIRE COURANT
Cette commande renvoie le nom du rpertoire courant dans la rponse.
Voir Appendice II.
LIST (LIST)

CATALOGUE DU REPERTOIRE COURANT

Cette commande provoque l'mission par le serveur d'une liste de

fichiers au DTP passif. Si le chemin mentionn spcifie un rpertoire ou tout
autre groupe de fichiers, le serveur rpondra par une liste des fichiers dans
ce rpertoire ou ce groupe. Si le chemin spcifie un fichier normal, alors les
informations systme relatives ce fichier seront renvoyes. Une absence
d'argument indique par dfaut le rpertoire courant. La rponse est
transfre via le canal de donnes pour les types ASCII ou EBCDIC.
(l'utilisateur doit s'assurer que le type est effectivement ASCII ou EBCDIC).
Comme les informations relatives un fichier peuvent varier grandement en
forme et prsentation entre divers systmes, celles-ci seront gnralement
peu exploitable par un automate. Elles sont cependant fort utiles pour un
utilisateur humain.
NAME LIST (NLST)

CATALOGUE COURT

Cette commande provoque l'envoi par le serveur d'un catalogue succinct

d'un de ses rpertoires vers l'utilisateur. Le chemin spcifi doit dcrire un
rpertoire valide ou tout autre descripteur d'un ensemble de fichiers; un
argument omis dsigne le rpertoire courant. Le serveur rpondra par une
liste de noms de fichiers l'exclusion de toute autre information. Les
donnes sont transfres en ASCII ou EBCDIC sur le canal de donnes
sous forme d'une suite de noms de chemins d'accs valides spars par des
<CRLF> ou <NL>. (Encore une fois, l'utilisateur doit s'assurer que le
paramtre TYPE est correct). Cette commande a t implmente pour
permettre des processus automatiques de pouvoir rcuprer cette liste
pour traitement ultrieur. Un cas typique est l'implmentation d'une fonction
de tlchargement de fichiers multiples.

RFC959

31

SITE PARAMETERS (SITE)

PARAMETRES DE TAILLE

Cette commande est utilise par le serveur pour proposer des services
spcifiques ce systme qui sont indispensables pour le transfert de
fichiers mais insuffisamment universels pour justifier l'attribution d'une
commande dans le protocole. La nature de ces services, et leur syntaxe
devra tre fournie par chaque service les utilisant, en rponse d'une
commande HELP SITE.
SYSTEM (SYST)

SYSTEME

Cette commande permet de connatre le type de systme d'exploitation

sur le serveur. La rponse devra mentionner dans son premier "mot" l'un des
systmes mentionns dans le document Assigned Numbers [4] en cours de
validit.
STATUS (STAT)

STATUT

Cette commande provoque l'envoi d'un message d'tat (statut) de

rponse sur le canal de contrle. Cette commande peut tre utilise en
cours de transfert (avec les signaux IP et Synch de Telnet voir la Section
traitant des commandes FTP) auquel cas le serveur doit rpondre avec l'tat
de la transaction en cours, ou bine elle peut tre envoye entre deux
transferts. Dans ce dernier cas, la commande devra tre utilise avec un
argument. Si cet argument est un chemin d'accs, la commande rsultante
quivaut une commande "list" l'exception prs que la rponse sera
transmise par le canal de connexion au lieu du canal de donnes. Si un
chemin partiel est donn, Le serveur rpondra par une liste de noms de
fichiers ou d'attributs associs cette spcification. Si aucun argument n'est
donn, le serveur renverra une information gnrale concernant le
processus serveur FTP. Ceci pourra inclure l'ensemble des paramtres de
connexion actuellement utilis ainsi que l'tat de toutes les connexions.
HELP (HELP)

AIDE

Cette commande provoque l'envoi d'une information d'aide concernant

l'implmentation du serveur lui-mme, via la connexion de contrle. Cette
commande peut prendre un argument (ex., n'importe quel nom de
commande) et renvoie des informations encore plus prcises. La rponse
sera de type 211 ou 214. Il est suggr que la commande HELP soit
permise y compris avant qu'une commande USER d'ouverture de session
n'ait t excute. Le serveur pourra utiliser cette commande pour donner
des informations sur des paramtres dpendants du systme, ex., en
rponse la requte "HELP SITE".
NOOP (NOOP)

PAS D'ACTION

Cette commande n'affecte aucun paramtre ni n'interagit avec aucune

des commandes prcdemment lances. Elle provoque aucune autre action
qu'une simple rponse "OK" de la part du serveur.

RFC959

32

4.2. REPONSES FTP

Les rponses des commandes FTP sont destines assurer une certaine
synchronisation des actions impliques dans un processus de transfert de fichiers,
et garantir que le processus utilisateur puisse toujours connatre l'tat du serveur.
Chaque commande suscite au moins une rponse, mais plusieurs rponses peuvent
tre donnes; dans ce dernier cas, les multiples rponses devront tre aisment
diffrentiables. De plus, certaines commandes peuvent tre mises groupes en
squence, comme USER, PASS et ACCT, ou RNFR et RNTO. Les rponses
tmoignent de l'existence d'tats intermdiaires si toutes les commandes passes
sont excutes avec succs. L'chec d'une seule tape ncessitera de
recommencer toute la procdure.
Les dtails d'une squence de commandes-rponses sont explicites dans
l'ensemble de diagrammes ci-aprs.
Une rponse FTP rpond consiste en un nombre trois chiffres (transmis sous
forme de trois caractres alphanumriques) suivis d'un texte. Le code numrique est
destination d'automates pour renseigner des dispositions prendre et de l'tat
suivant de celui-ci; le texte est plutt destin l'utilisateur humain. Les trois digits du
code sont senss contenir suffisamment d'information pour que le processus
utilisateur (USER-PI) n'ait pas ncessit d'examiner la partie texte de la rponse,
laquelle peut tre soit limine, soit transfre l'interface utilisateur, selon la
ncessit. En particulier, le texte mis peut varier de serveur serveur, et un
automate pourrait donc avoir des difficults analyser tous les messages possibles.
Une rponse est dfinie comme contenant le code 3-digits, suivi d'un Espace
<SP>, suivie par une ligne de texte (lorsqu'une longueur maximale de rponse a t
dfinie auparavant), et termine par le code de fin-de-ligne Telnet. Il y aura des cas
cependant, ou le texte sera plus long qu'une simple ligne. Dans ce cas, le texte
entier aurait pu tre mis entre crochets de sorte que le processus utilisateur puisse
savoir quand s'arrte la lecture du texte (c--d. arrte l'analyse de l'entre du canal
de contrle) pour passer d'autres tches. Ceci implique l'utilisation d'un format
particulier sur la premire ligne pour indiquer que d'autres lignes suivent, et un autre
format particulier sur la dernire. Au moins une de ces lignes doit prsenter le code
de rponse. Pour satisfaire tous les avis sur le problme, il a t dcid que le code
serait identique sur la premire et la dernire ligne.
Ainsi, le format d'une rponse multilignes est tel que la premire ligne dbute par
le code exact de la rponse, suivi d'un tiret "-" (Hyphnation ou "moins"), suivi du
texte de la premire ligne. La dernire ligne commencera par le mme code, suivi
immdiatement d'un Espace <SP>, ventuellement du texte, termin par le code de
fin-de-ligne Telnet.
Par exemple:
123-First line
Second line
234 A line beginning with numbers
123 The last line

RFC959

33

Le processus utilisateur n'a plus qu' chercher la deuxime occurrence du code

de rponse suivie de l'Espace <SP> en dbut de ligne, et ignorer les lignes
intermdiaires. Si une ligne intermdiaire commence par un nombre de 3-digits, le
serveur ajoutera un espace en tte de ligne pour viter toute confusion.
Ce schma permet des routines systme standard d'tre employes pour
gnrer la rponse (ex. pour la rponse la commande STAT), avec un marquage
supplmentaire "artificiel" en tte de la premire et la dernire ligne. Au cas (rare)
ou ces routines seraient susceptibles de gnrer une ligne commenant par 3 digits
suivi d'un espace, un caractre neutre (ex. Espace) sera rajout en tte de chaque
ligne.
Ce schma permet d'viter la mise entre crochets de la rponse.
Les trois digits de la rponse ont chacun une signification particulire. Ceci
permet d'implmenter des traitements rponse du plus simple au plus complexe
dans l'USER-PI. Le premier digit indique si la commande se termine en succs,
chec, ou est incomplte. (Rapport au diagramme d'tat), un interprteur de
protocole simpliste pourra dterminer une stratgie d'action lancer (telles que se
retirer, tenter de nouveau, etc.) en se bornant examiner ce digit. Un processus
utilisateur dsireux de savoir de quelle nature est l'erreur, (ex. erreur du systme de
fichiers, erreur de syntaxe dans la commande) pourra examiner le second digit, le
troisime tant rserv au degr le plus fin de signalisation (ex., une commande
RNTO sans commande RNFR antrieure).
Le premier digit peut prendre 5 valeurs diffrentes :
1yz

Rponse positive prliminaire

L'action demande a t correctement reconnue et lance; on devra

attendre une autre rponse pour pouvoir demander l'excution d'une
nouvelle commande. (Un processus utilisateur mettant une nouvelle
commande avant conclusion de la premire obtiendrait une rponse d'erreur
du type "violation de protocole"; certains processus serveur FTP peuvent
empiler les rponses entrantes sans mettre ce type d'avertissement). Ce
type de rponse est utilis pour avertir l'utilisateur que sa commande a t
bien reconnue et qu'il peut alors surveiller son canal de donnes,
notamment dans le cas d'applications dans lesquelles la surveillance
simultane des deux canaux "contrle" et "donnes" n'est pas pratique. Un
serveur FTP devra au moins mettre une commande de classe 1yz par
commande reue.
2yz

Rponse positive dfinitive

L'action demande s'est compltement droule avec succs. Une

nouvelle commande peut tre reue par le serveur.

RFC959

34

3yz

Rponse positive intermdiaire

La commande a t accepte, mais le serveur a mis celle-ci en sommeil,

dans l'attente d'informations supplmentaires. L'utilisateur devra alors
mettre une autre commande avec les informations demandes. Cette
rponse est utilise dans les groupements de commandes en squence.
4yz

Rponse ngative transitoire

La commande a t refuse, et l'action n'a pas t excute, mais la

condition d'erreur invoque est de nature temporaire, impliquant que la
mme commande peut tre tente nouveau. Dans le cas d'une squence
de commandes groupes, l'utilisateur reprendra toute la squence depuis
son dbut. Le contexte du terme "transitoire" reste cependant difficile
expliciter, en particulier lorsque deux sites distincts (SERVER- et processus
USER) doivent s'accorder sur son interprtation. Chaque rponse de la
classe 4yz peut correspondre un contexte de dure diffrent, mais le but
de cette classe est de signaler au processus utilisateur la possibilit de
tenter l'opration encore une fois. Une rgle d'implmentation pour savoir si
une rponse doit entrer ou doit tre fournie dans la classe 4yz ou 5yz
(Ngative dfinitive) est la suivante : une rponse sera de classe 4yz si la
commande peut tre rpte avec une chance de succs, A L'IDENTIQUE,
et sans aucune modification des paramtres USER ou SERVER (c--d., la
commande est crite strictement comme la premire; l'utilisateur ne change
pas ses droits d'accs, ne change pas de compte ni de session; le serveur
ne change pas d'implmentation).
5yz

Rponse ngative dfinitive

La commande a t refuse, et l'action n'a pas t excute. Le serveur

notifie par l au processus utilisateur qu'il sera vain de retenter la mme
commande (dans la mme squence).
Certaines conditions d'erreur
"permanentes" pourront toutefois tre corriges, et la commande pourra tre
relance par une action explicite de l'utilisateur humain, soit aprs correction
de la commande, soit aprs changement de ses droits, soit aprs
intervention de l'oprateur du serveur.
Le second digit donne une indication sur la nature de la rponse :
x0z Syntaxe
Ces rponses se rfrent des erreurs de syntaxe, des commandes
correctes en termes de syntaxe, mais ne se rfrant aucune fonction
connue ou implmente.
x1z Information
Indiquent une rponse des demandes d'information, comme les
commandes d'tats ou d'aide.

RFC959

35

x2z Connexions
Rponses se rfrent une problmatique de connexion sur les canaux
"contrle" ou "donnes".
x3z Identification et authentification
Rponses du processus d'accs au systme de fichiers.
x4z

Non encore spcifie.

x5z Systme de fichiers

Ces rponses se rfrent l'tat du systme de fichiers serveur lorsque
des commandes de ce systme sont invoques.
Le troisime digit permet de qualifier encore plus finement les rponses dans
chacune des catgories donnes par le deuxime digit. La liste des rponses
donne ci-aprs le montre. Notez que le contenu informationnel du texte ci-dessous
est une "recommandation", et est nature interprtation en fonction du serveur qui
l'met. Les codes de rponse, par opposition, doivent suivre la lettre les
spcifications indiques; c'est--dire que les implmentations des serveurs ne
doivent jamais inventer de nouveaux codes, mme si les situations dans lesquelles
ils peuvent tre sont lgrement diffrentes que celles dfinies; elles devront
imprativement choisir le code correspondant la situation la plus proche.
Une commande telle que TYPE ou ALLO dont l'excution complte n'est pas de
nature apporter une information utile pour le processus utilisateur provoqueront le
retour d'une rponse de code 200. Lorsque la commande en question n'est pas
implmente par un processus SERVER-FTP particulier (cette fonction n'a pas de
signification dans ce contexte particulier de serveur, par exemple, la commande
ALLO sur un site TOPS20), ce dernier devra de prfrence rpondre par un code
positif de sorte que l'utilisateur puisse poursuivre sa procdure. Une rponse de
code 202 sera utilis dans ce cas, associ par exemple au texte suivant: "Allocation
non ncessaire." Si, par contre, la commande est gnrale, mais non implmente
par le site serveur, un code 502 sera rpondu. Une version affine de cette rponse
est le code 504 qui prcise que cette commande est implmente, mais l'un au
moins des paramtres associs ne l'est pas.
4.2.1 CODES DE REPONSE PAR GROUPES DE FONCTIONS
200 Commande conclue.
500 Erreur de syntaxe, commande non reconnue. Inclut le cas d'une ligne de
commande trop longue.
501 Erreur de syntaxe dans le paramtres ou arguments.
202 Commande non implmente, ou superflue sur ce site.
502 Commande non implmente.
503 Mauvaise squence de commandes.
504 Commande non implmente pour ce paramtre.

RFC959

36

110 Rponse marqueur de reprise. Dans ce cas, le texte doit tre exact et n'est
pas "adaptable" par des implmentations "locales"; il DOIT indiquer: MARK yyyy =
mmmm o yyyy est le marqueur du flux de donnes USER-DTP, et mmmm le
marqueur quivalent ct serveur (noter l'espace indispensable entre les marqueurs
et le "=").
211 Statut systme, ou rponse d'aide systme.
212 Statut de rpertoire.
213 Statut de fichier.
214 Message d'aide.
Sur la manire d'utiliser le serveur ou la signification d'une commande non standard.
Cette rponse n'est destine qu' un utilisateur humain.
215 NOM de type de systme.
Le nom de type de systme est un nom officiel standard dfini dans la RFC
"Assigned Numbers".
120 Service disponible dans nnn minutes.
220 Service disponible pour nouvel utilisateur.
221 Canal de contrle ferm par le service. Cas archiv si ncessaire.
421 Service non disponible, canal de contrle ferm. Rpondu toute commande
lorsque la fermeture imminente du service est prvue.
125 Canal de donnes dj ouvert; dbut de transfert.
225 Canal de donnes ouvert; pas de transfert en cours.
425 Erreur d'ouverture du canal de donnes.
226 Fermeture du canal de donnes. Service termin (par exemple, transfert de
fichier ou avortement).
426 Connexion ferme, transfert interrompu.
227 Passage en mode passif (h1,h2,h3,h4,p1,p2).
230 Session ouverte.
530 Session non ouverte.
331 Nom d'utilisateur reu, mot de passe demand.
332 Compte utilisateur demand.
532 Compte utilisateur demand pour enregistrement de fichiers.
150 Statut de fichier vrifi; ouverture de canal de donnes en cours.
250 Service fichier termin.
257 "CHEMIN" cr.
350 Service fichier en attente d'information.
450 Service fichier non trait. Fichier non disponible (ex., fichier verrouill par un
autre utilisateur).
550 Service fichier non trait. Fichier non accessible (ex., fichier non trouv,
accs refus).
451 Service interrompu. Erreur locale de traitement.
551 Service interrompu. Type de page inconnu.
452 Service interrompu. Espace insuffisant.
552 Service fichier interrompu. Quota dpass (pour le rpertoire ou compte
courant).
553 Service interrompu. Nom de fichier erron.

RFC959

37

4.2.2 CODES REPONSE PAR ORDRE NUMERIQUE

110 Rponse marqueur de reprise. Dans ce cas, le texte doit tre exact et n'est
pas "adaptable" par des implmentations "locales"; il DOIT indiquer: MARK yyyy =
mmmm o yyyy est le marqueur du flux de donnes USER-DTP, et mmmm le
marqueur quivalent ct serveur (noter l'espace indispensable entre les marqueurs
et le "=").
120 Service disponible dans nnn minutes.
125 Canal de donnes dj ouvert; dbut de transfert.
150 Statut de fichier vrifi; ouverture de canal de donnes en cours.
200 Commande conclue.
202 Commande non implmente, ou superflue sur ce site.
211 Statut systme, ou rponse d'aide systme.
212 Statut de rpertoire.
213 Statut de fichier.
214 Message d'aide.
Sur la manire d'utiliser le serveur ou la signification d'une commande non standard.
Cette rponse n'est destine qu' un utilisateur humain.
215 NOM de type de systme.
Le nom de type de systme est un nom officiel standard dfini dans la RFC
"Assigned Numbers".
220 Service disponible pour nouvel utilisateur.
221 Canal de contrle ferm par le service. Cas archiv si ncessaire.
225 Canal de donnes ouvert; pas de transfert en cours.
226 Fermeture du canal de donnes. Service termin (par exemple, transfert de
fichier ou avortement).
227 Passage en mode passif (h1,h2,h3,h4,p1,p2).
230 Session ouverte.
250 Service fichier termin.
257 "CHEMIN" cr.
331 Nom d'utilisateur reu, mot de passe demand.
332 Compte utilisateur demand.
350 Service fichier en attente d'information.
421 Service non disponible, canal de contrle ferm. Rpondu toute commande
lorsque la fermeture imminente du service est prvue.
425 Erreur d'ouverture du canal de donnes.
426 Connexion ferme, transfert interrompu.
450 Service fichier non trait. Fichier non disponible (ex., fichier verrouill par un
autre utilisateur).
451 Service interrompu. Erreur locale de traitement.
452 Service interrompu. Espace insuffisant.
500 Erreur de syntaxe, commande non reconnue. Inclut le cas d'une ligne de
commande trop longue.
501 Erreur de syntaxe dans le paramtres ou arguments.

RFC959

38

502 Commande non implmente.

503 Mauvaise squence de commandes.
504 Commande non implmente pour ce paramtre.
530 Session non ouverte.
532 Compte utilisateur demand pour enregistrement de fichiers.
550 Service fichier non trait. Fichier non accessible (ex., fichier non trouv,
accs refus).
551 Service interrompu. Type de page inconnu.
552 Service fichier interrompu. Quota dpass (pour le rpertoire ou compte
courant).
553 Service interrompu. Nom de fichier erron.

5. SPECIFICATIONS DECLARATIVES
5.1. IMPLEMENTATION MINIMALE
Afin de rendre FTP exploitable sans multiplication de messages d'erreur inutiles,
une implmentation minimale assurer par tous serveurs est dfinie ci-aprs :
TYPE - ASCII Non-print
MODE - Flux
STRUCTURE - Fichier, Enregistrement
COMMANDES - USER, QUIT, PORT,
TYPE, MODE, STRU, pour les valeurs par dfaut
RETR, STOR,
NOOP.
Les paramtres par dfaut pour le transfert de donnes sont :
TYPE - ASCII Non-print
MODE - Stream
STRU - File
Tous les htes doivent accepter les paramtres ci-dessus comme paramtres par
dfaut standards.
5.2. CONNEXIONS
L'interprteur de protocole serveur "coute" sur le Port L. L'utilisateur, ou son
interprteur de protocole doit prendre l'initiative de l'tablissement de la connexion
bidirectionnelle du canal de contrle. Les processus SERVER- et USER- doivent
suivre les conventions du protocole Telnet spcifies dans le ARPA-Internet
Protocol Handbook [1]. Les serveurs n'ont aucune obligation de fournir un moyen
d'diter la ligne de commande. Cette dition, si ncessaire, peut tre dlgue au
processus utilisateur. La connexion de contrle pourra tre coupe par le serveur
sur demande de l'utilisateur, aprs conclusion de toutes les transmissions de
commandes et rponses associes.

RFC959

39

Le USER-DTP doit "couter" le Port de donnes spcifi; celui-ci peut tre le port
standard (U) ou le port donne par une commande PORT. Le serveur peut lui-mme
tablir la connexion du canal de donnes entre son port de donnes standard (L-1)
et le port utilisateur spcifi. Le port utilis, et le sens de transfert seront dtermins
par la nature de la commande de service FTP excuter.
Notez que toutes les implmentations FTP doivent pouvoir piloter des transferts
sur le port de donnes par dfaut, alors que seuls les USER-PI peuvent provoquer
l'usage des ports non standard.
Lorsque des donnes doivent tre transmises entre deux serveurs, A et B (voir
Figure 2), le USER-PI de C tablit un canal de contrle avec chacun des SERVERPI de A et respectivement de B. L'un des serveurs, disons A, reoit une commande
PASV lui indiquant "d'couter" son port de donnes plutt que tenter une connexion
lorsqu'il reoit un ordre de transfert. Lorsque le USER-PI reoit l'acquittement de
cette commande PASV, qui inclut l'identit et le port du serveur "cout", le USERPI envoie la rfrence au port A au serveur B par une commande PORT; une
rponse est attendue. Le USER-PI met alors les commandes de service FTP
correspondantes A et B. Le serveur B tablit la connexion de donnes et le
transfert commence. La squence de commandes est montre ci-dessous (les
messages sont explicits selon un synchronisme vertical, la disposition horizontale
restant asynchrone) :
USER-PI - Serveur A
-------------------

USER-PI - Serveur 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

Figure 3
La connexion de donnes peut tre ferme par le serveur sous les conditions
dcrites la Section traitant de l'Etablissement de la Connexion de Donnes. Si la
fermeture du canal de donnes survient aprs un transfert pour lequel la fermeture
du canal ne correspond pas une ncessit de signaler une fin-de-fichier (EOF), le
serveur peut en prendre l'initiative immdiate. Il n'est pas permis d'accepter une
nouvelle commande de transfert dans ce cas car le processus utilisateur ne pourra
tester l'tat de la connexion de donnes pour se mettre en coute sur celle-ci (il l'a
dj fait une fois, et n'a pas priori de moyen de savoir que la connexion est
referme, par contre, un utilisateur doit ncessairement pouvoir se mettre en coute
d'un canal de donnes "ferm" AVANT d'envoyer une commande de transfert). Pour
viter un blocage en ce point, le serveur renvoie une rponse (226) aprs avoir
ferm le canal de donnes (ou, si le canal est laiss ouvert, une rponse "transfert
termin" (250)). Le USER-PI devra attendre une de ces deux rponses avant de
relancer une commande de transfert

RFC959

40

Chaque fois qu'un utilisateur ou un serveur s'aperoit que le canal de donnes a

t ferm l'autre bout, il devra le plus rapidement possible vider les tampons
associs ce canal, et refermer son propre ct de ce dernier.
5.3. COMMANDES
Les commandes sont des chanes de caractres conformes au protocole Telnet
transmises sur des canaux de contrle tel que le dcrit la Section traitant des
Commandes FTP. Les fonctions et smantique des commandes sont dcrites dans
la Section traitant des Commandes de Contrle d'Accs, Commandes de
Paramtrage de Transfert, Commandes de Service FTP, et Commandes Diverses.
La syntaxe des commandes est prcise ci-aprs.
Toute commande commence par un code de commande
d'argument. Le code de commande est compos d'au plus
alphabtiques. Il ne doit pas tre tenu compte de la casse
commande FTP. Ainsi, toutes les combinaisons suivantes
commande de tlchargement :
RETR

Retr

retr

ReTr

suivi d'un champ

quatre caractres
dans un code de
se rfrent la

rETr

Ceci s'applique tous les symboles utiliss pour donner les codes de valeurs
des arguments, comme "A" ou "a" pour le TYPE ASCII. Le code de commande et les
arguments doivent tre spars l'un l'autre par un Espace.
Le champ d'argument est une chane de longueur variable termine par la
squence <CRLF> en reprsentation NVT-ASCII, ou la squence de fin-de-ligne
correspondante si un autre langage a t ngoci pour la transmission. Il doit tre
not ici que le serveur doit attendre la rception de cette squence avant d'excuter
une quelconque action.
La syntaxe est explicite ci-dessous en NVT-ASCII. Tous les caractres du
champ d'arguments sont des caractres ASCII incluant toute reprsentation
dcimale d'entiers en ASCII. Les crochets indiquent un argument optionnel. Si cette
option n'est pas explicite, la valeur par dfaut est considre.
5.3.1. COMMANDES FTP
Les commandes FTP sont spcifies ci-dessous :
USER <SP> <nom d'utilisateur> <CRLF>
PASS <SP> <mot de passe> <CRLF>
ACCT <SP> <compte utilisateur> <CRLF>
CWD <SP> <chemin d'accs> <CRLF>
CDUP <CRLF>
SMNT <SP> <chemin d'accs> <CRLF>
QUIT <CRLF>
REIN <CRLF>
PORT <SP> <port> <CRLF>
PASV <CRLF>
TYPE <SP> <code type> <CRLF>
STRU <SP> <code structure> <CRLF>

RFC959

41

MODE <SP> <code mode> <CRLF>

RETR <SP> <chemin d'accs> <CRLF>
STOR <SP> <chemin d'accs> <CRLF>
STOU <CRLF>
APPE <SP> <chemin d'accs> <CRLF>
ALLO <SP> <entier dcimal>
[<SP> R <SP> <entier dcimal>] <CRLF>
REST <SP> <marqueur> <CRLF>
RNFR <SP> <chemin d'accs> <CRLF>
RNTO <SP> <chemin d'accs> <CRLF>
ABOR <CRLF>
DELE <SP> <chemin d'accs> <CRLF>
RMD <SP> <chemin d'accs> <CRLF>
MKD <SP> <chemin d'accs> <CRLF>
PWD <CRLF>
LIST [<SP> <chemin d'accs>] <CRLF>
NLST [<SP> <chemin d'accs>] <CRLF>
SITE <SP> <chane> <CRLF>
SYST <CRLF>
STAT [<SP> <chemin d'accs>] <CRLF>
HELP [<SP> <chane>] <CRLF>
NOOP <CRLF>

5.3.2. ARGUMENTS DE COMMANDES FTP

Syntaxe des champs d'arguments ci-avant (notation BNF si applicable) :
<nom d'utilisateur> ::= <chane>
<mot de passe> ::= <chane>
<compte utilisateur> ::= <chane>
<chane> ::= <char> | <char><chane>
<char> ::= tout caractre ASCII de code 0 128 sauf <CR>
et <LF>
<marqueur> ::= <pr-chane>
<pr-chane> ::= <pr-char> | <pr-char><pr-chane>
<pr-char> ::= caractres imprimables, codes ASCII de 33
126
<taille d'octet> ::= <nombre>
<port> ::= <adresse hte>,<numro port>
<adresse hte> ::= <nombre>,<nombre>,<nombre>,<nombre>
<numro port> ::= <nombre>,<nombre>
<nombre> ::= tout entier dcimal entre 1 et 255
<code format> ::= N | T | C
<type-code> ::= A [<sp> <code format>]
| E [<sp> <code format>]
| I
| L <sp> <taille d'octet>
<code structure> ::= F | R | P
<code mode> ::= S | B | C
<chemin d'accs> ::= <chane>
<entier dcimal> ::= tout entier dcimal cod en ASCII

RFC959

42

5.4. SEQUENCEMENT DES COMMANDES ET REPONSES

La communication entre l'utilisateur et le serveur est prvue pour autoriser un
dialogue bidirectionnel. A ce titre, l'utilisateur met une commande FTP laquelle le
serveur rpond par une premire rponse rapide provisoire. L'utilisateur devra
attendre cette rponse, positive ou ngative, avant de pouvoir mettre une autre
commande.
Certaines commandes ncessitent l'attente d'une deuxime rponse. Ces
rponses peuvent, par exemple, donner un tat d'avancement ou de conclusion d'un
transfert de fichier ou signaler la fermeture du canal de donnes. Ce sont des
rponses secondaires des commandes de transfert de fichier.
Un groupe important de rponses est celui qui contient les rponses
d'information suite la conclusion d'une connexion. En des circonstances normales,
un serveur mettra une rponse de code 220, "attente d'entre", lorsque la
connexion est tablie. L'utilisateur devra attendre cette rponse d'tat avant
d'mettre toute commande. Si les serveur n'est pas immdiatement en tat de
recevoir des commandes, il mettra une rponse de code 120 "service retard"
immdiatement aprs l'tablissement de la connexion, puis une rponse de code
220 ds qu'il est en tat de recevoir. L'utilisateur est averti de ce temps d'attente, et
pourra choisir de maintenir la connexion.
Rponses spontanes
Parfois, "le systme" a spontanment un message mettre vers l'utilisateur (en
gnral tous les utilisateurs connects).Par exemple, "Arrt du systme dans 15
minutes". FTP ne propose pas de mcanisme particulier pour mettre spontanment
un message du serveur vers l'utilisateur. Il est recommand d'empiler cette rponse
au niveau du SERVER-PI et de dlivrer cette information lors de l'mission d'une
rponse classique ultrieure (par exemple en constituant une rponse multilignes).
La table ci-aprs liste les rponses positives et ngatives pour chaque
commande. Il est demand un respect strict des codes de rponse dans les
situations indiques; le texte mis par le serveur est libre, bien que son sens gnral
et l'indication sur l'action excuter dusse rester explicite, dans le contexte, et
univoque.
Squences de Commandes Rponses
Dans cette section sont prsentes les squences usuelles de commandesrponses. Chaque commande est liste avec toutes ses rponses possibles; les
groupes de commandes sont lists ensembles. Les rponses provisoires sont listes
en premier, puis les rponses dfinitives positives et ngatives, enfin, les rponses
intermdiaires avec les reste des rponses suivantes de la squence. Ces listes
sont la base des diagrammes d'tats, prsents plus en avant.
Etablissement de connexion
120
220
220
421

RFC959

43

Ouverture de session
USER
230
530
500, 501, 421
331, 332
PASS
230
202
530
500, 501, 503,
332
ACCT
230
202
530
500, 501, 503,
CWD
250
500, 501, 502,
CDUP
200
500, 501, 502,
SMNT
202, 250
500, 501, 502,

421

421
421, 530, 550
421, 530, 550
421, 530, 550

Fermeture de session
REIN
120
220
220
421
500, 502
QUIT
221
500
Paramtres de transfert
PORT
200
500, 501, 421,
PASV
227
500, 501, 502,
MODE
200
500, 501, 504,
TYPE
200
500, 501, 504,
STRU
200

RFC959

530
421, 530
421, 530
421, 530

44

500, 501, 504, 421, 530

Commandes de service fichiers
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
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

RFC959

45

350
RNTO
250
532,
500,
DELE
250
450,
500,
RMD
250
500,
MKD
257
500,
PWD
257
500,
ABOR
225,
500,

553
501, 502, 503, 421, 530
550
501, 502, 421, 530
501, 502, 421, 530, 550
501, 502, 421, 530, 550
501, 502, 421, 550
226
501, 502, 421

Commandes d'information
SYST
215
500, 501, 502, 421
STAT
211, 212, 213
450
500, 501, 502, 421, 530
HELP
211, 214
500, 501, 502, 421
Commandes diverses
SITE
200
202
500, 501, 530
NOOP
200
500, 421

6. DIAGRAMMES D'ETAT
Cette section prsente les diagrammes d'tats pour une implmentation basique
de FTP. Seul le premier digit des codes de rponse est considr. Un diagramme
d'tat est associ un groupe de commandes FTP ou une squence de
commandes.

RFC959

46

Le regroupement des commandes a t opr lors de la construction du modle

de chaque commande par association des commandes qui rpondaient au mme
modle structurel.
Pour chaque commande, ou squence de commandes, trois issues sont
possibles: succs S (Success), Echec F (Failure), et erreur E (Error).
Dans les diagrammes ci-dessous, nous avons utilis le symbole B pour "begin"
(dbut), et le symbole W pour "wait for reply" (attente de rponse).
Le diagramme suivant prsente le fonctionnement de la plus grande partie des
commandes FTP :
1,3
+---+
----------->| E |
|
+---+
|
+---+
cmd
+---+
2
+---+
| B |---------->| W |---------->| S |
+---+
+---+
+---+
|
|
4,5
+---+
----------->| F |
+---+

Ce diagramme propose le modle pour les commandes :

ABOR, ALLO, DELE, CWD, CDUP, SMNT, HELP, MODE, NOOP, PASV,
QUIT, SITE, PORT, SYST, STAT, RMD, MKD, PWD, STRU, et TYPE.
Un autre groupe important de commande rpond au schma suivant lgrement
diffrent :

3
+---+
----------->| E |
|
+---+
|
+---+
cmd
+---+
2
+---+
| B |---------->| W |---------->| S |
+---+
--->+---+
+---+
|
| |
|
| |
4,5
+---+
| 1 | ----------->| F |
----+---+

Ce diagramme propose le modle pour les commandes :

APPE, LIST, NLST, REIN, RETR, STOR, et STOU.

RFC959

47

Notez que ce second modle pourrait servir reprsenter les commandes du

premier groupe, La seule diffrence est que dans le premier groupe, les rponses
de la classe 100 ne sont pas attendues et de ce fait sont traites comme une erreur,
tandis que le second groupe peut attendre (et parfois ncessiter) une rponse de
classe 100. Une rponse au plus de classe 100 est autorise par commande.
Les diagrammes restants donnent un modle pour des squences de
commandes, une des plus simples est la squence conduisant au renommage d'un
fichier :

+---+
RNFR
+---+
1,2
+---+
| B |---------->| W |---------->| E |
+---+
+---+
-->+---+
| |
|
3
| | 4,5
|
-------------- -----|
|
| |
+---+
|
------------->| S |
|
|
1,3 | |
+---+
|
2| -------|
| |
|
V
| |
|
+---+
RNTO
+---+ 4,5 ----->+---+
|
|---------->| W |---------->| F |
+---+
+---+
+---+

Le diagramme suivant propose un modle simple pour une commande de reprise :

+---+
REST
+---+
1,2
+---+
| B |---------->| W |---------->| E |
+---+
+---+
-->+---+
| |
|
3
| | 4,5
|
-------------- -----|
|
| |
+---+
|
------------->| S |
|
|
3
| |
+---+
|
2| -------|
| |
|
V
| |
|
+---+
cmd
+---+ 4,5 ----->+---+
|
|---------->| W |---------->| F |
+---+
-->+---+
+---+
|
|
| 1
|
--------

Dans lequel "cmd" est APPE, STOR, ou RETR.

Nous avons not que ces deux diagrammes apparaissent comme trs similaires.
La commande de reprise diffre de celle de renommage dans le seul traitement des
rponses de classe 100 du second tage, tandis que le second groupe attend (et

RFC959

48

parfois impose) une commande de classe 100. Souvenez vous qu'une seule
commande de classe 100 est permise pour une commande donne.
Le diagramme le plus complexe est pour l'ouverture d'une session (Login):
1
+---+
USER
+---+------------->+---+
| B |---------->| W | 2
---->| E |
+---+
+---+------ | -->+---+
| |
| | |
3 | | 4,5
| | |
------------------ | | |
|
| | | |
|
| | | |
|
--------- |
|
1|
| |
|
V
|
| |
|
+---+
PASS
+---+ 2 | ------>+---+
|
|---------->| W |------------->| S |
+---+
+---+
---------->+---+
| |
| |
|
3 | |4,5| |
|
--------------------|
|
| | | |
|
| | | |
|
----------|
1,3|
| | |
V
| 2| | |
+---+
ACCT
+---+-- |
----->+---+
|
|---------->| W | 4,5 -------->| F |
+---+
+---+------------->+---+

Enfin, nous prsenterons un diagramme gnralis qui peut tre utilis comme
modle universel d'un change de commandes et rponses :

-----------------------------------|
|
Begin
|
|
|
V
|
|
+---+ cmd
+---+ 2
+---+
|
-->|
|------->|
|---------->|
|
|
|
|
| W |
| S |-----|
-->|
|
-->|
|----|
|
|
|
+---+
|
+---+ 4,5 |
+---+
|
|
|
|
| |
|
|
|
|
|
1| |3
|
+---+
|
|
|
|
| |
|
|
|
|
|
|
---- |
---->| F |----|
|
|
|
|
|
|
|
+---+
------------------|
|
V
End

RFC959

49

7. SCENARIOS FTP TYPIQUES

Un utilisateur au port U voulant transfrer ou recevoir des fichiers d'un serveur S:
En gnral, l'utilisateur communique avec le serveur via la mdiation d'un
processus USER-FTP. Ce qui suit peut tre pris comme scnario typique. Les
"prompts" USER-FTP sont montrs entre parenthses, '---->' dsigne une
commande de l'utilisateur U vers l'hte S, et '<----' dsigne une rponse de l'hte S
l'utilisateur U.
COMMANDES LOCALES (Utilisateur)

ACTION IMPLIQUEE

ftp (host) multics<CR>

Connexion l'hte S, port L,

Etblissement du canal de contrle.
<---- 220 Service ready <CRLF>.
username Doe <CR>
USER Doe<CRLF>---->
<---- 331 User name ok,
need password<CRLF>.
password mumble <CR>
PASS mumble<CRLF>---->
<---- 230 User logged in<CRLF>.
retrieve (local type) ASCII<CR>
(local pathname) test 1 <CR>
Le USER-FTP ouvre un fichier local en
ASCII.
(for. pathname) test.pl1<CR>
RETR test.pl1<CRLF> ---->
<---- 150 File status okay;
about to open data
connection<CRLF>.
Le serveur tablit le canal de donnes
vers le port U.

type Image<CR>

<---- 226 Closing data connection,

file transfer successful<CRLF>.
TYPE I<CRLF> ---->
<---- 200 Command OK<CRLF>

store (local type) image<CR>

(local pathname) file dump<CR> Le USER-FTP ouvre le fichier local
sous Image.
(for.pathname) >udd>cn>fd<CR> STOR >udd>cn>fd<CRLF> ---->
<---- 550 Access denied<CRLF>
terminate
QUIT <CRLF> ---->
Le serveur ferme toutes les connexions

8. ETABLISSEMENT DE LA CONNEXION
Le canal de contrle FTP est tabli via TCP entre le port U du processus
utilisateur et le port L de l'hte serveur. Au protocole FTP est en effet assign le port
21 (25 octal), c'est dire L=21.

APPENDICE I - STRUCTURE DE PAGE

Le besoin de FTP de supporter la structure en pages de certains fichiers est
motive par le besoin de transferts de fichiers fiables entre des systmes TOPS-20,
et en particulier les fichiers utiliss par NLS.

RFC959

50

Le systme de fichiers d'un TOPS-20 est bas sur le concept de pages. Le

systme d'exploitation de cette plate-forme est bien plus performant lorsqu'il
manipule les fichiers sous cette forme. Le systme d'exploitation fournit en gnral
une interface vers le systme de fichiers afin que des applicatifs puissent voir les
fichiers comme des flux continus d'octets conformment l'usage le plus rpandu.
Cependant, certaines applications utilisent directement la structure sous-jacente en
pages.
Un fichier disque d'un TOPS-20 est compos de quatre lments: un chemin
d'accs, un table de pages, un ensemble de pages (peut tre vide), et un ensemble
d'attributs.
Le chemin d'accs est celui spcifi dans les commandes RETR ou STOR. Il
inclut le nom du rpertoire, le nom du fichier, l'extension de fichier, et un numro de
gnration.
La table de pages peut contenir jusqu' 2**18 entres. Chaque entre peut tre
marque EMPTY (vide), ou peut "pointer" sur une page. Si elle est non vide, elle
contiendra de plus quelques bits de marquage propres la page; les protections
d'accs sur les fichiers et sur chacune des pages peuvent tre gres
indpendamment.
Une page est un ensemble de 512 mots de 36 bits chacun contigus.
Les attributs du fichier, dans le descripteur de fichier (File Descriptor Block, ou
FDB), contiennent des informations telles que la date de cration, la date de
dernire criture, la date de dernire lecture, la taille d'octets logique de l'auteur, le
pointeur de fin de fichier, un dcompte des accs en lecture et en criture,
numrotation de sauvegarde, etc.
Notez qu'il n'est pas obligatoire que les entres soient contigus dans la table.
On pourra trouver des pointeurs de page vides entre deux pointeurs de pages
relles. De plus, la fin de fichier est simplement marque comme un nombre. Il n'est
pas obligatoire que cette fin de fichier pointe sur la dernire donne du fichier. Des
appels d'I/O squentiels basiques sur un TOPS-20 laissera le pointeur de fin de
fichier effectivement positionn aprs la dernire donne inscrite, mais d'autres
oprations peuvent trs bien ne pas laisser le pointeur cet endroit, si un
programme particulier le souhaite.
En fait, les deux cas particuliers d'un fichier discontinu (pages vides insres
entre des pages non vides) et d'un pointeur de fin-de-fichier n'indiquant pas la
dernire page du fichier, peuvent survenir dans un systme gr sous NLS.
Les fichiers pagins d'un TOPS-20 peuvent tre mis sous FTP en marquant les
paramtres de transfert ainsi : TYPE L 36, STRU P, et MODE S (en fait, tout mode
peut tre utilis).
Chaque page d'information dispose d'une en-tte. Chaque champ d'en-tte,
constitu d'un mot logique, est un mot du systme TOPS-20, dans la mesure o le
TYPE est L 36.
Ces champs d'en-tte sont :

RFC959

51

Mot 0: Header Length

Longueur d'en-tte

La longueur d'en-tte vaut 5.

Mot 1: Page Index.

Index de page

Si les donnes reprsentent une page d'un fichier sur disque, il s'agit du
numro de la page reporte dans la table de pages. Les pages vides (trous)
d'un fichier ne sont tout simplement pas transfres. Notez qu'un trou n'est
pas la mme chose qu'une page pleine de zros.
Mot 2: Data Length.

Longueur des donnes

La longueur des donnes situes dans la page et aprs l'en-tte,

exprime en mots logiques. De ce fait, la longueur totale transmise est la
somme de la longueur d'en-tte et de la longueur des donnes.
Mot 3: Page Type.

Type de page

Un code pour indiquer de quel type est le segment de donnes. Une

page de donnes a pour type 3, la page FDB a pour type 2.
Mot 4: Page Access Control.

Contrle d'accs de page

Les bits de contrle d'accs associs cette page de la table de pages.

(Le mot complet est mis dans l'AC2 d'un SPACS par le programme lisant
depuis le rseau vers le disque).
Juste aprs l'en-tte, on trouvera Data Length mots de donnes. Cette longueur
est couramment de 512 pour une page de donnes, et de 31 pour la FDB. Les zros
de bourrage d'une page peuvent tre omis, donnant ainsi une longueur de donnes
infrieure 512 si tel est le cas.

APPENDICE II - COMMANDES DE REPERTOIRE

UNIX disposant d'une structure de rpertoires en arbre dont les lments
(rpertoires) sont simples manipuler car compris comme des fichiers part entire,
il apparat utile d'tendre les fonctionnalits des serveurs FTP sur ce type de plateforme pour y adjoindre des commandes de manipulation de rpertoires. Dans la
mesure ou d'autres types d'htes de l'ARPA-Internet disposent aussi de structures
de rpertoires en arbre (y compris TOPS-20 et Multics), ces commandes ont t
ajoutes sous la forme la plus gnrique possible.
Quatre commandes de manipulation de rpertoire ont t adjointes la dfinition
de FTP :
MKD chemin d'accs
Cre un nouveau rpertoire de nom "chemin d'accs".

RFC959

52

RMD chemin d'accs

Efface le rpertoire de nom "chemin d'accs".
PWD
Imprime le nom du rpertoire de travail courant.
CDUP
Remonte au pre du rpertoire courant de travail. Le pre devient le
nouveau rpertoire de travail.
L'argument "chemin d'accs" devra tre cr (ou dtruit) au titre de sousrpertoire du rpertoire courant, sauf si la chane "chemin d'accs" contient
suffisamment d'information pour qu'il en soit fait autrement, ex., "chemin d'accs" est
exprim sous forme absolue (sous UNIX et Multics), ou ce chemin ressemble
quelque chose comme "<abso.lute.path>" sous TOPS-20.
CODES DE REPONSE
La commande CDUP est un cas particulier de la commande CWD, et est
disponible pour simplifier l'criture de programmes transfrant des arborescences
compltes entre des systmes qui notent par une syntaxe diffrente l'accs au
rpertoire pre. Les codes de rponse une commande CDUP sont identiques
ceux obtenus pour une commande CWD.
Les codes de rponse la commande RMD sont identiques ceux obtenus pour
son homologue "fichiers", DELE.
Les codes de rponse pour la commande MKD, par contre, sont un peu plus
compliqus. Un rpertoire nouvellement cr sera trs frquemment l'argument
d'une commande CWD ultrieure. Malheureusement, l'argument pass la
commande MKD n'est pas toujours exploitable directement par la commande CWD.
C'est le cas par exemple, lorsqu'un sous-rpertoire est cr sous TOPS-20 en
donnant juste le nom du sous-rpertoire. C'est dire, la squence suivante pour un
serveur FTP tournant sous TOPS-20
MKD MYDIR
CWD MYDIR
va chouer. Le nouveau sous-rpertoire ne peut en effet tre accd qu'en mode
"absolu"; ex., si la commande MKD avait t envoye pour un rpertoire courant
<DFRANKLIN>, l'accs au nouveau sous-rpertoire ne peut se faire que par la
spcification de <DFRANKLIN.MYDIR>.
Mme sous UNIX et Multics, l'argument pass MKD peut aussi ne pas
convenir. S'il s'agit d'un chemin "relatif" (c--d., un chemin interprt partir du
rpertoire courant), l'utilisateur devra ncessairement tre positionn dans ce
rpertoire initial pour atteindre le sous-rpertoire considr par cette expression.
Suivant l'application, cela peut se rvler inconfortable. Dans tous les cas, ce
principe manque de robustesse.

RFC959

53

Pour rsoudre ces problmes, et sur conclusion positive d'une commande MKD,
le serveur devrait retourner de prfrence la chane suivante :
257<espace>"<nom-rpertoire>"<espace><commentaire>
Le serveur, par l, indique quelle est la chane utiliser pour accder au
rpertoire nouvellement cr. Le nom de rpertoire peut contenir n'importe quels
caractres; un guillemet dans la chane devra tre doubl.
Par exemple, un utilisateur se branche sur le rpertoire /usr/dm, et cre un sous
rpertoire, appel "chemin":
CWD
200
MKD
257

/usr/dm
directory changed to /usr/dm
chemin
"/usr/dm/chemin" directory created

Voici un exemple avec un guillemet "dans le texte" :

MKD
257
CWD
200

foo"bar
"/usr/dm/foo""bar" directory created
/usr/dm/foo"bar
directory changed to /usr/dm/foo"bar

L'existence pralable d'un sous rpertoire de mme nom est considr comme
une erreur, et le serveur doit renvoyer une erreur "access denied".
CWD /usr/dm
200 directory changed to /usr/dm
MKD chemin
521-"/usr/dm/chemin" directory already exists;
521 taking no action.
Les rponses d'erreur pour MKD sont analogues son homologue "fichiers",
STOR. De mme, une rponse "access denied" est donne si le nom du rpertoire
entre en conflit avec un autre fichier existant pour ce chemin, quel que soit son type
(ceci est effectivement un problme d'UNIX, mais ne devrait pas en tre un sous
TOPS-20).
Comme la commande PWD renvoie le mme type d'information que la
commande MKD pour une conclusion positive, le code de rponse positive pour la
commande PWD utilisera galement le code 257.
SUBTILITES
Comme ces commandes seront les plus utiles pour transfrer des arborescences
d'une machine l'autre, il faudra se rappeler que l'argument donn MKD doit tre
interprt comme un chemin relatif par rapport au rpertoire courant, sauf si ce
chemin contient suffisamment d'information pour qu'il en soit autrement. Voici un
exemple hypothtique sur un systme TOPS-20 :

RFC959

54

CWD
200
MKD
257
CWD
431
CWD
200

<some.where>
Working directory changed
overrainbow
"<some.where.overrainbow>" directory created
overrainbow
No such directory
<some.where.overrainbow>
Working directory changed

CWD
200
MKD
257
CWD

<some.where>
Working directory changed to <some.where>
<unambiguous>
"<unambiguous>" directory created
<unambiguous>

Notez que le premier exemple se termine par la cration d'un sous rpertoire du
rpertoire courant d'accs. Par contre, l'argument donn dans la deuxime cration
fournit assez d'information au systme TOPS-20 pour que celui-ci puisse considrer
de faon univoque que le rpertoire crer doit l'tre partir de la racine. Notez
d'ailleurs dans le premier exemple, que l'utilisateur "viol" le protocole en essayant
d'accder directement au rpertoire nouvellement cr sans utiliser la chane
retourne par le systme TOPS-20. Le problme aurait pu tre masqu par
l'existence d'un rpertoire <overrainbow> au niveau haut de hirarchie; ceci est une
ambigut propre certaines implmentations du systme TOPS-20. Des
considrations similaires s'appliquent la commande RMD. Le cas est le suivant :
sauf l o cette manipulation violerait des conventions internes du systme pour la
description de chemins d'accs relatifs et absolus, l'hte doit traiter les arguments
des commandes MKD et RMD comme des sous rpertoires relatifs. La rponse de
code 257 une commande MKD doit toujours renvoyer le chemin d'accs absolu
nouvellement cr.

APPENDICE III - RFC propos de 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.

RFC959

55

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.
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

RFC959

56

(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.
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,

RFC959

57

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.

REFERENCES
[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.

RFC959

58