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
For many users of the ARPANET, an RJE protocol is probably as
in terms of utility as a TELNET (VTP) protocol. In fact, the provided by a TELNET and an RJE protocol are probably of most
to most users of computernetworks. For these users, the net provides
fast, cheap RJE surrogate, just as TELNET provides a telephone
for the timesharing user. The collection (and layers) of protocols
provide these services must be organized to efficiently support a
variety of applications and user needs. They should not pose an software burden on the user
The "official" NETRJE protocol for the ARPANET has met an response from both the user and server community. I believe there
two basic reasons. First, a large commitment of resources is
to implement NETRJE. Second, the protocol creates serious problems
In order to support the ARPA RJE protocol, a user must implement
Telnet, Server FTP, and User RJE, while a server must implement
Telnet, User FTP, and Server RJE. In addition when an RJE session
going on all three of these protocol implementations will be
for most of the life of the session. This could entail
burden for some systems. Although it may not be out of line to
a service to shoulder such burdens, it is out of line to require a
to assume them in order to gain a rather basic service. Most
installations are oriented toward meeting their user's needs not
implementing large amounts of network software. (In fact one of
better aspects of the previous ARPANET protocol designs was that
attempted to minimize the work for the user. (It must be
though that compassion for the user was not the reason for approach.)
In order to support a "hot line printer" (i.e., a job is
printed when it is completed), the user must store his user code password for the output host at the server host. This, of course presents a rather severe security problem. Although the ARPANET can
be made totally secure without massive revision, there are some
precautions that can be taken to protect users from being victimized
every first year Computer Science student with access to the net
The RJE protocolproposed here tries to mitigate the problems and securityproblems. The protocol is designed to
three levels of service. A user or server has the perogative implement the protocol at whatever level their resources allow.
service can then be upgraded to cleaner or more sophisticated
when and if the opportunity arises
This paper is not considered to be complete in every detail. It
written primarily to elicit comments from the network community and
measure the desire of the community to adopt such a procedure. We
tried to describe enough of the protocol so that the reader can get
idea of how things are to work without getting bogged down in the
that would be necessary for implementation. Below is an outline of
final protocoldocument as presently conceived. Sections marked with
asterisk are to be provided later
[page 2]
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316
An RJE Protocol for a Resource Sharing
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316
An RJE Protocol for a Resource Sharing
Part I THE NETRJE
------------------------
This section describes the proposed NETRJE protocol in a narrative form
A formal definition will be included in Part II after review.
narrative should provide the general reader with the flavor of protocol without getting bogged down in unnecessary detail. proposed NETRJE protocolprovides three different models for submission and retrieval. The three models can be characterized as 1)
RJE using Telnet only, 2) RJE using Telnet and Data Transfer, and 3)
using FTP. This approachprovides flexibility for both implementors
users. User and server sites constrained by manpower or
resources may implement only the simpler models. The user may use different models separately or in any consistent combination which
suits his requirements and convenience. Servers should assume that
minimal implementation of a more sophisticated model includes
minimal implementations of all less sophisticated models. (There are
however, certain minimal requirements that must be supported.)
secton will discuss each of these models in turn, and show each one
be used to provide a useful network RJE functon
This protocol does not contain the security difficulties of the protocol. This has been avoided by requiring that the burden
implementing the "hot line printer" or "hot card reader" be put on
user system. Thus, those systems which desire such a facility may
support it. The user implementaton will be slightly more complicated
The trade-off is the increased security of the protocol
End-to-end protocols are assumed to be available and to provide
ordered, error free bit stream to the RJE protocol. It is also
that a suitable virtual terminalprotocol such as Telnet, is used
format the control connection
RJE Using Only Telnet (VTP
---------------------------
The intent of this model is, bluntly, to provide an official "quick
dirty" form of the protocol. Many organizatons, both users and servers
are often confronted with problem of providing a service quickly
within very tight budgetary constraints. This model is intended
these situations. With this model, the user is required only to be
to establish a Telnet connection via the RJE contact socket. Commands
replies, and data are all sent over the Telnet connecton. Card input
printer output has the appearance of coming from or going to the user' terminal. The user's system may allow output to be diverted from terminal to another device such as the line printer. The technique
diverting terminal output was used with great success in the MARK I
[page 4]
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316
An RJE Protocol for a Resource Sharing
systems where various devices were not assigned socket numbers as in
TIP. This technique is also useful for hosts that allow program
to the network only through the user's Telnet connection. situation may exist in the early phases of a server's availability
the network. When data is transferred in this mode an end-of-
marker will be sent to aid the receiving host in determining when
stop diverting the data. This model will have to handle the problems
data traveling on a connection essentially meant for control. The
of this data transfermechanism is intended as an intermediate required by limited resources. For now we let it stand that
designers are aware of the problems inherent in embedding commands
replies in the data stream. We will leave the exact resolution of
problem to the formal definition
This proposed NETRJE protocol uses a schedule verb, SCHED for submission. For this model, there are two forms of SCHED that relevant. First, there is the "SCHED pathname>" form.
command indicates to the server that there exists at the server site
file with all necessary job control information and data to define
job. The server will then attempt to place the job in the job queue
reply to the user indicating success or failure and possibly a job-id
This job-id will be used when inquiring about the job status
retrieving the job's output
When the job finishes, the server will take one of two actions
a) if the user is still logged in, the server will send a
notifying the user of his job completion; or
b) if the user is not logged in, the server will save the status
the job which may later be interrogated via the STATUS command (
below).
The otherform of SCHED of relevance to this model has the syntax
SCHED INPUT .
This allows the user to sit down at a terminal and type his own
control or possibly a program. It also allows those users whose
systems provide a facility to transmit files with User TELNET transmit user input job fles in this way. The RJE Server would
the job into the local job stream, returning the proper indication
success or failure along with identification of the job
Just as the SCHED command provides several ways for job submission,
OUTPUT command provides several options for retrieving output. The
[page 5]
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316
An RJE Protocol for a Resource Sharing
The OUTDEF command for a job may be sent at any time after the job
been scheduled and before it is retrieved using the OUTPUT command
This command will specify the parametersnecessary to effect transfer of the output to the user or to define the disposition of
output. We realize that the OUTDEF pathname>
(indicating that output is to be placed in a file described by pathname) may be difficult for some systems to implement. These
would merely respond negatively indicating their inability to
the function
A scenario is now in order to illustrate the model. The user has
in to Multics and is ready to submit an RJE job in the following
(XXX will denote the as yet unspecified reply code for the reply):
The user then sends an empty line when he is read to receive the output
[page 6]
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316
An RJE Protocol for a Resource Sharing
This exchange allows the user to effect output diversion at his
site if necessary after he has confirmed the server is ready
If the user had not wished to wait on his output and had logged
after getting the successfulsubmission, the next time the user
in he could inquire as to the status of the job or all jobs under
usercode and then proceeded to output any or all of them
RJE with TELNET and Data
---------------------------------
The previous model provided a minimal implementation for NETRJE.
model provides better data transfer facilities without requiring an implementation. This model requires no new commands, but
manipulate connections differently, so that data is not required to
on the command connection (see Fig. 2). Data is sent on
default connections (unless otherwise specified) as in the CCN protocol. However, for this protocol the defaults used will be the
offsets from the control connection as those in FTP
The use of this model is indicated to the Server by either the
command or a SCHED command with no arguments. The INDEF command
the user to specify a socket other than the default socket as the
of the input. On receipt of the SCHED or INDEF indicating technique is to be used, the Server will attempt to connect to appropriate socket. If a SCHED command was sent, the user
interpreter could start sending cards as soon as the data connection
established. (It is assumed that the user interface has indicated
the RJE protocol interpreter where the cards are to come from.) If
command was INDEF, then the Server will not start reading until
SCHED is received. Similarly, when the output is ready, either
OUTDEF or OUTPUT command is sent to set up and start the printing.
INDEF and OUTDEF commands used with this mode will also allow
data to or from a TIP or printer
This model requires definiton of actual data transfer formats for
reader and printer lines. We propose that the formats and
schemes of the present FTP be adopted. This solution has the
of not requiring extra coding efforts for users with FTP
and may allow them to organize their FTP implementations and may
them to organize their FTP and NETRJE implementations in such a way
to take advantage of common algorithms. One might easily confuse solution with a revival of the Data TransferProtocol. Some thought
a more rigorous definition of a Data TransferProtocol for the
use of FTP and RJE might be worthwhile in the future
[page 7]
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316
An RJE Protocol for a Resource Sharing
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316
An RJE Protocol for a Resource Sharing
NETRJE Using
----------------
This model (illustrated in Fig. 3) uses FTP to effect the transfer
the files. It may be easier for some systems to use this sort of
for more sophisticated RJE systems. This is especially true if
users desire to take input from the local file system or to send
to the local file system rather than from an actual card reader or to
actual line printer. Although using the local file system is
prohibited by the Data Transfer model, it may be easier to
through FTP. Using FTP with NETRJE also allows the utilization of
FTP server-server transfermechanism to generate input from or
output to a third host
The only new facilityrequired by this model are the commands INPATH
OUTPATH. When using FTP to transfer input to the Server, the user
know where to send the job so that it enters the job stream. The
command returns as a reply such a legal pathname. Thus the scenario
job submission is as follows: The user sends an INPATH command;
Server responds with a legal Server pathname for the user. The
process starts sending the input to the file using FTP. When
is complete, the user sends a SCHED pathname> command. When
job has finished, the pathname created for the user may or may
destroy the input file. The OUTPATH command is similarily used
identify the pathname for the output, so that it may be retrieved
FTP. Some systems may define file names in such a way that the user
derive them from the parameters of his job
Note on
In all of the above examples we have refrained from defining
reply codes. The intent is to use the same reply structure, and appropriate the same numbers, as described in RFC 640 "Revised FTP
Codes".
An integral part of any good protocoldefinition is a set
measurements to allow evaluation of both the protocol and implementation. This provides two functions: 1) It allows the
designer to evaluate the protocol and make improvements. 2) It
the user of the protocol to know how expensive it is and to
improvements. The proposed NETRJE protocolprovides two sets
measures - one for a particular session and one for overall performance
These measurements may be elicited by the MEASURE command which
take an argument with three values: JOB (job statistics and
measurements), SESSION (measurements taken for this sesson), and
[page 9]
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316
An RJE Protocol for a Resource Sharing
(overall measurements of the performance of the protocol and implementation). The command will return the measurements in a
format reply
6. cpu time, storage space-time product, and I/O operations for
the protocol and jobs submitted: average, std. deviation, and
and lower bounds (overall as well as by model, transfer mode,
file size). (The reason for including job statistics here is so
[page 10]
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316
An RJE Protocol for a Resource Sharing
It is clear that it may be difficult to acquire some measures (such transmission rate) when NETRJE is using FTP. This is unavoidable
FTP is not metered. The most straightforward solution is also to
FTP (hint). For the final definition a close look will be given to
subset that should be required. Comments are welcome. However,
believe strongly that it is very important to know how a facility
this is used as well as how well it performs
[page 11]
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316
An RJE Protocol for a Resource Sharing
Part II. Preliminary Definition of NETRJE
---------------------------------------------------
For purposes of discussion this section gives a very definition of the NETRJE commands and their replies. The intent is
give a brief but not exhaustive definition of each command and its
replies to give the flavor of the protocol. We do not do this
discourage nit-picking by critics, since we may actually overlook
obvious on occasion, but merely to expedite the writing of this paper
The reply scheme will follow the model of the revised FTP reply described in RFC 640.
ACCT
These perform the normal functions to log the user into the system.
replies to them are the standard ones in FTP. It was never clear
"account" was not included in the old NETRJE. Presumably, if it' necessary for an FTP or Telnet user, it will be necessary for an
user
This command reinitializes the state of the NETRJE server process
that it is ready for a new user. If the transfer of data is in
for the previous user, it will be allowed to complete
This command is used to abort the transfer of data. This command
meaningful to the Server only if the data is being transferred over
Telnet connection or the default data sockets. If FTP is being used
the execution of this command is the responsibility of the USER
process
This command causes the Server to log out the user and close the connection. If the transfer of data is in progress, the action of
command will be delayed until the transfer is complete
[page 12]
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316
An RJE Protocol for a Resource Sharing
