summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc725.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc725.txt')
-rw-r--r--doc/rfc/rfc725.txt1580
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