Rick Kirkham <RKIRKHAM@AARDVARK.UCS.UOKNOR.EDU> (02/26/90)
Cliff Frost writes:
{I think BITNET is the name
{for a collection of services, most built on top of NJE connectivity.
{As long as users want these services BITNET will thrive.
{Running NJE over TCP/IP allows these services to be complementary...
{you
{can run either UUCP or NJE or both on top of IP if you want
{those services.
I know of no service provided by either Bitnet or UUCP that cannot be
easily duplicated (and for the most part already is duplicated) on
the Internet.
Why deal with the technical headaches of running one protocol over
another?
None of the recent posting have succeeded in justifying the continued
existence of Bitnet beyond the time when the forthcoming Edunet is
fully independent/operational. On the other hand, I can see a future
for the PEOPLE who run Bitnet and Bitnic: The Edunet, after all, is
going to need a network information center.
Dept. of Philosophy/U of Oklahoma/Norman OK 73019
rkirkham@aardvark.ucs.uoknor.edu
rkirkham@uokucsvx (Bitnet)
aa9927@uokmvsa (Bitnet)"Bryan, Jerry" <U0A61@WVNVM.bitnet> (02/26/90)
>I know of no service provided by either Bitnet or UUCP that cannot be >easily duplicated (and for the most part already is duplicated) on >the Internet. Not true. The Internet does not have interactive messaging capability. It does not have the ability to send files asynchoronously without passwords, and with the transmission being initiated on the sending side. In other words, it lacks "mail" like service for file transfer. Hence, people sometimes tend to encode files inside of mail, which is not a very satisfactory replacement for true file transfer.
Cliff Frost {415} 642-5360 <CLIFF@UCBCMSA.bitnet> (02/26/90)
>I know of no service provided by either Bitnet or UUCP that cannot be >easily duplicated (and for the most part already is duplicated) on >the Internet. Then drop off (or out of) BITNET. I certainly don't recommend running NJE or UUCP over IP unless you or the users you serve detect enough value from it to justify the effort! >Why deal with the technical headaches of running one protocol over >another? I hope you're not asking 'why bother running IP?'... ;-) The group I'm in doesn't do UUCP for folks--there's been very little demand for it, if any. We do BITNET because of the massive demand for it, and because it is much more economical than trying to duplicate the functionality for our users in any other way. There are people I know who find great value in UUCP over IP, though, and so they do it where they need to--it isn't really all that hard. And all of us are IP bigots. Cliff
Mark Bodenstein <MAB@CORNELLC.bitnet> (02/27/90)
On Sun, 25 Feb 90 17:32:00 CST Rick Kirkham said: > ... >I know of no service provided by either Bitnet or UUCP that cannot be >easily duplicated (and for the most part already is duplicated) on >the Internet. >Why deal with the technical headaches of running one protocol over >another? > >None of the recent posting have succeeded in justifying the continued >existence of Bitnet beyond the time when the forthcoming Edunet is >fully independent/operational. ... This discussion has also been going on on the POLICY-L@BITNIC list. The following is an excerpt from a message I posted there. Many of these points have been responded to there, in various ways. I can only refer you to the LISTSERV archives at BITNIC for those responses. Here are the things I can think of that Bitnet currently provides that the Internet doesn't: - Low cost connection for institutions that don't already have TCP/IP connectivity. - Connectivity to peer NJE networks in Europe, Canada, Mexico, Japan and Scandinavia (and I'm probably forgetting some others.) Some of these places support TCP/IP, but others currently do not. - Sender-initiated no-recipient-password-required file transfer. This allows sending files - when the sender wishes to - with no write access to recipient disks needed - with no recipient password needed. It makes possible the file distribution functions of LISTSERV and NETSERV, including automatic file distribution. Bitnet-style sender-initiated file transfer has been discussed of late in the TCP/IP community, but is not provided by any of the standard TCP/IP applications. It may be difficult to make generally available on the Internet because it has operating system implications. - Interactive messages. One could consider creating such a service based on UDP, but again this is not currently provided on the Internet. This allows both human-to-human almost-real-time discussions, and also a very nice transport mechanism for user-to-server commands and server- to-user responses. (e.g. TELL LISTSERV AT node SUBSCRIBE ...). Mark Bodenstein (mab@cornellc; 607-255-3747) Cornell University
Anthony J Stieber <astieber@csd4.csd.uwm.edu> (02/28/90)
In article <FUTURE-L%90022613392247@UGA.BITNET> BITNET Futures List <FUTURE-L@BI >>I know of no service provided by either Bitnet or UUCP that cannot be >>easily duplicated (and for the most part already is duplicated) on >>the Internet. > >Not true. The Internet does not have interactive messaging capability. >It does not have the ability to send files asynchoronously without >passwords, and with the transmission being initiated on the sending >side. In other words, it lacks "mail" like service for file transfer. >Hence, people sometimes tend to encode files inside of mail, which is >not a very satisfactory replacement for true file transfer.
"Bryan, Jerry" <U0A61@WVNVM.bitnet> (02/28/90)
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.
Dave Buechner <DBUECHNE@GTRI01.bitnet> (02/28/90)
On Tue, 27 Feb 90 17:07:00 CST Rick Kirkham said: > 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 >"interactive" messages of NJE, these conversations are in real time. As has been pointed out (I believe by John Wagner) the NJE messages are pretty close to real time. And they are created and received with standard easy to use programs. Part of the problem with interactive messages in the Internet is pointed out by your message; you use a program "usually" called PHONE "or" TALK. Such programs have grown up in the Unix world as far as I know. They're not really defined standard TCP/IP applications that are expected to be implemented in even the quasi-consistent way of some of the other applications (such as FTP). Besides which, personally, the asynchronous nature of NJE messages is very helpful. I can send a message, and go back to what I was doing. And I can be sent a message no matter what program I am/am not running. This has helped me provide "support" to people having problems with my site no matter where they are. Again, this is not to say that PHONE and TALK and company are not valid ways of doing some interactive messaging. They do not currently cover all of the bases. > Finally, please note that my assertion was that all Bitnet/UUCP >services _can_ be duplicated in the Internet, not that all of them ac- >tually are at the moment. E.g. some Usenet groups are not echoed as >Internet SIGs. But they perfectly well could be. > I think many of us realize that, and realized it from the start. But let's be clear on what others are saying. There are no complaints about whether it is possible to implement Bitnet's services in the Internet, but there is valid concern about the fact that they are not there *now* and that noone is as yet working on them as far as most of us can tell. Until that happens and we all get a chance to play with it there is a need fulfilled by Bitnet that is not fulfilled anywhere else and hence the "death of Bitnet" is premature. >Rick Kirkham Dave Buechner Lead IBM Systems Programmer Georgia Institute of Technology, Atlanta, GA, USA