Path: utzoo!utgpu!BITNIC!FUTURE-L Date: Mon, 26 Feb 90 16:47:09 EST Reply-To: BITNET Futures List Sender: BITNET Futures List From: Mark Bodenstein Subject: Re: fall of Bitnet To: UofToronto LAN redistribution References: Message of Sun, Message-ID: <90Feb26.195320est.57432@ugw.utcs.utoronto.ca> Newsgroups: list.future-l Distribution: ut Approved: devnull@gpu.utcs.toronto.edu 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