RJE protocol for a resource sharing network
RFC 725

Document Type RFC - Unknown (March 1977; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 725 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
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


                                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


                    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

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 for this

In order to support a "hot line printer" (i.e., a job is automatically
printed when it is completed), the user must store his user code and
password for the output host at the server host.  This, of course,
presents a rather severe security problem.  Although the ARPANET can not
be made totally secure without massive revision, there are some basic
precautions that can be taken to protect users from being victimized by
every first year Computer Science student with access to the net.

The RJE protocol proposed here tries to mitigate the implementation
problems and security problems.  The protocol is designed to provide
three levels of service.  A user or server has the perogative to
implement the protocol at whatever level their resources allow.  The
service can then be upgraded to cleaner or more sophisticated approaches
when and if the opportunity arises.

This protocol is described in terms of the ARPANET.  Several aspects of

                                                                [page 1]

NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
An RJE Protocol for a Resource Sharing Network

the design (such as the reply structure) were made to coincide with
existing ARPANET conventions.  This was done to facilitate understanding
and limit the discussion to the protocol itself.  Although the protocol
is described in ARPANET terms, it should be applicable to other network

This paper is not considered to be complete in every detail.  It was
written primarily to elicit comments from the network community and to
measure the desire of the community to adopt such a procedure.  We have
tried to describe enough of the protocol so that the reader can get an
idea of how things are to work without getting bogged down in the detail
that would be necessary for implementation.  Below is an outline of the
final protocol document as presently conceived.  Sections marked with an
Show full document text