Mon blog

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 RFC 959), et d'innombrables extensions ajoutées sans trop de coordination. FTP, qui a commencé en 1971, sous le nom de Data Transfer Protocol (RFC 171), 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 RFC 2389, 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, RFC 2389 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 RFC 4217, section 9).
• Le nom de l'extension, par exemple MDTM (date de modification d'un fichier, cf. RFC 3659) ou hist (fourre-tout pour les vieilles extensions, abandonnées). Si l'extension suit le cadre du RFC 2389, 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 RFC 5797 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 RFC 2389 et sont donc écrits en minuscules), comme base (commandes obligatoires), secu (extensions de sécurité du RFC 2228), ou nat6 (extensions pour aider avec les NAT ou avec IPv6, dans le RFC 2428).

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 RFC 4217. On trouve aussi, par exemple, une commande LANG, normalisée dans le RFC 2640, 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 (RFC 959), toutes obligatoires (comme USER, ou RETR, l'équivalent du GET de HTTP) ou d'essais depuis abandonnés (par exemple par le RFC 1123).

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