As per Relevance of the word suitable, we have this rfc below:
Network Working Group Mike
Request for Comments: 949
Semisupersedes RFC 505 July 1985
FTP UNIQUE-NAMED STORE
STATUS OF THIS
This RFC proposes an extension to the File Transfer Protocol for
ARPA-Internet community, and requests discussion and suggestions
improvements. Distribution of this memo is unlimited
There are various contexts in which it would be desirable to have
FTP command that had the effect of the present STOR but rather
requiring the sender to specify a file name instead caused
resultant file to have a unique name relative to the
directory. This would be useful for all sorts of "pool" directories
the directories that serve as queues for printer daemons
immediately to mind (so do fax and even cardpunch daemons' queues),
although naturally the sort of printer queue that a local command
to manage the interface to isn't what's meant by "pool" in
context
If we accept the need for such an FTP extension, and that it
not be done with an "X" command because it needs to be relied
"everywhere," the interesting question then becomes how to
it. Probably the most natural way to do it would be either to add
"control argument" of -UNM to the syntax of STOR, now that there
enough UNIXtm's around so that this good old Multics trick isn'
alien any more, or even to declare that STOR with no argument
cause a directory-unique name to be generated. However, either
these would necessitate "reopening" the STOR command code, which is
distasteful sort of exercise. Since most FTP's presumably do
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
(-> STUN) is silly; UNIQue comes to close to free advertising or
trademark infringement (and confuses fingers if you're typing);
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)
taken; and so it goes. The best bet seems to be STOU
Of somewhat more practical import, there's also the question
whether the sender needs to be apprised of what the unique
turned out to be. Intuitively, sometimes this would be the case
sometimes it wouldn't. Making it optional is almost certainly
Padlipsky [Page 1]
RFC 949 July 1985
FTP Unique-Named Store
much like work, though--even if it does have the subtle virtue
finally getting control arguments into FTP. Therefore, why not
include it in a suitable response-code's free text field (unless,
course, an avalanche of comments comes in urging it not be done
all)?
Note, by the way, that the intent here is emphatically not
sidestep whatever access control, authentication, and
mechanisms Hosts might have in play before the user can do an
STOR or a new STOU, but with suitable publicized ID's and
it could be almost as good as the proposal made in RFC 505.
Add a new command, STOU, to FTP, which behaves like STOR except
the resultant file is to be created in the current directory under
name unique to that directory. The 250 Transfer Started
should include the name generated (unless the copy of FTP I have
so old that 250 isn't the right number any more).
Padlipsky [Page 2]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
