C'est un très vieux projet qui voit enfin le jour avec ce
RFC : documenter les différentes commandes qu'a
accumulé le vénérable protocole FTP, après
vingt-quatre ans d'existence sous sa forme actuelle (spécifiée par le
), et d'innombrables extensions ajoutées sans trop de
coordination. FTP, qui a commencé en 1971, sous le nom de
Data Transfer Protocol (), reste
très utilisé un peu partout et l'absence d'un registre de ses
commandes et extensions pouvait entrainer des problèmes de
portabilité.
Certaines des extensions suivaient le cadre du ,
qui normalisait un mécanisme commun, souvent désigné sous le nom de
FEAT (FEATure). Mais ce n'est pas le cas de
toutes. Désormais, ou pas, toutes les commandes et
extensions sont dans un registre
unique.
Ce registre est décrit en section 2. Nommé FTP Commands and Extensions, il comprend notamment, pour
chaque entrée, les informations suivantes :
Nom de la commande (en MAJUSCULES), s'il y en a une (certaines
extensions impliquent plusieurs commandes et, dans ce cas, il n'y a
pas de nom de commande). Par exemple, LIST
(obtenir la liste des fichiers distants) ou PROT+ (cette dernière
étant, comme son nom l'indique, une modification de
PROT, qui permet de spécifier le niveau de
sécurité requis pour un transfert, voir , section 9).Le nom de l'extension, par exemple MDTM
(date de modification d'un fichier, cf. ) ou
hist (fourre-tout pour les vieilles extensions, abandonnées). Si l'extension
suit le cadre du , pas de problème, ce nom est celui
donné en réponse à la commande FEAT et il est
noté en MAJUSCULES. Sinon un nom est inventé et indiqué en minuscules.
Le caractère obligatoire ou bien facultatif de cette
extension. 'm' signifie mandatory (obligatoire),
'o' optional (facultatif) et 'h'
historic (abandonné).
Notre contient en section 3 le registre
initial (on peut trouver la version actuelle en
ligne). Il contient plusieurs codes « pseudo-FEAT » (qui
n'utilisent pas réellement le système FEAT du et
sont donc écrits en minuscules), comme base
(commandes obligatoires), secu (extensions de
sécurité du ), ou nat6 (extensions
pour aider avec les NAT ou avec
IPv6, dans le ).
C'est ainsi que la commande AUTH est
enregistrée comme AUTH+ pour tenir compte des
extensions TLS qui avaient été normalisées dans
le . On trouve aussi, par exemple, une commande
LANG, normalisée dans le , et
qui permet d'internationaliser FTP, entre
autres en demandant des messages dans d'autres langues que l'anglais.
Les sections 2.4 et 2.5 donnent des explications sur la création du
registre initial, à partir des commandes de base (),
toutes obligatoires (comme USER, ou
RETR, l'équivalent du GET de
HTTP) ou
d'essais depuis abandonnés (par exemple par le ).
Créer un registre est une chose, mais il faut le faire vivre
ensuite : il est prévu que de nouvelles extensions à FTP soient
enregistrées. Selon quels critères ? La section 2.3 (et la section 5) les
formalise. L'idée est que le registre sert à éviter les conflits dans
les codes utilisés. Il ne signifie pas que les extensions qu'il liste
sont « approuvées » ou bien qu'elles représentent une « bonne
idée ». Les vérifications faites avant l'enregistrement sont :
Qu'une spécification publique de l'extension existe, par exemple
un RFC. Tout RFC convient. Pour les autres
documents, l'expert appelé pour vérifier l'enregistrement devra
s'assurer que l'autre document a bénéficié d'un examen sérieux.Que l'extension a effectivement été mise en œuvre dans un
client ou un serveur FTP (dans la tradition du running
code de l'IETF).
C'est uniquement si l'extension doit être marquée comme obligatoire
qu'il faudra un RFC de statut « Chemin des normes ».
Ces règles sont donc une légère variante des règles « Norme nécessaire »
et « Examen par un expert » du .