summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc949.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc949.txt')
-rw-r--r--doc/rfc/rfc949.txt113
1 files changed, 113 insertions, 0 deletions
diff --git a/doc/rfc/rfc949.txt b/doc/rfc/rfc949.txt
new file mode 100644
index 0000000..f6ee991
--- /dev/null
+++ b/doc/rfc/rfc949.txt
@@ -0,0 +1,113 @@
+
+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 [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 access control, authentication, and accounting
+ mechanisms Hosts might have in play before the user can do an old
+ STOR or a new STOU, but with suitable publicized ID's and passwords
+ it could be almost as good as the proposal made in RFC 505.
+
+RECOMMENDATION
+
+ Add a new command, STOU, to FTP, which behaves like STOR except that
+ the resultant file is to be 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 any more).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Padlipsky [Page 2]
+