Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!usc!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!CS.UMD.EDU!chris From: chris@CS.UMD.EDU (Chris Torek) Newsgroups: comp.protocols.tcp-ip Subject: Re: BITNET -- Internet capabilities Message-ID: <8910282012.AA20961@mimsy.UMD.EDU> Date: 28 Oct 89 20:12:11 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 39 >From: jqj@rt-jqj.Stanford.EDU (JQ Johnson) > >This ... is usually implemented as writing the files to a remote spool >area where disk space is charged to the system rather than the target >user, and the target user may retrieve the files or not within some >reasonable time. ... The key feature that it has which SMTP-based email >lacks is a standard (sort of) for sending non-textual data. X.400 with >its provision for arbitrary binary attachments may make this BITNET >feature obsolete. But Internet-only users should not be so >narrowminded as to think that ftp is the "one true way" to manage file >transfer! % ftp remotehost.biguniv.edu User: anonymous Password: me@here type image put local-file incoming/remote-file quit Now all we need is to write it up as an RFC (changing the `put local-file incoming/remote-file' sequence to a new `give' command, so that the `incoming/' can go away), and write a front end called `give' or whatever that does the above automatically. Hosts can expire stuff in ~ftp/incoming, or whatever they name this spool directory, as often as desired. In other words, we need only one change to the FTP protocol (to add a command that means `I am sending you a file that you should put in your spool directory, whatever its name may be'), along with some front ends so that `given' files are handled much like mail: spooled on the local machine until the transfer can happen. -- `They were supposed to be green.' In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris