Groupe de travail Réseau	Mike Padlipsky, Mitre	
Request for Comments : 949	juillet 1985	
Remplace la RFC 505	Traduction Claude Brière de L’Isle	

Commande FTP Store à dénomination unique

Statut de ce mémoire
La présente RFC propose une extension au protocole de transfert de fichier pour la communauté ARPA-Internet, et appelle à la discussion et à des suggestions pour son amélioration. La distribution du présent mémoire n’est soumise à aucune restriction.

Discussion

Il y a divers contextes dans lesquels il serait souhaitable d’avoir une commande FTP qui ait pour effet la présente commande STOR mais plutôt que d’exiger que l’envoyeur spécifie un nom de fichier qui fasse que le fichier résultant ait un nom unique par rapport au répertoire actuel. Cela serait utile pour toutes sortes de répertoires "réservoirs" ; les répertoires qui servent de file d’attente pour les automates d’imprimante viennent immédiatement à l’esprit (ainsi que les files d’attentes de télécopieur et même des automates à carte perforée) bien que naturellement les sortes de files d’attente d’imprimante qu’une commande local a pou gérer l’interface ne soient pas ce qu’on entend par "réservoir" dans ce contexte.

Si on accepte la nécessité d’une telle extension à FTP, et qu’elle ne devrait pas être faite avec une commande "X" parce qu’elle doit être fiable "partout", la question intéressante devient alors comment la mécaniser. La façon qui est probablement la plus naturelle pour le faire serait soit d’ajouter un "argument de commande" de -UNM à la syntaxe de STOR, maintenant qu’il y a suffisamment de UNIXtm dans le paysage pour que le bon vieux truc du Multics soit tout à fait familier, soit même de déclarer que STOR sans argument devrait causer la génération d’un nom de répertoire unique. Cependant, l’une et l’autre de ces solutions nécessiteraient de "rouvrir" le code de la commande STOR ce qui est un genre d’exercice qui ne plait à personne. Comme la plupart des mises en œuvre de FTP commencent probablement par répartir les choses à partir d’une liste de noms de commandes, une commande supplémentaire semble être la direction dans laquelle il faut aller.

Donner un nom à la commande demande un peu d’imagination. STore Uniquement Nommé (-> STUN) est stupide; UNIQue est trop proche des publicités libres ou même de la violation de propriété commerciale (et introduit une certaine confusion dans la frappe sur le clavier) ; Store Uniquement NoMMé (-> SUNM) n’évite pas non plus la marque commerciale ; Uniquement Nommé STore (-> UNST) pourrait sembler un synonyme de DELEte (supprimer) bien que ce ne soit pas si mauvais ; on prend SToRe Uniquement nommé (-> STRU) et ça passe. Le meilleur pari semble être STOU.

D’importance plus pratique, il y a aussi la question de savoir si l’envoyeur a besoin d’être informé de ce que le nom unique se trouve être. Intuitivement, on peut dire que parfois ce sera le cas, et parfois ce ne le sera pas. Le rendre facultatif est presque certainement le plus simple, bien que – même si cela n’a pas la vertu subtile de donner finalement des arguments de contrôle dans FTP. Donc, pourquoi ne pas juste l’inclure dans un champ de texte libre d’un code de réponse convenable (sauf, bien sûr si une avalanche de commentaires me somme de n’en rien faire ) ?

Noter en passant, que l’intention n’est assurément pas de mettre de côté quel que mécanisme de contrôle d’accès, d’authentification, et de comptabilité que les hôtes pourraient avoir en jeu avant que l’utilisateur puisse faire un vieux STOR ou un nouveau STOU, mais avec des identifiants et mots de passe convenablement annoncés, cela pourrait faire une proposition au moins aussi bonne que celle de la RFC 505.

Recommandation

Ajouter une nouvelle commande, STOU, à FTP, qui se comporte comme STOR sauf que le fichier résultant est à créer dans le répertoire en cours sous un nom unique au sein de ce répertoire. La réponse 250 Transfert commencé devrait inclure le nom généré (sauf si la copie de FTP que j’ai est si vieille que 250 ne serait plus le bon numéro).