RFC 949

RFC 949: FTP Unique-Named Store Command 💖

Okay bestie, this is RFC 949, written by Mike Padlipsky at Mitre in July 1985 🎀 It's from the Network Working Group, and it's a proposal that semisupersedes RFC 505 ✨ Let's get into it 💅

Status of This Memo 🌸

This RFC proposes an extension to the File Transfer Protocol for the ARPA-Internet community, and it's asking everyone to share discussion and suggestions for improvements 🫶 Distribution of this memo is unlimited 🌈

Discussion 💜

Okay so there are lots of situations where you'd want an FTP command that does what the current STOR does, but instead of the sender picking a file name, it makes the resulting file get a name that's unique relative to the current directory 😭 This is giving "pool" directories. The queues for printer daemons come to mind immediately, and so do the queues for fax and even cardpunch daemons 🖨️ To be clear though, the kind of printer queue a local command manages isn't what "pool" means here 🙈

If we agree that an FTP extension like this is needed, and that it shouldn't be an "X" command because it has to be relied on "everywhere," then the real question is how to actually build it 🧠 The most natural options would be adding a -UNM "control argument" to STOR (it's a good old Multics trick, and there are enough UNIXtm's around now that it isn't alien anymore 👑), or declaring that STOR with no argument should generate a directory-unique name. But both of those mean "reopening" the STOR command code, which is a super distasteful exercise 💀 Most FTPs presumably dispatch off a list of command names anyway, so a brand new command seems like the move ✨

Naming it is a whole thing 😂 Here's the tea on the candidates:

• STUN (STore Uniquely Named) is silly 💀
• UNIQ comes too close to free advertising or even trademark infringement, and it confuses fingers if you're typing 🙃
• SUNM (Store Uniquely NaMed) doesn't avoid the free advertising problem either 😬
• UNST (Uniquely Named STore) might look like a synonym for DELE, though it's not all that bad 🤷‍♀️
• STRU (SToRe Uniquely named) is already taken 😤

And so it goes 💅 The best bet seems to be STOU 🦋

There's also a more practical question: does the sender need to know what the unique name ended up being? Intuitively, sometimes yes and sometimes no 🤔 Making it optional would be almost certainly too much work, even though it has the subtle virtue of finally getting control arguments into FTP 🎀 So why not just put the name in a suitable response code's free text field? Unless, of course, an avalanche of comments comes in urging that it not be done at all 😭

Also, super important: the point here is emphatically not to sidestep whatever access control, authentication, and accounting mechanisms Hosts might have in play before the user can do an old STOR or a new STOU 🚨 With suitably publicized ID's and passwords, though, it could be almost as good as the proposal made in RFC 505 🔐

Recommendation 👑

Add a new command, STOU, to FTP ✨ It behaves like STOR, except the resulting file is created in the current directory under a name unique to that directory 🦋 The 250 Transfer Started response should include the name generated 🫶 (Unless the copy of FTP I have is so old that 250 isn't the right number anymore, periodt 💀)