RFC 949 (rfc949) - Page 1 of 2

FTP unique-named store command

Network Working Group                                     Mike Padlipsky
Request for Comments: 949                                          Mitre
Semisupersedes RFC 505                                         July 1985

                     FTP UNIQUE-NAMED STORE COMMAND


STATUS OF THIS MEMO

   This RFC proposes an extension to the File Transfer Protocol for the
   ARPA-Internet community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

DISCUSSION

   There are various contexts in which it would be desirable to have an
   FTP command that had the effect of the present STOR but rather than
   requiring the sender to specify a file name instead caused the
   resultant file to have a unique name relative to the current
   directory.  This would be useful for all sorts of "pool" directories;
   the directories that serve as queues for printer daemons come
   immediately to mind (so do fax and even cardpunch daemons' queues),
   although naturally the sort of printer queue that a local command has
   to manage the interface to isn't what's meant by "pool" in this
   context.

   If we accept the need for such an FTP extension, and that it should
   not be done with an "X" command because it needs to be relied on
   "everywhere," the interesting question then becomes how to mechanize
   it.  Probably the most natural way to do it would be either to add a
   "control argument" of -UNM to the syntax of STOR, now that there are
   enough UNIXtm's around so that this good old Multics trick isn't
   alien any more, or even to declare that STOR with no argument should
   cause a directory-unique name to be generated.  However, either of
   these would necessitate "reopening" the STOR command code, which is a
   distasteful sort of exercise.  Since most FTP's presumably do a
   dispatch sort of thing off a list of command names to begin with,
   then, an additional command would seem to be the way to go.

   Naming the command calls for a bit of thought.  STore Uniquely Named
   (-> STUN) is silly; UNIQue comes to close to free advertising or even
   trademark infringement (and confuses fingers if you're typing); Store
   Uniquely NaMed (-> SUNM) doesn't avoid free advertising either;
   Uniquely Named STore (-> UNST) might look like a synonym for DELEte,
   though it's not all that bad; SToRe Uniquely named (-> STRU) is
   taken; and so it goes.  The best bet seems to be STOU.

   Of somewhat more practical import, there's also the question of
   whether the sender needs to be apprised of what the unique name
   turned out to be.  Intuitively, sometimes this would be the case and
   sometimes it wouldn't.  Making it optional is almost certainly too


Padlipsky