doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc360.txt b/doc/rfc/rfc360.txt
new file mode 100644
index 0000000..f4586dc
--- /dev/null
+++ b/doc/rfc/rfc360.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group                                         C. Holland
+Request for Comments: 360                                        UCSD-CC
+Category: Protocols, RJE                                       June 1972
+NIC: 10602
+
+
+                   PROPOSED REMOTE JOB ENTRY PROTOCOL
+
+   Remote job entry is the mechanism whereby a user at one location
+   causes a batch-processing job to be run at some other location.  This
+   protocol specifies the Network standard procedures for such a user to
+   communicate over the Network with a remote batch-processing server,
+   causing that server to retrieve a job-input file, process the job,
+   and deliver the job's output file(s) to a remote location.  The
+   protocol uses TELNET (to a special standardized logger, not socket 1)
+   connection for all control communication between the user and the
+   server RJE process.  The server-site then uses the File Transfer
+   Protocol to retrieve the job-input file and to deliver the output
+   file(s).
+
+   There are two types of users: direct users (persons) and user
+   processes.  The direct user communicates from an interactive terminal
+   attached to a TIP or any host.  This user may cause the input and/or
+   output to be retrieved/sent on a specific socket at the specified
+   host (such as for card readers or printers on a TIP), or the user may
+   have the files transferred by pathname using File Transfer Protocol.
+   The other type of user is an RJE User-process in one remote host
+   communicating with the RJE Server-process in another host.  This type
+   of user ultimately receives its instructions from a human user, but
+   through some unspecified indirect means.  The command and response
+   streams of this protocol are designed to be readily used and
+   interpreted by both the human user and the user process.
+
+   A particular user location may choose to establish the TELNET control
+   connection for each logical job or may leave the control connection
+   open for extended periods.  If the control connection is left open,
+   then multiple job-files may be directed to be retrieved or optionally
+   (to servers that are able to determine the end of one logical job by
+   the input stream and form several jobs out of one input file) one
+   continuous retrieval may be done (as from a TIP card reader).  This
+   then forms a "hot" card reader to a particular server with the TELNET
+   connection serving as a "job monitor".  Since the output is always
+   transferred job at a time per connection to the output socket, the
+   output from this "hot" reader would appear when ready as if to a
+   "hot" printer.  Another possibility for more complex hosts is to
+   attach an RJE User-process to a card reader and take instructions
+   from a lead control card, causing an RJE control TELNET to be opened
+   to the appropriate host with appropriate logon and input retrieval
+
+
+
+Holland                                                         [Page 1]
+
+RFC 360                     REMOTE JOB ENTRY                   June 1972
+
+
+   commands.  This card reader would appear to the human user as a
+   Network "host" card reader.  The details of this RJE User-process are
+   beyond the scope of this protocol.
+
+   GENERAL SPECIFICATIONS
+
+   1.   User - A human user at a real terminal or a process that
+        supplies the command control stream causing a job to be
+        submitted remotely will be termed the User.  The procedure by
+        which a process user receives its instructions is beyond the
+        scope of this protocol.
+
+   2.   User TELNET - The User communicates its commands over the
+        Network in Network Virtual Terminal code through a User TELNET
+        process in the User's Host.  This User TELNET process initiates
+        its activity via ICP to the standard "RJE logger" socket (socket
+        5) at the desired RJE-server Host.
+
+   3.   RJE-server TELNET - The RJE-server process receives its command
+        stream from and sends its response stream to the TELNET channel
+        through an RJE-server TELNET process in the server host.  This
+        process must listen for the ICP on the "RJE logger" socket (and
+        cause appropriate ICP socket shifting).
+
+   4.   TELNET Connection - The command and response streams for the RJE
+        mechanism are via a TELNET-like connection to a special socket
+        with full specifications according to the current NWG TELNET
+        protocol.
+
+   5.   RJE-Server - The RJE-Server process resides in the Host which is
+        providing Remote Batch Job Entry service.  This process receives
+        input from the RJE-Server TELNET, controls access through the
+        "logon" procedure, retrieves input job files, queues jobs for
+        execution by the batch system, responds to status inquiries, and
+        transmits job output files when available.
+
+   6.   User FTP - All input and output files are transferred under
+        control of the RJE-server process at its initiative.  Those
+        files may be directly transferred via Request-for-connection to
+        a specific Host/socket or they may be transferred via File
+        Transfer Protocol.  If the later method is used, then the RJE-
+        server acts through its local User FTP process to cause the
+        transfer.  This process initiates activity by an active
+        Request-for-connection to the "FTP Logger" in the foreign host.
+
+
+
+
+
+
+
+Holland                                                         [Page 2]
+
+RFC 360                     REMOTE JOB ENTRY                   June 1972
+
+
+   7.   Server FTP - This process in a remote host (remote from the
+        RJE-server) listens for an ICP from the User FTP and then acts
+        upon the commands from the User FTP causing the appropriate file
+        transfer.
+
+   8.   FTP - When File Transfer Protocol is used for RJE files, the
+        standard FTP mechanism is used as fully specified by the current
+        NWG FTProtocol.
+
+   9.   RJE Command Language - The RJE system is controlled by a command
+        stream from the User over the TELNET connection specifying the
+        user's identity (logon), the source of the job input file, the
+        status, altering job status or output disposition.  Additional
+        commands affecting output disposition are includable in the job
+        input file.  This command language is explicitly specified in a
+        following section of this protocol.
+
+   10.  RJE Command Replies - Every command input from the User via
+        TELNET and certain other conditions calls for a response message
+        from the RJE-server to the User over the TELNET connection.
+        These messages are formatted in a standardized manner to
+        facilitate interpretation by both human Users and User
+        processes.  A following section of this protocol specifies the
+        response messages.
+
+   RJE COMMANDS OVER TELNET CONNECTION
+
+   GENERAL CONVENTIONS
+
+   1.   All commands will be contained in one input line terminated by
+        the standard TELNET "crlf".  The line may be of any length
+        desired by the user (explicitly, not restricted to a physical
+        terminal line width).  The characters "cr" and "lf" will be
+        ignored by the RJE-server except in the explicit order "crlf"
+        and may be used as needed for local terminal control.
+
+   2.   All commands will begin with a recognized command name and may
+        then contain recognized syntactic element strings and free-form
+        variable strings (for userid, pathnames, etc.).  Recognized
+        words consist of alphanumeric strings (letters and digits) or
+        punctuation.  Recognized alphanumeric string elements must be
+        separated from each other and from unrecognizable strings by at
+        least one blank or a syntactically permitted punctuation.  Other
+        blanks may be used freely as desired before or after any
+        syntactic element.  The "=" after the command name in all
+        commands except OUT and CHANGE are optional.
+
+
+
+
+
+Holland                                                         [Page 3]
+
+RFC 360                     REMOTE JOB ENTRY                   June 1972
+
+
+   3.   Recognized alphanumeric strings may contain upper case letters
+        or lower case letters in any mixture without syntactic
+        differentiation.  Unrecognizable strings will be used exactly as
+        presented with full differentiation of upper and lower case
+        input, unless the host finally using the string defines
+        otherwise.
+
+   4.   There are two types of Unrecognizable strings: final and
+        imbedded.  Final strings appear as the last syntactic element of
+        a command and are parsed as beginning with the next non-blank
+        character of the input stream and continuing to the last non-
+        blank character before the "crlf".
+
+        Imbedded strings include "job-id" and "job-file-id" in the OUT,
+        CHANGE, and ALTER commands.  At present these fields will be
+        left undelimitted since they must only be recognizable by the
+        server host which hopefully can recognize its own job-ids and
+        file-names.
+
+   SYNTAX: The following command descriptions are given in a BNF-like
+        syntax.  Parenthesized names are non-terminal syntactic elements
+        which are expanded in succeeding syntactic equations.  Each
+        equation has the defined name on the left of the ::= and a set
+        of alternative definitions, separated by slashes "/", on the
+        right.  The equations for (host-file) and (disp) use the
+        characters "/" "( )" explicitly in their definitions.  In these
+        cases the quotes are not part of the definition, but surround
+        literal text which is part.
+
+   USER
+
+     USER = (user-id)
+
+     This command must be the first command over a new TELNET
+     connection.  As such, it initiates a "logon" sequence.  The
+     response to this command is either
+
+      a) User code in error.
+      b) Enter password (if usercode ok)
+      c) Log-on ok, proceed.  (if no password required)
+
+     Another USER command may be sent by the User at any time to change
+     Users.  Further input will then be charged to the new user.  A
+     server may refuse to honor a new user command if it is not able to
+     process it in its current stat (during input file transfer, for
+     example), but the protocol permits the USER command at any time
+
+
+
+
+
+Holland                                                         [Page 4]
+
+RFC 360                     REMOTE JOB ENTRY                   June 1972
+
+
+     without altering previous activity.  An incorrect subsequent USER
+     command or its following PASS command are to be ignored with error
+     response, leaving the original User logged-in.
+
+     It is permissable for a server to close the TELNET connection if
+     the initial USER/PASS commands are not completed within a server
+     specified time period.
+
+     It is not required or implied that the "logged-on" User be the
+     user-id used for file transfer or job execution, but only
+     identifies the submitter of the command stream.  Servers will
+     establish their own rules relating User-id with the job-execution-
+     user for Job or Output alteration commands.
+
+     Successful "log-on" always clears any previous Input or Output
+     default parameters (INID, etc.).
+
+   PASS
+
+      PASS = (password)
+
+      This command immediately follows a USER command and completes the
+      "log-on" procedure.  Although a particular Server may not require
+      a password and has already indicated "log-on ok" after the USER
+      command, every Server must permit a PASS command (and possibly
+      ignore it) and acknowledge it with a "log-on ok" if the log-on is
+      completed.
+
+   BYE
+
+      BYE
+
+      This command terminates a USER and if input transfer is not in
+      progress, closes the TELNET connection.  If input is in progress,
+      the connection will remain open for result response and will then
+      close.  During the interim, a new USER command (and no other
+      command) is acceptable.
+
+      An unexpected close on the TELNET connection will cause the server
+      to take the effective action of an ABORT and BYE.
+
+   INID/INPASS
+
+      INID = (user-id)
+      INPASS = (password)
+
+
+
+
+
+
+Holland                                                         [Page 5]
+
+RFC 360                     REMOTE JOB ENTRY                   June 1972
+
+
+      The specified Userid and Password will be sent in the File
+      Transfer request to retrieve the input file.  These parameters are
+      not used by the Server in any other way.  If this command does not
+      appear, then the USER/PASS parameters are used.
+
+   INPATH/INPUT
+
+      INPATH = (pathname)
+      INPUT = (pathname)
+      INPUT
+
+      NOTE: The following syntax will also be used for output
+      (pathname).
+
+      (pathname)::= (host-socket) / (host-file)
+      (host-socket)::= (host),(socket) / (socket)
+           no (host) part implies the User-site host
+      (host)::= (decimal-integer) / (standard-host-name)
+      (socket)::= (decimal-integer) / PORT (decimal-integer)
+           (decimal-integer) implies explicit socket, lower bit
+                will be set appropriately for the direction
+           PORT implies the specified port-sockets for a TIP
+                Tip-Socket = Port * 2**16 + (2 or 3)
+      (host-file)::= (host)(attributes)"/"(file-name)
+      (attributes)::= (empty) / : (transmission)(code)
+      (transmission)::= (empty) / T / A / N
+           (empty) implies default which is
+                N for Input files
+                A for output files
+           T specifies TELNET-like coding with imbedded "crlf"
+                for new-line, "ff" for new-page
+           N specifies FTP blocked transfer with record marks
+                but without other carriage-control
+           A specifies FTP blocked records with ASA carriage-
+                control (column 1 of image is forms control)
+      (code)::= (empty) / E
+            (empty) specifies NVT ASCII code
+            E specifies EBCDIC (TE not allowed)
+      (file-name)::= (any string recognized by the
+                 FTP Server at the site of the file)
+
+   The (pathname) syntax is the general RJE mechanism for specifying a
+   particular file source or destination for input or output.  If the
+   (host-socket) form is used then direct transfer will be made by the
+   RJE-Server to the named socket using TELNET-like ASCII.  If the
+   (host-file) form is used then the RJE-server will call upon its local
+   FTP-user process to do the actual transfer.  The data stream in this
+   mode is either TELNET-like ASCII or blocked records (which may use
+
+
+
+Holland                                                         [Page 6]
+
+RFC 360                     REMOTE JOB ENTRY                   June 1972
+
+
+   column 1 for ASA carriage-control).  Although A mode is permitted on
+   input (column 1 is deleted) the usual mode would be the default N.
+   The output default A would supply carriage-control in the first
+   character of each record ("blank"= single-space, "1"=new-page, etc.),
+   while the optional N mode would transfer the data only (as to a card
+   punch, etc.).
+
+   The (file-name) is an arbitrary Unrecognized string which is saved by
+   RJE-server and sent back over FTP to the FTP-server to retrieve or
+   store the appropriate files.
+
+   INPATH or INPUT commands first store the specified (pathname) if one
+   is supplied, and then the INPUT command initiates input.  The INPATH
+   name may be used to specify a pathname for later input and the INPUT
+   command without pathname will cause input to initiate over a
+   previously specified pathname.  An INPUT "crlf" command with no
+   previous (pathname) specified is illegal.
+
+   ABORT
+
+      ABORT
+
+      This command aborts any input retrieval in progress, discards
+      already received records, and closes the retrieval connection.
+
+      Note: ABORT with parameters is an Output Transmission control.
+
+   OUTUSER/OUTPASS
+
+      OUTUSER = (user-id) OUTPASS = (password)
+
+      The specified Userid and Password will be sent in the File
+      Transfer request to send the output file(s).  These parameters are
+      not used by the Server in any other way.  If this command does not
+      appear, then the USER/PASS parameters are used.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Holland                                                         [Page 7]
+
+RFC 360                     REMOTE JOB ENTRY                   June 1972
+
+
+   OUT
+
+      OUT (out-file) = (disp)(pathname)
+
+      (out-file)::= (empty) / (job-file-id)
+           (empty) implies the primary print file of the job
+      (job-file-id)::= (string representing a specific output file
+                from the job as recognized by the Server)
+      (disp)::= (empty) / "(H)" / "(S)" / "(D)"
+           (empty) specifies Transmit then discard
+           (H) specifies Hold-only, do not transmit
+           (S) specifies Transmit and Save
+           (D) specified discard without transmitting
+         Note: Parentheses are part of the above elements.
+      (pathname)  see INPUT command
+
+      This command specifies the disposition of output file(s) produced
+      by the job.  Unspecified files will be Hold-only by default.  The
+      OUTUSER, OUTPASS, and OUT commands must be specified before INPUT
+      command to be effective.  These commands will affect any following
+      jobs submitted by this USER over this RJE-TELNET connection.  A
+      particular job may override these commands by NET control cards on
+      the front of the input file.
+
+      Once output disposition is specified by this OUT command or by a
+      NET OUT card, the information is kept with the job until final
+      output disposition, and is modifiable by the CHANGE command.
+
+   OUTPUT RE-ROUTE
+
+      CHANGE (job-id)(out-file) = (disp)(pathname)
+
+      This command changes the output disposition supplied with the job
+      submission.  The (job-id) is assumed recognizable by the RJE-
+      server, who may verify if this USER is authorized to modify the
+      specified job.  After the job is identified, the other information
+      has the same syntax and semantics as the original OUT command.
+      CHANGE command may be specified for a job-file-id which was not
+      mentioned at submission time and has the same effect as an
+      original OUT command.
+
+
+
+
+
+
+
+
+
+
+
+Holland                                                         [Page 8]
+
+RFC 360                     REMOTE JOB ENTRY                   June 1972
+
+
+   OUTPUT CONTROLS DURING TRANSMISSION
+
+      (command)(count)(what)
+
+      (command)::= RESTART / RECOVER / BACK / SKIP / ABORT / HOLD
+           these commands specify
+                Restart the transmission (new RFC, etc.)
+                Recover restarts transmission from last
+                   FTP Restart-marker-reply (see FTP).
+                Back up the output "count" blocks
+                Skip the output forward "count" blocks
+                Abort the output, discarding it
+                Hold the output after Aborting it
+      (count)::= (empty) / (decimal-integer)
+           (empty) implies  1 where defined
+      (what)::= @(pathname) / (job-id)(job-file-id)
+           (pathname) is as in the INP command
+      (job-id)::= (server recognized job identifier which was
+                supplied at INP completion by the server)
+      (job-file-id)::= (server recognized file identifier or
+                if missing then the prime printer output
+                of the specified job)
+
+      This collection of commands will modify the transmission of output
+      in progress or recently aborted.  If output transmission is cut-
+      off before completion, then the RJE-server will either try to
+      resend the entire file if the file's (disp) was Transmit-and-
+      discard or will Hold the file for further User control if the
+      (disp) was (S) transmit-and Save.  Either during transmission,
+      during the Save part of a transmit-and-Save, or for a Hold-only
+      file; the above commands may be used to control the transmission.
+      The @(pathname) form of (what) is permitted only if transmission
+      is actually in progress.
+
+      If the file's state is inconsistent with the command then the
+      command is illegal and ignored with reply.
+
+   STATUS
+
+      STATUS
+      STATUS (job-id)
+
+      These commands request the status of either the RJE-server or a
+      particular job respectively.  The information content of the
+      Status reply is site dependent.
+
+
+
+
+
+
+Holland                                                         [Page 9]
+
+RFC 360                     REMOTE JOB ENTRY                   June 1972
+
+
+   CANCEL/ALTER
+
+      CANCEL (job-id)
+      ALTER  (job-id) (site dependent options)
+
+      These commands change the course of a submitted job.  CANCEL
+      specifies that the job is to be immediately terminated and any
+      output discarded.  ALTER provides for system dependent options
+      such as changing job priority, process limits, Terminate without
+      Cancel, etc.
+
+   OP
+
+      OP (any string)
+
+      The specified string is to be displayed to the Server site
+      operator when any following job is initiated servicing from the
+      batch queue of the Server.  This command usually appears in the
+      input file as a NET OP control card, but may be a TELNET command.
+      It is cancelled as a all-jobs command by an OP "crlf" command (no
+      text supplied).
+
+   RJE CONTROL CARDS IN THE INPUT FILE
+
+   Certain RJE commands may be specified by control cards in the front
+   of the input file.  If these controls appear, they take precedence
+   over the same command given thru the RJE-TELNET connection and affect
+   only this specific job.
+
+   All these RJE control cards must appear as the first records of the
+   job's input-file.  They all contain the control word NET in columns
+   1-2.  Scanning for these controls stop when the first card without
+   NET in col 1-3 is encountered.
+
+   The control commands appear in individual records and are terminated
+   by the end-of-record (usually an 80 column card-image).  Continuation
+   is permitted onto the next record by the appearance of NET+ in
+   columns 1-4 of the next record.  Column 5 of the next record
+   immediately follows the last character of the previous record.
+
+   NET OUTUSER = (userid)
+
+   NET OUTPASS = (password)
+
+   NET OUT (out-file) = (disp)(pathname)
+
+   NET OP (any string)
+
+
+
+
+Holland                                                        [Page 10]
+
+RFC 360                     REMOTE JOB ENTRY                   June 1972
+
+
+   See the corresponding TELNET commands for details.  One option
+   permitted by the NET OUTUSER and NET OUT controls not possible from
+   the TELNET connection is specification of different OUTUSERs for
+   different OUTs, since the TELNET stores and supplies only an initial
+   OUTUSER, but the controls may change OUTUSERs before each OUT control
+   is encountered.
+
+   RJE USE OF FILE TRANSFER PROTOCOL
+
+   Most non-TIP files will be transferred to or from the RJE-server
+   through the FTP process.  RJE-server will call upon its local FTP-
+   user supplying the Host, File-pathname, User-id, Password, and Mode
+   of the desired transfer.  FTP-user will then connect to its FTP-
+   server counterpart in the specified host and set up a transfer path.
+   Data will then flow through the RJE-FTP interface in the Server, over
+   the Network, from/to the foreign FTP-server and then from/to the
+   specified File-pathname in the foreign host's file storage space.  On
+   output files, the file-pathname may be recognized by the foreign host
+   as directions to a printer or the file may simply be stored; a User-
+   RJE-process can supply output (pathname) by default which is
+   recognized by its own Server-FTP as routing to a printer.
+
+   Although many specifics of the RJE-Server/User-FTP interface are
+   going to be site dependent, there are several FTP options which will
+   be used in a standard way by RJE-Servers:
+
+   1.   A new FTP connection will be initiated for each file to be
+        transferred.  The connection will be opened with the RJE User
+        supplied User-id (OUTUSER or INUSER) and Password.
+
+   2.   The data bytesize will be 8 bits.
+
+   3.   The FTP Type, Structure, and Mode parameters are determined by
+        the RJE transfer direction (I/O), the (transmission and (code)
+        options supplied by the User:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Holland                                                        [Page 11]
+
+RFC 360                     REMOTE JOB ENTRY                   June 1972
+
+
+                I/O   (TRANS)   (CODE)   FTP TYPE   STRUCTURE   MODE
+                ----------------------------------------------------
+                I*      N        -       Ascii         R       Hasp
+                I       N        E       Image         R       Hasp
+                I       T        -       Ascii         F       Ascii
+                I       A        -       Ascii         R       Hasp
+                I       A        E       Image         R       Hasp
+
+                O*      A        -       Ascii-print   R       Hasp
+                O       A        E       Ebcdic-print  R       Hasp
+                O       N        -       Ascii         R       Hasp
+                O       N        E       Image         R       Hasp
+                O       T        -       Ascii-print   F       Ascii
+
+                 Note: The I* and O* are the default cases.
+
+   4.   The service commands used will be Retrieve for input and Append
+        (with create) for output.  The FTP pathname will be the (file-
+        name) supplied by the RJE User.
+
+   5.   On output in Hasp form, the User-FTP at the RJE-Server site will
+        send Restart-markers at periodic intervals (like every 100
+        lines, or so), and will remember the latest Restart-marker-reply
+        with the file.  If the file transfer is not completed and the
+        (disp) is (S) then the file will be held pending User
+        intervention.  The User may then use the RECOVER command to
+        cause a FTP restart at the last remembered Restart-marker-reply.
+
+   6.   The FTP Abort command will be used for the RJE ABORT and CANCEL
+        commands.
+
+   The specific form of the FTP commands used by an RJE-Server site, and
+   the order in which they are used will not be specified in this
+   protocol.
+
+   Errors encountered by FTP fall into three categories: a)access errors
+   or no storage space error; b)command format errors; and c)transfer
+   failure errors.  Since the commands are created by the RJE-Server
+   process, an error is a programming problem and should be logged for
+   attention and the situation handled as safely as possible.
+   Transmission failure or access failure on input cause an effective
+   ABORT and user notification.  Transmission failure on output causes
+   RESTART or Save depending on (disp).  (see OUT command.) Access
+   failure on output is a problem since the User may not be accessible.
+   A status response should be queued for that user, should he happen to
+   inquire; a (disp)=(S) file should be Held; and a  (disp)=(empty)
+   transmit-and-discard file should be temporarily held and then
+   discarded after a reasonable time if not claimed.
+
+
+
+Holland                                                        [Page 12]
+
+RFC 360                     REMOTE JOB ENTRY                   June 1972
+
+
+   REPLIES OVER THE TELNET CONNECTION
+
+   Each action of the RJE-server, including entry of each TELNET
+   command, is noted over the TELNET connection to the User.  These
+   RJE-server replies are formatted for Human or Process interpretation.
+   They consist of a leading 3-digit numeric code followed by a blank
+   followed by a text explanation of the message.  The numeric codes are
+   assigned by groups for future expansion to hopefully cover other
+   protocols besides RJE (like FTP).  The numeric code is designed for
+   ease of interpretation by processes.  The three digits of the code
+   are interpreted as follows:
+
+   a) The first digit specifies the "type" of response indicated:
+
+      000 These "replies" are purely informative, and are issued
+          voluntarily by the Server to inform a User of some state of
+          the server's system.
+
+      100 Replies to a specific status inquiry.  These replies server as
+          both information and as acknowledgement of the status request.
+
+      200 Positive acknowledgement of some previous command/request.
+          The reply 200 is a generalized "ok" for commands which require
+          no other comment.  Other 2xx replies are specified for
+          specific successful actions.
+
+      300 Incomplete information supplied so far.  No major problem, but
+          activity can not proceed with the input supplied.
+
+      400 Unsuccessful reply.  A request was correctly specified, but
+          could not be correctly completed.  Further attempts will
+          require User commands.
+
+          500 Incorrect or illegal command.  The command or its
+          parameters were invalid or incomplete from a syntactic view,
+          or the command is inconsistent with a previous command.  The
+          command in question has been totally ignored.
+
+      600-900 Reserved for expansion.
+
+   b) The second digit specifies the general subject to which the
+      response refers:
+
+      x00-x29 General purpose replies, not assignable to other subjects.
+
+      x30 Primary access.  There replies refer to the attempt to "log-
+          on" to a Server service (RJE, FTP, etc.).
+
+
+
+
+Holland                                                        [Page 13]
+
+RFC 360                     REMOTE JOB ENTRY                   June 1972
+
+
+      x40 Secondary access.  The primary Server is commenting on its
+          ability to access a secondary service (RJE must log-on to a
+          remote FTP service).
+
+      x50 FTP results.
+
+      x60 RJE results.
+
+      x70-x99 Reserved for expansion.
+
+   c) The final digit specifies a particular message type.  Since the
+      code is designed for an automation process to interpret, it is not
+      necessary for every variation of a reply to have a unique number,
+      only that the basic meaning have a unique number.  The text of a
+      reply can explain the specific reason for the reply to a human
+      User.
+
+   Each TELNET line (ended by "crlf") from the Server is intended to be
+   a complete reply message.  If it is necessary to continue the text of
+   a reply onto following lines, then those continuation replies contain
+   the special reply code of three blanks.
+
+   The assigned reply codes relating to RJE are:
+
+      000 General information message (time of day, etc.)
+      030 Server availability information
+      050 FTP commentary or user information
+      060 RJE or Batch system commentary or information
+      100 System status reply
+      150 File status reply
+      151 Directory listing reply
+      160 RJE system general status reply
+      161 RJE job status reply
+      200 Last command received ok
+      201 An ABORT has terminated activity, as requested
+      202 ABORT request ignored, no activity in progress
+      203 The requested Transmission Control has taken effect
+      230 LOG-on completed
+      231 Log-off completed, goodbye.
+      232 Log-off noted, will complete when transfer done
+      240 File transfer has started
+      250 FTP file transfer started ok
+      251 FTP Restart-marker-reply
+            Text is: MARK yyyy = mmmm
+             where yyyy is data stream marker value (yours)
+              and mmmm is receiver's equivalent mark (mine)
+      252 FTP transfer completed ok
+      253 Rename completed
+
+
+
+Holland                                                        [Page 14]
+
+RFC 360                     REMOTE JOB ENTRY                   June 1972
+
+
+      254 Delete completed
+      260 Job (job-id) accepted for processing
+      261 Job (job-id) completed, awaiting output transfer
+      262 Job (job-id) Cancelled as requested
+      263 Job (job-id) Altered as requested to state (status)
+      300 Connection greeting message, awaiting input
+      301 Current command not completed
+             (may be sent after suitable delay, if no "crlf")
+      330 Enter password
+             (may be sent with hide-your-input mode)
+      360 INPUT has never specified an INPATH
+      400 This service is not implemented
+      401 This service is not accepting log-on now, goodbye.
+      430 Log-on time or tries exceeded, goodbye.
+      431 Log-on unsuccessful, user and/or password invalid
+      432 User not valid for this service
+      434 Log-out forced by operator action, please phone site
+      435 Log-out forced by system problem
+      436 Service shutting down, goodbye.
+      440 RJE could not log-on to remote FTP for input transfer
+      441 RJE could not access the specified input file through FTP
+      442 RJE could not establish (host-socket) input connection
+      443 RJE could not log-on to remote FTP for output delivery
+      444 RJE could not access file space given for output
+      445 RJE could not establish (host-socket) output connection
+      450 FTP: The named file does not exist (or access denied)
+      451 FTP: The named file space not accessible by YOU
+      452 FTP: Transfer not completed, data connection closed
+      453 FTP: Transfer not completed, insufficient storage space
+      460 Job input not completed, ABORT performed
+      461 Job format not acceptable for processing, Cancelled
+      462 Job previously accepted has mysteriously been lost
+      463 Job previously accepted did not complete
+      464 Job-id referenced by STATUS, CANCEL, ALTER, CHANGE, or
+            Transmission Control is not known (or access denied)
+      465 Requested Alteration not permitted for the specified job
+      466 Un-deliverable, un-claimed output for (job-id) discarded
+      500 Last command line completely unrecognized
+      501 Syntax of the last command is incorrect
+      502 Last command incomplete, parameters missing
+      503 Last command invalid, illegal parameter combination
+      504 Last command invalid, action not possible at this time
+      505 Last command conflicts illegally with previous command(s)
+      506 Requested action not implemented by this Server
+
+
+
+
+
+
+
+Holland                                                        [Page 15]
+
+RFC 360                     REMOTE JOB ENTRY                   June 1972
+
+
+   SEQUENCING OF COMMANDS AND REPLIES
+
+   The communication between the User and Server is intended to be an
+   alternating dialogue.  As such, the User issues an RJE command and
+   the Server responds with a prompt primary reply.  The User should
+   wait for this initial success or failure response before sending
+   further commands.
+
+   A second type of reply is sent by Server asynchronously with respect
+   to User commands.  These replies report on the progress of a job
+   submission caused by the INPUT command and as such are secondary
+   replies to that command
+
+   The final class of Server "replies" are strictly informational and
+   may arrive at any time.  These "replies" are listed below as
+   spontaneous.
+
+                    COMMAND-REPLY CORRESPONDENCE TABLE
+
+   COMMAND                  Success        Fail
+   -------                  -------        ----
+   USER                     230,330        430,431,432,500-505
+   PASS                     230            430,431,432,500-505
+   BYE                      231,232        500-505
+   INID                     200            500-505
+   INPASS                   200            500-505
+   INPATH                   200            500-505
+   INPUT                    240            360,440-442,500-505
+     sec. Input retrieval   260            460,461
+     sec. Job execution     261            462,463
+     sec. Output Transmission --           443,444,445,446
+   ABORT (input)            201,202        500-505
+   OUTUSER                  200            500-505
+   OUTPASS                  200            500-505
+   OUT                      200            500-505
+   CHANGE                   200            500-505
+   RESTART/RECOVER/BACK/
+    SKIP/ABORT(output)/HOLD 203            464,500-506
+   STATUS                   1xx            464,500-505
+   CANCEL                   262            464,500-506
+   ALTER                    263            464,465,500-506
+   OP                       200            500-505
+   Spontaneous              0xx,300,301    434-436
+
+   Note: For commands appearing on cards, the 200 is not sent
+         but the 500-505 errors may be "asynchronously" sent.
+
+
+
+
+
+Holland                                                        [Page 16]
+
+RFC 360                     REMOTE JOB ENTRY                   June 1972
+
+
+   TYPICAL RJE SCENARIOS
+
+   1. TIP USER WANTING HOT CARD READER TO HOSTX
+      a) TIP user opens TELNET connection to HOSTX socket 5
+      b) Commands sent over TELNET to RJE
+         USER=myself
+         PASS=dorwssap
+         OUT=PORT 7
+         INPUT=PORT 5
+      c) RJE-server connects to the User's host port 5 and begins
+         reading.  When end-of-job card is recognized, the job is queued
+         to run.  The connection to the card reader is still open for
+         more input as another job
+      d) The first job finishes.  A connection to the Users host port 7
+         is established by RJE-server and the output is sent as an NVT
+         stream.
+      e) Continue at any time with another deck at step c).
+
+   2. TIP WITH JOB-AT-A-TIME CARD READER
+      a) thru d) the same but User closes Reader after the deck
+      e) The output finishes and the printer connection closes.
+      f) INPUT may be typed any time after step c) finishes and another
+         job will be entered starting at c).
+
+   3. HOSTA USER RUNS JOB AT HOSTC, INPUT FROM HOSTB
+      a) User TELNET connects to HOSTC socket 5 for RJE
+         USER=roundabout
+         PASS=aaabbbc
+         OUTUSER=roundab1
+         OUT=:E/.sysprinter
+         OUT puncher = (s)HOSTB:NE/my.savepunch
+         INUSER=rounder
+         INPASS=x.x.x
+         INPUT=HOSTB:E/my.jobinput
+      b) The RJE-server has FTP retrieve the input from HOSTB using
+         Userid of "rounder" and Password of "x.x.x" for file named
+         "my.jobinput".
+      c) The job finishes.  RJE-server uses FTP to send two files:  the
+         print output is sent to HOSTA in EBCDIC with ASA carriage
+         control to file ".sysprinter" while the file known as "puncher"
+         is sent to HOSTB in EBCDIC without carriage-control to file
+         "my.savepunch".
+      d) when the outputs finish, RJE-server at HOSTC discards the print
+         file but retains the "puncher" file.
+      e) The User who had signed out after job submission has gotten his
+         output and checked his file "my.savepunch" at HOSTB.  He
+         deletes the saved copy at HOSTC by re-calling RJE at HOSTC.
+         USER=roundabout
+
+
+
+Holland                                                        [Page 17]
+
+RFC 360                     REMOTE JOB ENTRY                   June 1972
+
+
+         PASS=aaabbbcc
+         ABORT job123 puncher
+           or by
+         CHANGE job123 puncher = (D)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Holland                                                        [Page 18]
+