Browse Prior Art Database

FTP unique-named store command (RFC0949) Disclosure Number: IPCOM000004945D
Original Publication Date: 1985-Jul-01
Included in the Prior Art Database: 2001-Jul-12
Document File: 3 page(s) / 4K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

M.A. Padlipsky: AUTHOR



This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 83% of the total text.

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



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.


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 [Page 1]

RFC 949 July 1985 FTP Unique-Named Store Command

much like work, though--even if it does have the subtle virtue of finally getting control arguments into FTP. Therefore, why not just include it in a suitable response-code's free text field (unless, of course, an avalanche of comments comes in urging it not be done at all)?

Note, by the way, that the intent here is emphatically not to sidestep whatever ac...