doc: Add RFC documents

1 files changed, 1580 insertions, 0 deletions

diff --git a/doc/rfc/rfc725.txt b/doc/rfc/rfc725.txt
new file mode 100644
index 0000000..74fb9f5
--- /dev/null
+++ b/doc/rfc/rfc725.txt
@@ -0,0 +1,1580 @@
+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 for this
+approach.)
+
+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
+environments.
+
+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
+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 Network
+
+
+
+Introduction
+
+Part I
+
+   The NETRJE Models
+
+      1.  Telnet (VTP) Model
+
+      2.  Telnet with Data Transfer Model
+
+      3.  Telnet with FTP Model
+
+   Scenarios for the Models
+
+*    Suggested Implementaton Schemes for Various Applications
+
+Part II
+
+   The Server RJE Commands
+
+*        General Conventions
+
+   Commands
+
+   Replies
+
+      Numerical List
+
+      Command-Reply List
+
+*         Details of the Data Transfer
+
+*         Minimal Requirements for a User RJE
+
+*         Minimal Requirements for a Server RJE
+
+*         Glossary of Terms
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [page 3]
+
+NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
+An RJE Protocol for a Resource Sharing Network
+
+
+
+Part I THE NETRJE MODELS
+------------------------
+
+This section describes the proposed NETRJE protocol in a narrative form.
+A formal definition will be included in Part II after review.  The
+narrative should provide the general reader with the flavor of the
+protocol without getting bogged down in unnecessary detail.  The
+proposed NETRJE protocol provides three different models for job
+submission and retrieval.  The three models can be characterized as 1)
+RJE using Telnet only, 2) RJE using Telnet and Data Transfer, and 3) RJE
+using FTP.  This approach provides flexibility for both implementors and
+users.  User and server sites constrained by manpower or machine
+resources may implement only the simpler models.  The user may use the
+different models separately or in any consistent combination which best
+suits his requirements and convenience.  Servers should assume that the
+minimal implementation of a more sophisticated model includes the
+minimal implementations of all less sophisticated models.  (There are,
+however, certain minimal requirements that must be supported.)  This
+secton will discuss each of these models in turn, and show each one can
+be used to provide a useful network RJE functon.
+
+This protocol does not contain the security difficulties of the present
+protocol.  This has been avoided by requiring that the burden of
+implementing the "hot line printer" or "hot card reader" be put on the
+user system.  Thus, those systems which desire such a facility may still
+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 an
+ordered, error free bit stream to the RJE protocol.  It is also assumed
+that a suitable virtual terminal protocol such as Telnet, is used to
+format the control connection.
+
+RJE Using Only Telnet (VTP)
+---------------------------
+
+The intent of this model is, bluntly, to provide an official "quick and
+dirty" form of the protocol.  Many organizatons, both users and servers,
+are often confronted with problem of providing a service quickly or
+within very tight budgetary constraints.  This model is intended for
+these situations.  With this model, the user is required only to be able
+to establish a Telnet connection via the RJE contact socket.  Commands,
+replies, and data are all sent over the Telnet connecton.  Card input or
+printer output has the appearance of coming from or going to the user's
+terminal.  The user's system may allow output to be diverted from the
+terminal to another device such as the line printer.  The technique of
+diverting terminal output was used with great success in the MARK I ANTS
+
+
+
+
+
+                                                                [page 4]
+
+NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
+An RJE Protocol for a Resource Sharing Network
+
+
+
+systems where various devices were not assigned socket numbers as in a
+TIP.  This technique is also useful for hosts that allow program access
+to the network only through the user's Telnet connection.  This
+situation may exist in the early phases of a server's availability to
+the network.  When data is transferred in this mode an end-of-data
+marker will be sent to aid the receiving host in determining when to
+stop diverting the data.  This model will have to handle the problems of
+data traveling on a connection essentially meant for control.  The use
+of this data transfer mechanism is intended as an intermediate measure
+required by limited resources.  For now we let it stand that the
+designers are aware of the problems inherent in embedding commands or
+replies in the data stream.  We will leave the exact resolution of the
+problem to the formal definition.
+
+This proposed NETRJE protocol uses a schedule verb, SCHED for job
+submission. For this model, there are two forms of SCHED that are
+relevant.  First, there is the "SCHED <server pathname>" form.  This
+command indicates to the server that there exists at the server site a
+file with all necessary job control information and data to define a
+job.  The server will then attempt to place the job in the job queue and
+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 or
+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 reply
+   notifying the user of his job completion; or,
+
+   b)  if the user is not logged in, the server will save the status of
+   the job which may later be interrogated via the STATUS command (see
+   below).
+
+The otherform of SCHED of relevance to this model has the syntax:
+
+   SCHED INPUT <CRLF><data><CRLF>.<CFLF>
+
+This allows the user to sit down at a terminal and type his own job
+control or possibly a program.  It also allows those users whose local
+systems provide a facility to transmit files with User TELNET to
+transmit user input job fles in this way.  The RJE Server would insert
+the job into the local job stream, returning the proper indication of
+success or failure along with identification of the job.
+
+Just as the SCHED command provides several ways for job submission, the
+OUTPUT command provides several options for retrieving output.  The form
+
+
+
+
+
+
+                                                                [page 5]
+
+NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
+An RJE Protocol for a Resource Sharing Network
+
+
+
+   OUTPUT<job-id><server pathname>DISCARD
+
+is sent to the server to initiate the output to the user's site
+according to output specifications defined by previous OUTDEF commands
+(see below).  The optional DISCARD argument to the OUTPUT command
+indicates, if present, that the file is to be destroyed after
+transmission has completed successfully.
+
+The OUTDEF command for a job may be sent at any time after the job has
+been scheduled and before it is retrieved using the OUTPUT command.
+This command will specify the parameters necessary to effect the
+transfer of the output to the user or to define the disposition of the
+output.  We realize that the OUTDEF <job-id><server pathname> command
+(indicating that output is to be placed in a file described by the
+pathname) may be difficult for some systems to implement.  These systems
+would merely respond negatively indicating their inability to perform
+the function.
+
+A scenario is now in order to illustrate the model.  The user has logged
+in to Multics and is ready to submit an RJE job in the following way
+(XXX will denote the as yet unspecified reply code for the reply):
+
+   SCHED MY-JOB>TREK
+
+The system responds with a reply indicating the job has been submitted
+successfully and returns a job-id, say XA1423.
+
+   XXX JOB XA1423 was successfully submitted.
+
+At some later time a message appears.
+
+   XXX JOB XA1423 has completed.
+
+The user or user process now sends OUTDEF XA1423 TELNET indicating that
+the job should be sent on the TELNET connection.  A reply returns
+
+   XXX last command successful.
+
+The user now sends
+
+   OUTPUT XA1423
+
+and the server replies with
+
+   XXX Output ready.  Type an empty line when ready.
+
+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 Network
+
+
+
+This exchange allows the user to effect output diversion at his local
+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 off
+after getting the successful submission, the next time the user logged
+in he could inquire as to the status of the job or all jobs under his
+usercode and then proceeded to output any or all of them.
+
+RJE with TELNET and Data Transfer
+---------------------------------
+
+The previous model provided a minimal implementation for NETRJE.  This
+model provides better data transfer facilities without requiring an FTP
+implementation.  This model requires no new commands, but does
+manipulate connections differently, so that data is not required to flow
+on the command connection (see Fig. 2).  Data is sent on separate
+default connections (unless otherwise specified) as in the CCN NETRJS
+protocol.  However, for this protocol the defaults used will be the same
+offsets from the control connection as those in FTP.
+
+The use of this model is indicated to the Server by either the INDEF
+command or a SCHED command with no arguments.  The INDEF command allows
+the user to specify a socket other than the default socket as the source
+of the input.  On receipt of the SCHED or INDEF indicating this
+technique is to be used, the Server will attempt to connect to the
+appropriate socket.  If a SCHED command was sent, the user protocol
+interpreter could start sending cards as soon as the data connection is
+established.  (It is assumed that the user interface has indicated to
+the RJE protocol interpreter where the cards are to come from.)  If the
+command was INDEF, then the Server will not start reading until the
+SCHED is received.  Similarly, when the output is ready, either an
+OUTDEF or OUTPUT command is sent to set up and start the printing.  The
+INDEF and OUTDEF commands used with this mode will also allow moving
+data to or from a TIP or printer.
+
+This model requires definiton of actual data transfer formats for the
+reader and printer lines.  We propose that the formats and connection
+schemes of the present FTP be adopted.  This solution has the advantage
+of not requiring extra coding efforts for users with FTP implementations
+and may allow them to organize their FTP implementations and may allow
+them to organize their FTP and NETRJE implementations in such a way as
+to take advantage of common algorithms.  One might easily confuse this
+solution with a revival of the Data Transfer Protocol.  Some thought on
+a more rigorous definition of a Data Transfer Protocol for the common
+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 Network
+
+
+
+Let us consider a scenario.
+
+The user wishes to submit a card deck to the Server.  He then types
+
+   SCHED<CRLF>
+
+The Server opens a connection to the user's default card reader socket
+while sending a reply to the user on the control connection.
+
+   XXX attempting connection to card reader.
+
+When the connection is opened, another reply:
+
+   XXX transfer started
+
+and when completed:
+
+   XXX JOB XA 1423 was successfully submitted.
+
+When the job completes and the completion message is sent to the user,
+he may wish to send the output to his TIP printer on socket Y.  He will
+then type
+
+   OUTDEF XA1423 255, Y (255 being his host address).
+
+The Server will then attempt to connect to the socket and will reply
+
+   XXX printer connection successful.
+
+When the user has satisfied himself all is in readiness, he will type
+
+   OUTPUT XA1423
+
+and the Server will start sending and reply to the user
+
+   XXX print started.
+
+When the transfer is complete the Server will close the data connection
+and send an appropriate reply.
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [page 8]
+
+NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
+An RJE Protocol for a Resource Sharing Network
+
+
+
+NETRJE Using FTP
+----------------
+
+This model (illustrated in Fig. 3) uses FTP to effect the transfer of
+the files.  It may be easier for some systems to use this sort of model
+for more sophisticated RJE systems.  This is especially true if the
+users desire to take input from the local file system or to send output
+to the local file system rather than from an actual card reader or to an
+actual line printer.  Although using the local file system is not
+prohibited by the Data Transfer model, it may be easier to approach
+through FTP.  Using FTP with NETRJE also allows the utilization of the
+FTP server-server transfer mechanism to generate input from or direct
+output to a third host.
+
+The only new facility required by this model are the commands INPATH and
+OUTPATH.  When using FTP to transfer input to the Server, the user must
+know where to send the job so that it enters the job stream.  The INPATH
+command returns as a reply such a legal pathname.  Thus the scenario for
+job submission is as follows:  The user sends an INPATH command; the
+Server responds with a legal Server pathname for the user.  The user
+process starts sending the input to the file using FTP.  When transfer
+is complete, the user sends a SCHED <server pathname> command.  When the
+job has finished, the pathname created for the user may or may not
+destroy the input file.  The OUTPATH command is similarily used to
+identify the pathname for the output, so that it may be retrieved by
+FTP.  Some systems may define file names in such a way that the user may
+derive them from the parameters of his job.
+
+Note on Replies
+
+In all of the above examples we have refrained from defining actual
+reply codes.  The intent is to use the same reply structure, and where
+appropriate the same numbers, as described in RFC 640 "Revised FTP Reply
+Codes".
+
+Protocol Measurement
+
+An integral part of any good protocol definition is a set of
+measurements to allow evaluation of both the protocol and its
+implementation.  This provides two functions:  1) It allows the protocol
+designer to evaluate the protocol and make improvements.  2) It allows
+the user of the protocol to know how expensive it is and to demand
+improvements.  The proposed NETRJE protocol provides two sets of
+measures - one for a particular session and one for overall performance.
+These measurements may be elicited by the MEASURE command which will
+take an argument with three values:  JOB (job statistics and cost
+measurements), SESSION (measurements taken for this sesson), and GLOBAL
+
+
+
+
+
+                                                                [page 9]
+
+NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
+An RJE Protocol for a Resource Sharing Network
+
+
+
+(overall measurements of the performance of the protocol and its
+implementation).  The command will return the measurements in a fixed
+format reply.
+
+The measurements reported for a job are:
+
+   1.  CPU time,
+
+   2.  I/O operations,
+
+   3.  storage space time product,
+
+   4.  job cost in dollars,
+
+   5.  elapsed time the job waited before being executed, and
+
+   6.  elapsed time for the job to execute.
+
+The measures taken from a sesson are:
+
+   1.  number of bits transferred,
+
+   2.  transmission rate of input or output transfers,
+
+   3.  the amount of CPU time, storage space-time product, and I/O
+   operations for the session.
+
+   4.  cost in dollars and cents.
+
+The measures to be taken globally are:
+
+   1.  frequency of commands and possibly command forms,
+
+   2.  model frequency (which submission/retrieval model used),
+
+   3.  transmission mode frequency,
+
+   4.  total number of sessions,
+
+   5.  transmission rate:  average, std. deviation, upper and lower
+   bounds (also by transmission mode),
+
+   6.  cpu time, storage space-time product, and I/O operations for both
+   the protocol and jobs submitted:  average, std. deviation, and upper
+   and lower bounds (overall as well as by model, transfer mode, and
+   file size).  (The reason for including job statistics here is so that
+
+
+
+
+
+
+                                                               [page 10]
+
+NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
+An RJE Protocol for a Resource Sharing Network
+
+
+
+   management and systems personnel have some indication how the
+   facility is being used.)
+
+It is clear that it may be difficult to acquire some measures (such as
+transmission rate) when NETRJE is using FTP.  This is unavoidable since
+FTP is not metered.  The most straightforward solution is also to meter
+FTP (hint).  For the final definition a close look will be given to the
+subset that should be required.  Comments are welcome.  However, we
+believe strongly that it is very important to know how a facility like
+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 Network
+
+
+
+Part II.  Preliminary Definition of NETRJE Commands
+---------------------------------------------------
+
+For purposes of discussion this section gives a very preliminary
+definition of the NETRJE commands and their replies.  The intent is to
+give a brief but not exhaustive definition of each command and its major
+replies to give the flavor of the protocol.  We do not do this to
+discourage nit-picking by critics, since we may actually overlook the
+obvious on occasion, but merely to expedite the writing of this paper.
+
+The reply scheme will follow the model of the revised FTP reply codes
+described in RFC 640.
+
+Access Control
+
+   USER <usercode>
+
+   PASS <password>
+
+   ACCT <account>
+
+These perform the normal functions to log the user into the system.  The
+replies to them are the standard ones in FTP.  It was never clear why
+"account" was not included in the old NETRJE.  Presumably, if it's
+necessary for an FTP or Telnet user, it will be necessary for an RJE
+user.
+
+REINIT
+
+This command reinitializes the state of the NETRJE server process so
+that it is ready for a new user.  If the transfer of data is in progress
+for the previous user, it will be allowed to complete.
+
+ABORT
+
+This command is used to abort the transfer of data.  This command is
+meaningful to the Server only if the data is being transferred over the
+Telnet connection or the default data sockets.  If FTP is being used,
+the execution of this command is the responsibility of the USER NETRJE
+process.
+
+BYE
+
+This command causes the Server to log out the user and close the Telnet
+connection.  If the transfer of data is in progress, the action of the
+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 Network
+
+
+
+SCHED <input part><output part>
+
+<input part>::= <empty>|<server pathname> [DISCARD]
+
+   INPUT <CRLF>   <text>   <CRLF>.<CRLF>
+
+output part ::= <empty>|<server pathname>[DISCARD]
+
+server pathname ::= {locally recognizable string of characters
+terminated by an ASCII NULL}
+
+This command causes the input described by the <input part> to be
+entered into the RJE job stream and the output produced to be disposed
+of according to the <output part>.  The null condition for either
+argument implies that the information has been previously specified or
+is the default.
+
+For the <input part>, the <empty> may imply two actions.  If an INDEF
+command has previously specified a <server pathname>, input to the job
+stream is taken from the file indicated by the file name.  If the INDEF
+command has specified that the input is to come from a CCN-like data
+transfer socket, the SCHED <empty> command is the signal for the Server
+to start reading data.
+
+The DISCARD modifier, if present, indicates that the file should be
+discarded after it has been transmitted or it has been received and
+executed.  If the input stream is to be sent on the Telnet connection,
+the source may be a local device or a human user.  This facility is
+provided for mini-hosts that can't use one of the other techniques and
+for the user who wishes to enter job control directly at his terminal.
+
+The empty for output specifies either the primary output file of the job
+(the default) or a previously specified server pathname (OUTDEF
+command).
+
+Successful replies to this command should indicate any job-id assigned
+by the local RJE system along with other status informaton.  Failure
+would be because files did not exist, access was denied, etc.
+
+OUTPUT <output spec>
+
+<output spec>::= <job-id><xmsn part>|<job-id><server pathname>
+
+<xmsn part>::= <empty>| /<IO params>
+
+<IO params>::= <xmsn params>, <dest>
+
+
+
+
+
+
+                                                               [page 13]
+
+NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
+An RJE Protocol for a Resource Sharing Network
+
+
+
+This command indicates to the Server what output  is to be sent to the
+user, how it is to be sent, and to whom.  The <IO params> part will
+allow the specification of a host and socket so that output may be sent
+to a TIP printer, or alternatively sent on the Telnet connection or to
+the default data sockets.  This argument also specifies the format and
+representation of the data.
+
+When the Server receives this command, it will proceed to transmit the
+output to the host in the prescribed manner.  The reply structure of
+this command will depend on how the output is moved and will be
+discussed in more detail later.
+
+INPATH
+
+This command returns to the user a legal pathname at the Server.  The
+user may then transfer his input to this pathname for eventual
+submission to the RJE facility.
+
+OUTPATH
+
+This command performs a similar function to INPATH.
+
+DISCARD   <job-file-id>  |  <server pathname>
+
+This allows the user to destroy input or output files associated with a
+job.
+
+INDEF     <job-id><I/O params>
+
+OUTDEF    <job-id><I/O params>
+
+These commands allow the user to specify the parameters necessary to
+send input or retrieve output.  This command specifies how the data will
+be transferred and specifies format, etc.
+
+CANCEL <job-id>
+
+This command allows a job to be cancelled from the RJE job stream.
+
+STATUS <status arg>
+
+status arg ::= <empty>|<user id>|<job-id>|<job-id><blank><job-file-id>
+
+This command allows the user to determine the status of the RJE session,
+all jobs under his usercode, a specific job, or the output of a specific
+job.
+
+
+
+
+
+
+                                                               [page 14]
+
+NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
+An RJE Protocol for a Resource Sharing Network
+
+
+
+ALTER <job-id><site specific option>
+
+SITE <site specific option>
+
+These commands allow site specific commands to be passed to the Server
+RJE system.  The ALTER command is intended to effect specific jobs,
+while the SITE command is used for commands of more global effect.  They
+could be merged into one.
+
+OP <operator message>
+
+This command allows messages to be sent to the operator at the Server
+site.
+
+Reply Codes for the Proposed NETRJE
+-----------------------------------
+
+The reply codes for this protocol will follow the model proposed for the
+new FTP specificaton in RFC 640.  As a reminder we insert the pertinent
+information from that RFC:
+
+There are five values for the first digit of the reply code:
+
+1yz     Positive Preliminary reply
+
+   The requested action is being initiated; expect another reply before
+   proceeding with a new command.  (The user-process sending another
+   command before the completion reply would be in violation of
+   protocol; but server-FTP processes should queue any commands that
+   arrive while a preceding command is in progress.)  For
+   implementations where simultaneous monitoring is difficult, this type
+   of reply can be used to indicate that the command was accepted and
+   the user-process may now pay attention to the data connections.
+
+2yz     Positive Completion reply
+
+   The requested action has been successfully completed.  A new request
+   may be initiated.
+
+3yz     Positive Intermediate reply
+
+   The command has been accepted, but the requested action is being held
+   in abeyance, pending receipt of further information.  The user should
+   send another command specifying this information.  This reply is used
+   in command sequence groups.
+
+
+
+
+
+
+
+                                                               [page 15]
+
+NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
+An RJE Protocol for a Resource Sharing Network
+
+
+
+4yz     Transient Negative Completion reply
+
+   The command was not accepted and the requested action did not take
+   place, but the error condition is temporary and the action may be
+   requested again.  The user should return to the beginning of the
+   command sequence, if any.  It is difficult to assign a meaning to
+   "transient", particularly when two distinct sites (Server and
+   User-processes) have to agree on the interpretation.  Each reply in
+   the 4yz category might have a slightly different time value, but the
+   intent is that the user-process is encouraged to try again.  A rule
+   of thumb in determining if a reply fits into the 4yz or the 5yz
+   (Permanent Negative) category is that replies are 4yz if the commands
+   can be repeated without any change in command form or in properties
+   of the User or Server (e.g., the command is spelled the same with the
+   same arguments used, the user does not change his file access or user
+   name, the server does not put up a new implementation.)
+
+5yz     Permanent Negative Completion reply
+
+   The command was not accepted and the requested action did not take
+   place.  The User-process is discouraged from repeating the exact
+   request (in the same sequence).  Even some "permanent" error
+   conditions can be corrected, so the human user may want to direct his
+   User-process to reinitiate the command sequence by direct action at
+   some point in the future (e.g., after the spelling has been changed,
+   or the user has altered his directory status.)
+
+The following function groupings are encoded in the second digit:
+
+x0z     Syntax - These replies refer to syntax errors, syntactically
+correct commands that don't fit any functional category, and
+unimplemented or superfluous commands.
+
+x1z     Information - These are replies to requests for information,
+such as status or help.
+
+x2z     Connection - Replies referring to the Telnet and data
+connections.
+
+x3z     Authentication and accounting - Replies for the logon process
+and accountng procedures.
+
+x4z     Unspecified as yet.
+
+x5z     File system - These replies indicate the status of the Server
+file system vis-a-vis the requested transfer or other file system
+action.
+
+
+
+
+
+                                                               [page 16]
+
+NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
+An RJE Protocol for a Resource Sharing Network
+
+
+
+The third digit gives a finer gradation of meaning in each of the
+function categories specified by the second digit.  The list of replies
+below will illustrate this.  Note that the text associated with each
+reply is suggestive, rather than mandatory, and may even change
+according to the command with which it is associated.  The reply codes,
+on the other hand, should strictly follow the specifications.  That is,
+Server implementations should not invent new codes for situations that
+are only slightly different from the ones described here, but rather
+should adapt codes already defined.
+
+Below is a list of replies ordered by reply code.  Some new replies have
+been added for RJE; these are marked by asterisks to aid the reader.
+Following this list is a list of commands with the replies that are
+possible for that command.  This list is not considered complete or
+final; as usual comments are welcomed.
+
+110 Restart marker reply,
+
+   In this case the text is exact and not left to the particular
+   implementation; it must read:
+
+      MARK yyyy = mmmm
+
+   where yyyy is user-process data stream marker, and mmmm is Server's
+   equivalent marker.  (Note the spaces between the markers and "=".)
+
+120 Service ready in nnn minutes
+
+125 Data connection already open; transfer starting
+
+150 File status okay; about to open data connection
+
+200 Command okay
+
+202 Command not implemented, superfluous at this site
+
+211 System status, or system help reply
+
+212 Directory status
+
+213 File status
+
+214 Help message (on how to use the server or the meaning of a
+particular non-standard command.  This reply is useful only to the human
+user.)
+
+*215 RJE general status reply
+
+
+
+
+
+                                                               [page 17]
+
+NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
+An RJE Protocol for a Resource Sharing Network
+
+
+
+*216 job status reply
+
+*217 RJE user's jobs status reply
+
+220 Service ready for new user
+
+221 Service closing TELNET connecton (logged off if appropriate)
+
+225 Data connection open; no transfer in progress
+
+226 Closing data connection; requested file action successful (for
+example, file transfer or file abort.)
+
+227 Entering [passive, active] mode
+
+230 User logged in
+
+250 Requested file action okay, completed
+
+*260 Job <job-id> has completed
+
+*261 Output ready.  Type an empty line when ready
+
+*262 Job <job-id> IS ALLOCATED  pathname
+
+*263 Job <job-id> cancelled as requested
+
+*264 Job <job-id> altered as requested to state status
+
+331 User name okay, need password
+
+332 Need account for login
+
+350 Requested file action held in abeyance, pending further information
+
+354 Start mail input; end with CRLF, CRLF
+
+*360 Job <job-id> successfully submitted
+
+421 Service not available, closing Telnet connecton.  (This may be a
+reply to any command if the service knows it must shut down.)
+
+425 Can't open data connection
+
+426 Connection trouble, closed; transfer aborted
+
+
+
+
+
+
+
+                                                               [page 18]
+
+NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
+An RJE Protocol for a Resource Sharing Network
+
+
+
+450 Requested file action not taken; file unavailable (e.g., file not
+found, no access)
+
+451 Requested action aborted; local error in processing
+
+452 Requested action not taken:  insufficient storage space in system
+
+500 Syntax error, command unrecognized  (This may include errors such as
+command line too long.)
+
+501 Syntax error in parameters or arguments
+
+502 Command not implemented
+
+503 Bad sequence of commands
+
+504 Command not implemented for that parameter
+
+530 Not logged in
+
+532 Need account for storing files
+
+550 Requested action not taken: file unavailable (e.g., file busy)
+
+552 Requested file action aborted:  exceeded storage allocation for
+current directory or dataset)
+
+553 Requested action not taken:  file name not allowed
+
+*563 Job <job-id> is not known to the system
+
+*564 Requested alteration is not permitted for the specified job.
+
+Reply codes for RJE
+
+   USER
+
+      230
+
+      530
+
+      500, 501, 421
+
+      331, 332
+
+   PASS
+
+
+
+
+
+
+                                                               [page 19]
+
+NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
+An RJE Protocol for a Resource Sharing Network
+
+
+
+      230
+
+      202
+
+      530
+
+      500, 501, 503, 421
+
+      332
+
+   ACCT
+
+      230
+
+      202
+
+      530
+
+      500, 501, 503, 421
+
+   BYE
+
+      221
+
+      500
+
+   REINIT
+
+      120
+
+      220
+
+      220
+
+      421
+
+      500, 502
+
+   ABORT
+
+      225, 226
+
+      500, 501, 502, 421
+
+   STATUS
+
+      211, 212, 213
+
+
+
+
+
+                                                               [page 20]
+
+NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
+An RJE Protocol for a Resource Sharing Network
+
+
+
+      450
+
+      500, 501, 502, 421, 530
+
+   HELP
+
+      211, 214
+
+      500, 501, 502, 421
+
+   SOCK
+
+      200
+
+      500, 501, 421, 530
+
+   BYTE, MODE, TYPE, STRU
+
+      200
+
+      500, 501, 504, 421, 530
+
+   SCHED
+
+      360     JOB <job-id> successfully submitted
+
+      260     Job <job-id> has completed.
+
+      125          500
+
+      425, 426     501
+
+      226          504, 532
+
+   OUTPUT
+
+      261     Output ready.  Type an empty line when ready.
+
+      125     Transfer started
+
+      226          500
+
+      425, 426      501
+
+      110
+
+   OUTDEF
+
+
+
+
+
+                                                               [page 21]
+
+NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
+An RJE Protocol for a Resource Sharing Network
+
+
+
+      225     Data connection opened, no transfer in progress.
+
+      425          500
+
+                   501
+
+                   504
+
+   INDEF
+
+      225          500
+
+      425          501
+
+                   504
+
+   INPATH/OUTPATH
+
+      262     JOB <job-id> IS ALLOCATED PATHNAME >
+
+                   500     504
+
+                    501
+
+   DISCARD
+
+                 250     500     530
+
+                 450     501
+
+                 550     502
+
+                         421
+
+   CANCEL
+
+      263     Job <job-id> Cancelled as requested
+
+                    500     504
+
+                    501
+
+                    502
+
+      563     Job <job-id> is not known to the system
+
+
+
+
+
+
+
+                                                               [page 22]
+
+NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
+An RJE Protocol for a Resource Sharing Network
+
+
+
+      564     Requested Alteration is not permitted for the specific
+      job.
+
+   STATUS
+
+      215     RJE general status reply
+
+      216     RJE job status reply
+
+      217     RJE user's jobs status reply
+
+      500, 501, 502, 504
+
+   ALTER
+
+   
+
+      264     Job <job-id> altered as requested to state status
+
+      500, 501, 502, 504     563, 564
+
+   SITE
+
+      200
+
+      500, 501, 502, 504
+
+   OP
+
+      200
+
+      500, 501, 502, 504
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                               [page 23]
+
+NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
+An RJE Protocol for a Resource Sharing Network
+
+
+
+References
+----------
+
+Braden, R.
+
+   1971 "Interim NETRJS Specifications", RFC 189, NIC 7133.
+
+Bressler, R.; Guida, R.; and McKenzie, A.
+
+   1972 "Remote Job Entry Protocol", RFC 407
+
+Neigus, N.
+
+   1973 "The File Transfer Protocol", RFC 542.
+
+Neigus, N.; Pogran, K.; and Postel, J.
+
+   1974 "A New Schema for FTP Reply Codes", RFC 640.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                               [page 24]
+
+NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
+An RJE Protocol for a Resource Sharing Network
+
+
+
+Figures
+-------
+
+   +-----------+
+   !           !
+   !  user     !
+   !  RJE      !
+   ! interface !
+   !           !
+   +-----------+     +--------+    Telnet Connection     +--------+
+         !           !        !                          !        !
+         !           ! user   !------------------------->! server !
+         ------------! RJE    !                          ! RJE    !
+                     ! module !<-------------------------! module !
+                     !        !                          !        !
+                     +--------+                          +--------+
+   
+      all RJE commands, replies and data on telnet connection
+   
+   
+                         RJE Using Only Telnet
+   
+                                 Figure 1.
+
+   +-----------+
+   !  user     !
+   !  RJE      !
+   ! interface !
+   +-----------+     +--------+     Telnet Connection      +--------+
+         !           ! user   !--------------------------->! server !
+         ------------! RJE    !  RJE Commands and Replies  ! RJE    !
+                     ! module !<---------------------------! module !
+                     +--------+                            +--------+
+                         !                                     !
+                     +--------+                            +--------+
+                     ! data   !          RJE Data          ! data   !
+                     !transfer!----------------------------!transfer!
+                     +--------+                            +--------+
+                        !                                      !
+           User's Local File System                  Server's RJE System
+           Card Readers or Line Printers
+   
+                 RJE Using a Separate Data Connection
+   
+                                 Figure 2.
+
+
+
+
+
+
+
+                                                               [page 25]
+
+NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
+An RJE Protocol for a Resource Sharing Network
+
+
+
+   +-----------+
+   !  user     !
+   !  RJE      !
+   ! interface !
+   +-----------+     +--------+     Telnet Connection      +--------+
+         !           ! user   !--------------------------->! server !
+         ------------! RJE    !  RJE Commands and Replies  ! RJE    !
+                     ! module !<---------------------------! module !
+                     +--------+                            +--------+
+   
+                        ! !
+                     +--------+     Telnet Connection      +--------+
+                     ! user   !--------------------------->! server !
+                     ! FTP    !  FTP Commands and Replies  ! FTP    !
+                     ! module !<---------------------------! module !
+                     +--------+                            +--------+
+   
+                         !                                     !
+                     +--------+                            +--------+
+                     ! data   !          RJE Data          ! data   !
+                     !transfer!----------------------------!transfer!
+                     +--------+                            +--------+
+                        !                                      !
+           User's Local File System                  Server's File
+   System
+           Card Readers or Line Printers
+   
+                               RJE Using FTP
+   
+                                 Figure 3.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                               [page 26]
\ No newline at end of file