RFC 505 (rfc505) - Page 2 of 3
Two solutions to a file transfer access problem
Alternative Format: Original Text Document
RFC 505 Two Solutions to a File Transfer 25 June 1973
[1]
This second solution has the virtue of requiring fewer steps than the
first, and would work even when the first wouldn't; so even though it
would require another FTP command, I propose the addition of a new
FTP "POOL" command, which does what the last paragraph described.
Depending on the various Servers' protection mechanisms, the pooled
files could be made readable only by the declared recipients. This
would, for example, offer an easy way to get some privacy for "mail"
(which otherwise is likely to be readable by anybody who can write
it), although other solutions to that particular problem of course
exist. At any rate, the POOL command's syntax would be POOL id name
where id is a valid user identifier on the Server, and name is the
desired name to be placed on the about-to-be-transferred file in the
Server's pool directory. (*) (Servers must, of course, do whatever
pre- or post-fixing to name is necessary to make it unique within the
pool.) The transfer then takes place in the same manner as with
STOR, and on successful completion the Server sends a message to id
that he should pick up name (suitably) modified to look like a local
pathname) if he wants it. The message should also identify the
putative sender (even though it might have come in from a free
account). The id should, naturally, be validated before starting the
transfer.
The question has been raised locally as to why we don't simply take a
pooled view of STOR on Multics and forget about pushing for a new
command. To do so would have two drawbacks, I feel: first, I think
we'd be remiss in our duty as NWG participants if we failed to
attempt to offer solutions to protocol problems to the Network
community as a whole. Second, on a less pious but more practical
note, if we don't know the id we have to infer it from the pathname,
which rules out abbreviations and forces senders to have to know too
much about our internal structure. (The alternative of requiring an
additional argument to the STOR is subject to the same objection. It
is also subject to the objection that protocols really shouldn't be
unilaterally extended. Of course, we could go to "site-specific
parameters", but that's complicating life so much that the
alternative of no unsolicited files seems preferable.) Therefore, I
think that POOL would be worthwhile unless no other Servers have
enough access control for it to be necessary anywhere but on Multics.
At the very least, having the protocol specify an "access id"
optional argument to STOR seems desirable.
[2]
Input as to whether any of the other Servers has file access control
abilities similar to those of Multics would be useful in clarifying
whether this whole area is one which needs specific treatment at the
Padlipsky