RFC 505 (rfc505) - Page 2 of 3

Two solutions to a file transfer access problem

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