Browse Prior Art Database

RJE protocol for a resource sharing network (RFC0725)

IP.com Disclosure Number: IPCOM000003771D
Original Publication Date: 1977-Mar-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 22 page(s) / 42K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

J.D. Day: AUTHOR [+2]

Abstract

Part I

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 7% of the total text.

NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316

An RJE Protocol for a Resource Sharing Network

CAC Technical Memorandum No. 86

CCTC-WAD No. 7508

ARPANET RFC No. 725

NIC No. 38316

An RJE Protocol for a Resource Sharing Network

by

John Day

Gary R. Grossman

Prepared for the

Command and Control Technical Center

WWMCCS ADP Directorate

of the

Defense Communications Agency

Washington, D.C. 20305

under contract

DCAl00-76-C-0088

Center for Advanced Computation

University of Illinois at Urbana-Champaign

Urbana, Illinois 61801

March 1, 1977

Approved for Release - Peter A. Alsberg, Principal Investigator

NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316

An RJE Protocol for a Resource Sharing Network

For many users of the ARPANET, an RJE protocol is probably as important

in terms of utility as a TELNET (VTP) protocol. In fact, the facilities

provided by a TELNET and an RJE protocol are probably of most interest

to most users of computer networks. For these users, the net provides a

fast, cheap RJE surrogate, just as TELNET provides a telephone surrogate

for the timesharing user. The collection (and layers) of protocols that

provide these services must be organized to efficiently support a wide

variety of applications and user needs. They should not pose an undue

software burden on the user.

The "official" NETRJE protocol for the ARPANET has met an underwhelming

response from both the user and server community. I believe there are

two basic reasons. First, a large commitment of resources is necessary

to implement NETRJE. Second, the protocol creates serious security

problems.

In order to support the ARPA RJE protocol, a user must implement User

Telnet, Server FTP, and User RJE, while a server must implement Server

Telnet, User FTP, and Server RJE. In addition when an RJE session is

going on all three of these protocol implementations will be executing

for most of the life of the session. This could entail considerable

burden for some systems. Although it may not be out of line to require

a service to shoulder such burdens, it is out of line to require a user

to assume them in order to gain a rather basic service. Most user

installations are oriented toward meeting their user's needs not toward

implementing large amounts of network software. (In fact one of the

better aspects of the previous ARPANET protocol designs was that they

attempted to minimize the work for the user. (It must be admitted

though that compassion for the user was not the reason fo...