Path: utzoo!utgpu!BITNIC!FUTURE-L Date: Tue, 27 Feb 90 21:22:59 EST Reply-To: BITNET Futures List Sender: BITNET Futures List From: John C Klensin Subject: Re: Re: The fall of Bitnet Comments: To: FUTURE-L%BITNIC.BITNET@MITVMA.MIT.EDU To: UofToronto LAN redistribution Message-ID: <90Feb27.212151est.57400@ugw.utcs.utoronto.ca> Newsgroups: list.future-l Distribution: ut Approved: devnull@gpu.utcs.toronto.edu Ignoring the question for the moment of what we presumed-Internet-bigots can learn from BITNET, I've seen one assumption go by that may be worth questioning as people propose migrating services. To a considerable extent, the absence of a sender-initiated file transfer mechanism on the Internet was a rather deliberate design decision, not an accident. Sure, there are some operating system issues, but there are also ways to get around most of them. The theory was that you should have my explicit permission before transmitting a large file into my disk space. This was important in the early days of the ARPANET when "big" computers had fairly small (by today's standards) disk capacity. But it is perhaps equally relevant today, when the modal "Internet machine" in many places is increasing tending to be a fairly "small" workstation, again with limited disk capacity and, perhaps, the "ability" for its other work to be brought to a complete halt while receiving a large file. The last time I looked, there was no sender-only file transfer mechanism in ISO OSI FTAM, either, possibly for similar reasons as well as (possibly) a protocol concern in much of the ISO and CCITT OSI work that has not significantly influenced Internet or BITNET protocol development: making sure someone can be found to pay whatever bills the "administrations" feel like rendering. Back in the early days of the ARPANET, there was a project to build a central archival data store--a "datacomputer"--and, because that device was conceived as using rather slow archival media, the question of a server initiating a file transfer without being a user on the remote machine was addressed (this is the issue referred to in an earlier transaction as the requirement for this type of file transfer in order to permit things like LISTSERV to work). If I recall (it's been 16 or 17 years), there were notions about attaching to a datacomputer server, specifying the retrieval request, and then leaving some sort of one-use-only authorization chit such that, when it was ready, the datacomputer server could initiate a file transfer to your machine using that authorization. That kind of capability would provide all of the capability that BITNET's sender-only transfers do, with none of the dangers, and, with today's technology for, e.g., public key encryption, it should be more feasible than it was a few decades ago. However, when I made some inquiries a few years ago, I could not discover *any* current research in the area of making a connection to a remote server, depositing a request, breaking the connection, and having the response to the request delivered through a secure/with permission/ authenticated mechanism. The proposed OSI RDA protocols were no help the last time I looked, and an inquiry to the relevant working group produced one of those "my this is an interesting problem, no one is thinking about it" responses. Now, ignoring the problem and deciding that the sender should be able to send off anything to anyone, as in BITNET, is certainly a possible solution. But it may not be extremely attractive when people have to pay for lines, packets, and incoming messages and files. And BITNET folks, before advocating it as a general solution, should perhaps contemplate the robustness of their systems and networks, in the presence of an attack based on the unsolicited receipt of a lot of large files. john klensin Klensin@INFOODS.MIT.EDU -------