Path: utzoo!utgpu!BITNIC!FUTURE-L Date: Wed, 28 Feb 90 10:10:29 EST Reply-To: BITNET Futures List Sender: BITNET Futures List From: "Bryan, Jerry" Subject: fall of bitnet To: UofToronto LAN redistribution References: Message of 02/27/90 at 17:07:00 from , Message-ID: <90Feb28.174214est.57410@ugw.utcs.utoronto.ca> Newsgroups: list.future-l Distribution: ut Approved: devnull@gpu.utcs.toronto.edu If I may say so, I found this to be an *excellent* note, not because I agree with it (I don't), but because it made the issues clear and tangible. > Several people have objected to my earlier assertion that there is >no service provided by either Bitnet or UUCP that cannot be duplicated >on the Internet. One of the objections is more or less well-taken, but >two others perpetuate certain myths about the Internet that are >prevalent in the Bitnet community. > The one which is well-taken is that in (very) rare circumstances >mail and/or files on the Internet will be lost due to its lack of a >store-and-forward capability. But this is not a very strong objection >since there are also circumstances in which NJE files or mail can be >lost or garbled. I know of no statistics on this, but in my experience >the Internet is more reliable. > The first of the myths is that the Internet does not provide >sender-initiated, no-recipient-password-required, no-special- >encoding/decoding-required file transfer. Look, I can send a file via >NJE by entering at my system prompt: > SEND/FILE filename recipient's-address >But I can also send the same file, via TCP/IP by entering at the >system prompt: > MAIL filename recipient's-address >I initiate the transfer in both cases. In neither case do I or the >recipient need any passwords other than our own login passwords. There >is encoding involved in both cases, but it is done invisibly. Neither >I nor the recipient need give any special encoding or decoding com- >mands. In the NJE transfer the recipient MUST copy the file to his >home directory/catalog. In the TCP/IP transfer, the file arrives as >mail in his mailbox. (He has the OPTION of moving it to another direc- >tory, but a simple "extract" command does this -- and automatically >decodes the file to boot.) No, no, no. This facility DOES NOT EXIST in any of the computing world with which I am familiar -- VM, MVS, VAX. In general, you can "sort of" include a file, as long as it is a text file not requiring encoding, and as long as line length requirements are not exceeded, etc. Also, the file must not include anything that could in anyway be interpreted as mail headers, etc. But a full blown, transparent, encoded mail envelope of an arbitrary file is not supported. Remember that a VM site can send a binary or executable file to another VM site over BITNET. I cannot do that over the Internet except with FTP. There are all sorts of gateway and character set issues to resolve if files are sent as mail, such as tabs and ASCII-EBCDIC conversion, national language conversion, etc. Actually, I agree that the facility you describe *should* be supported, and that it would solve the asynchonous, no-password, sender initiated file transfer problem on the Internet. However, I have participated in discussions about this intermittently through the years, and there seems to be a substantial body of opinion that mail is *not* a satisfactory transfer agent for files. The mail programs on some Internet nodes >may not make things this easy, but that is a failing of the mail >program, not the Internet protocol. There is in fact a second way to >do file transfer on the Internet. I can use FTP to park the file on a >public directory of the recipients computer, where he can print it, No, no, no. The keyword is "public". This is not satisfactory from a security viewpoint. >read it, or copy it to his own directory as he likes. Or I can park it >on a public directory of my node and he can FTP it himself. In both Once again, "public" is not satisfactory. In addition, the transfer is no longer sender initiated. >cases, I initiate the transfer, no special passwords are needed, and >normally no special encoding. > The second myth is that the Internet cannot provide interactive >messages. In fact, it can. And many (most?) Internet nodes have a >program, usually called PHONE or TALK, which allows conversations be- >tween users anywhere in the country. Moreover, unlike the so-called Again, please educate me further. Nothing I am familiar with can do this. Is this UNIX only? I think VAX/VMS has PHONE, but I didn't know it would go across the Internet. I certainly am not familiar with a PHONE in the IBM world. >"interactive" messages of NJE, these conversations are in real time.