NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316An RJE Protocol for a Resource Sharing Network CAC Technical Memorandum No. 86 CCTC-WAD No. 7508 ARPANET RFCNo. 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 38316An RJE Protocol for a Resource Sharing NetworkFor many users of the ARPANET, an RJE protocol is probably as importantin terms of utility as a TELNET (VTP) protocol. In fact, the facilitiesprovided by a TELNET and an RJE protocol are probably of most interestto most users of computer networks. For these users, the net provides afast, cheap RJE surrogate, just as TELNET provides a telephone surrogatefor the timesharing user. The collection (and layers) of protocols thatprovide these services must be organized to efficiently support a widevariety of applications and user needs. They should not pose an unduesoftware burden on the user.The "official" NETRJE protocol for the ARPANET has met an underwhelmingresponse from both the user and server community. I believe there aretwo basic reasons. First, a large commitment of resources is necessaryto implement NETRJE. Second, the protocol creates serious securityproblems.In order to support the ARPA RJE protocol, a user must implement UserTelnet, Server FTP, and User RJE, while a server must implement ServerTelnet, User FTP, and Server RJE. In addition when an RJE session isgoing on all three of these protocol implementations will be executingfor most of the life of the session. This could entail considerableburden for some systems. Although it may not be out of line to requirea 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 userinstallations are oriented toward meeting their user's needs not towardimplementing large amounts of network software. (In fact one of thebetter aspects of the previous ARPANET protocol designs was that theyattempted to minimize the work for the user. (It must be admittedthough that compassion for the user was not the reason for thisapproach.)In order to support a "hot line printer" (i.e., a job is automaticallyprinted when it is completed), the user must store his user code andpassWord for the output host at the server host. This, of course,presents a rather severe security problem. Although the ARPANET can notbe made totally secure without massive revision, there are some basicprecautions that can be taken to protect users from being victimized byevery first year Computer Science student with access to the net.The RJE protocol proposed here tries to mitigate the implementationproblems and security problems. The protocol is designed to providethree levels of service. A user or server has the perogative toimplement the protocol at whatever level their resources allow. Theservice can then be upgraded to cleaner or more sophisticated approacheswhen 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 38316An RJE Protocol for a Resource Sharing Networkthe design (such as the reply structure) were made to coincide withexisting ARPANET conventions. This was done to facilitate understandingand limit the discussion to the protocol itself. Although the protocolis described in ARPANET terms, it should be applicable to other networkenvironments.This paper is not considered to be complete in every detail. It waswritten primarily to elicit comments from the network community and tomeasure the desire of the community to adopt such a procedure. We havetried to describe enough of the protocol so that the reader can get anidea of how things are to work without getting bogged down in the detailthat would be necessary for implementation. Below is an outline of thefinal protocol document as presently conceived. Sections marked with anasterisk are to be provided later. [page 2] NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316An RJE Protocol for a Resource Sharing NetworkIntroductionPart 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 ApplicationsPart 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 38316An RJE Protocol for a Resource Sharing NetworkPart 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. Thenarrative should provide the general reader with the flavor of theprotocol without getting bogged down in unnecessary detail. Theproposed NETRJE protocol provides three different models for jobsubmission and retrieval. The three models can be characterized as 1)RJE using Telnet only, 2) RJE using Telnet and Data Transfer, and 3) RJEusing FTP. This approach provides flexibility for both implementors andusers. User and server sites constrained by manpower or machineresources may implement only the simpler models. The user may use thedifferent models separately or in any consistent combination which bestsuits his requirements and convenience. Servers should assume that theminimal implementation of a more sophisticated model includes theminimal implementations of all less sophisticated models. (There are,however, certain minimal requirements that must be supported.) Thissecton will discuss each of these models in turn, and show each one canbe used to provide a useful network RJE functon.This protocol does not contain the security difficulties of the presentprotocol. This has been avoided by requiring that the burden ofimplementing the "hot line printer" or "hot card reader" be put on theuser system. Thus, those systems which desire such a facility may stillsupport 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 anordered, error free bit stream to the RJE protocol. It is also assumedthat a suitable virtual terminal protocol such as Telnet, is used toformat the control connection.RJE Using Only Telnet (VTP)---------------------------The intent of this model is, bluntly, to provide an official "quick anddirty" form of the protocol. Many organizatons, both users and servers,are often confronted with problem of providing a service quickly orwithin very tight budgetary constraints. This model is intended forthese 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 orprinter output has the appearance of coming from or going to the user'sterminal. The user's system may allow output to be diverted from theterminal to another device such as the line printer. The technique ofdiverting terminal output was used with great success in the MARK I ANTS [page 4] NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316An RJE Protocol for a Resource Sharing Networksystems where various devices were not assigned socket numbers as in aTIP. This technique is also useful for hosts that allow program accessto the network only through the user's Telnet connection. Thissituation may exist in the early phases of a server's availability tothe network. When data is transferred in this mode an end-of-datamarker will be sent to aid the receiving host in determining when tostop diverting the data. This model will have to handle the problems ofdata traveling on a connection essentially meant for control. The useof this data transfer mechanism is intended as an intermediate measurerequired by limited resources. For now we let it stand that thedesigners are aware of the problems inherent in embedding commands orreplies in the data stream. We will leave the exact resolution of theproblem to the formal definition.This proposed NETRJE protocol uses a schedule verb, SCHED for jobsubmission. For this model, there are two forms of SCHED that arerelevant. First, there is the "SCHED <server pathname>" form. Thiscommand indicates to the server that there exists at the server site afile with all necessary job control information and data to define ajob. The server will then attempt to place the job in the job queue andreply to the user indicating success or failure and possibly a job-id.This job-id will be used when inquiring about the job status orretrieving 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 jobcontrol or possibly a program. It also allows those users whose localsystems provide a facility to transmit files with User TELNET totransmit user input job fles in this way. The RJE Server would insertthe job into the local job stream, returning the proper indication ofsuccess or failure along with identification of the job.
Just as the SCHED command provides several ways for job submission, theOUTPUT command provides several options for retrieving output. The form [page 5] NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316An RJE Protocol for a Resource Sharing Network OUTPUT<job-id><server pathname>DISCARDis sent to the server to initiate the output to the user's siteaccording to output specifications defined by previous OUTDEF commands(see below). The optional DISCARD argument to the OUTPUT commandindicates, if present, that the file is to be destroyed aftertransmission has completed successfully.The OUTDEF command for a job may be sent at any time after the job hasbeen scheduled and before it is retrieved using the OUTPUT command.This command will specify the parameters necessary to effect thetransfer of the output to the user or to define the disposition of theoutput. We realize that the OUTDEF <job-id><server pathname> command(indicating that output is to be placed in a file described by thepathname) may be difficult for some systems to implement. These systemswould merely respond negatively indicating their inability to performthe function.A scenario is now in order to illustrate the model. The user has loggedin 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>TREKThe system responds with a reply indicating the job has been submittedsuccessfully 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 thatthe job should be sent on the TELNET connection. A reply returns XXX last command successful.The user now sends OUTPUT XA1423and 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 38316An RJE Protocol for a Resource Sharing NetworkThis exchange allows the user to effect output diversion at his localsite if necessary after he has confirmed the server is ready.If the user had not wished to wait on his output and had logged offafter getting the successful submission, the next time the user loggedin he could inquire as to the status of the job or all jobs under hisusercode 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. Thismodel provides better data transfer facilities without requiring an FTP
implementation. This model requires no new commands, but doesmanipulate connections differently, so that data is not required to flowon the command connection (see Fig. 2). Data is sent on separatedefault connections (unless otherwise specified) as in the CCN NETRJSprotocol. However, for this protocol the defaults used will be the sameoffsets from the control connection as those in FTP.The use of this model is indicated to the Server by either the INDEFcommand or a SCHED command with no arguments. The INDEF command allowsthe user to specify a socket other than the default socket as the sourceof the input. On receipt of the SCHED or INDEF indicating thistechnique is to be used, the Server will attempt to connect to theappropriate socket. If a SCHED command was sent, the user protocolinterpreter could start sending cards as soon as the data connection isestablished. (It is assumed that the user interface has indicated tothe RJE protocol interpreter where the cards are to come from.) If thecommand was INDEF, then the Server will not start reading until theSCHED is received. Similarly, when the output is ready, either anOUTDEF or OUTPUT command is sent to set up and start the printing. TheINDEF and OUTDEF commands used with this mode will also allow movingdata to or from a TIP or printer.This model requires definiton of actual data transfer formats for thereader and printer lines. We propose that the formats and connectionschemes of the present FTP be adopted. This solution has the advantageof not requiring extra coding efforts for users with FTP implementationsand may allow them to organize their FTP implementations and may allowthem to organize their FTP and NETRJE implementations in such a way asto take advantage of common algorithms. One might easily confuse thissolution with a revival of the Data Transfer Protocol. Some thought ona more rigorous definition of a Data Transfer Protocol for the commonuse of FTP and RJE might be worthwhile in the future. [page 7] NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316An RJE Protocol for a Resource Sharing NetworkLet 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 socketwhile 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 startedand 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 willthen 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 XA1423and the Server will start sending and reply to the user XXX print started.When the transfer is complete the Server will close the data connectionand send an appropriate reply. [page 8] NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316An RJE Protocol for a Resource Sharing NetworkNETRJE Using FTP----------------This model (illustrated in Fig. 3) uses FTP to effect the transfer ofthe files. It may be easier for some systems to use this sort of modelfor more sophisticated RJE systems. This is especially true if theusers desire to take input from the local file system or to send outputto the local file system rather than from an actual card reader or to anactual line printer. Although using the local file system is notprohibited by the Data Transfer model, it may be easier to approachthrough FTP. Using FTP with NETRJE also allows the utilization of theFTP server-server transfer mechanism to generate input from or directoutput to a third host.The only new facility required by this model are the commands INPATH andOUTPATH. When using FTP to transfer input to the Server, the user mustknow where to send the job so that it enters the job stream. The INPATHcommand returns as a reply such a legal pathname. Thus the scenario forjob submission is as follows: The user sends an INPATH command; theServer responds with a legal Server pathname for the user. The userprocess starts sending the input to the file using FTP. When transferis complete, the user sends a SCHED <server pathname> command. When thejob has finished, the pathname created for the user may or may notdestroy the input file. The OUTPATH command is similarily used toidentify the pathname for the output, so that it may be retrieved byFTP. Some systems may define file names in such a way that the user mayderive them from the parameters of his job.Note on RepliesIn all of the above examples we have refrained from defining actualreply codes. The intent is to use the same reply structure, and whereappropriate the same numbers, as described in RFC640 "Revised FTP ReplyCodes".Protocol MeasurementAn integral part of any good protocol definition is a set ofmeasurements to allow evaluation of both the protocol and itsimplementation. This provides two functions: 1) It allows the protocoldesigner to evaluate the protocol and make improvements. 2) It allowsthe user of the protocol to know how eXPensive it is and to demandimprovements. The proposed NETRJE protocol provides two sets ofmeasures - 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 costmeasurements), SESSION (measurements taken for this sesson), and GLOBAL [page 9] NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316An RJE Protocol for a Resource Sharing Network(overall measurements of the performance of the protocol and itsimplementation). The command will return the measurements in a fixedformat 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 38316An 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 astransmission rate) when NETRJE is using FTP. This is unavoidable sinceFTP is not metered. The most straightforward solution is also to meterFTP (hint). For the final definition a close look will be given to thesubset that should be required. Comments are welcome. However, webelieve strongly that it is very important to know how a facility likethis is used as well as how well it performs. [page 11] NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316An RJE Protocol for a Resource Sharing NetworkPart II. Preliminary Definition of NETRJE Commands---------------------------------------------------For purposes of discussion this section gives a very preliminarydefinition of the NETRJE commands and their replies. The intent is togive a brief but not exhaustive definition of each command and its majorreplies to give the flavor of the protocol. We do not do this to
discourage nit-picking by critics, since we may actually overlook theobvious on occasion, but merely to expedite the writing of this paper.The reply scheme will follow the model of the revised FTP reply codesdescribed in RFC640.Access Control USER <usercode> PASS <password> ACCT <account>These perform the normal functions to log the user into the system. Thereplies to them are the standard ones in FTP. It was never clear why"account" was not included in the old NETRJE. Presumably, if it'snecessary for an FTP or Telnet user, it will be necessary for an RJEuser.REINITThis command reinitializes the state of the NETRJE server process sothat it is ready for a new user. If the transfer of data is in progressfor the previous user, it will be allowed to complete.ABORTThis command is used to abort the transfer of data. This command ismeaningful to the Server only if the data is being transferred over theTelnet connection or the default data sockets. If FTP is being used,the execution of this command is the responsibility of the USER NETRJEprocess.BYEThis command causes the Server to log out the user and close the Telnetconnection. If the transfer of data is in progress, the action of thecommand will be delayed until the transfer is complete. [page 12] NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316An RJE Protocol for a Resource Sharing NetworkSCHED <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 charactersterminated by an ASCII NULL}This command causes the input described by the <input part> to beentered into the RJE job stream and the output produced to be disposedof according to the <output part>. The null condition for eitherargument implies that the information has been previously specified oris the default.For the <input part>, the <empty> may imply two actions. If an INDEFcommand has previously specified a <server pathname>, input to the jobstream is taken from the file indicated by the file name. If the INDEFcommand has specified that the input is to come from a CCN-like datatransfer socket, the SCHED <empty> command is the signal for the Serverto start reading data.The DISCARD modifier, if present, indicates that the file should bediscarded after it has been transmitted or it has been received andexecuted. 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 isprovided for mini-hosts that can't use one of the other techniques andfor 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 (OUTDEFcommand).Successful replies to this command should indicate any job-id assignedby the local RJE system along with other status informaton. Failurewould 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 38316An RJE Protocol for a Resource Sharing NetworkThis command indicates to the Server what output is to be sent to theuser, how it is to be sent, and to whom. The <IO params> part willallow the specification of a host and socket so that output may be sentto a TIP printer, or alternatively sent on the Telnet connection or tothe default data sockets. This argument also specifies the format andrepresentation of the data.When the Server receives this command, it will proceed to transmit theoutput to the host in the prescribed manner. The reply structure ofthis command will depend on how the output is moved and will bediscussed in more detail later.INPATHThis command returns to the user a legal pathname at the Server. Theuser may then transfer his input to this pathname for eventualsubmission to the RJE facility.OUTPATHThis 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 ajob.INDEF <job-id><I/O params>OUTDEF <job-id><I/O params>These commands allow the user to specify the parameters necessary tosend input or retrieve output. This command specifies how the data willbe 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 specificjob. [page 14] NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316An RJE Protocol for a Resource Sharing NetworkALTER <job-id><site specific option>SITE <site specific option>These commands allow site specific commands to be passed to the ServerRJE system. The ALTER command is intended to effect specific jobs,
while the SITE command is used for commands of more global effect. Theycould be merged into one.OP <operator message>This command allows messages to be sent to the operator at the Serversite.Reply Codes for the Proposed NETRJE-----------------------------------The reply codes for this protocol will follow the model proposed for thenew FTP specificaton in RFC640. As a reminder we insert the pertinentinformation 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 38316An RJE Protocol for a Resource Sharing Network4yz 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, syntacticallycorrect commands that don't fit any functional category, andunimplemented 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 dataconnections.x3z Authentication and accounting - Replies for the logon processand accountng procedures.x4z Unspecified as yet.x5z File system - These replies indicate the status of the Serverfile system vis-a-vis the requested transfer or other file systemaction. [page 16] NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316An RJE Protocol for a Resource Sharing NetworkThe third digit gives a finer gradation of meaning in each of thefunction categories specified by the second digit. The list of repliesbelow will illustrate this. Note that the text associated with eachreply is suggestive, rather than mandatory, and may even changeaccording 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 thatare only slightly different from the ones described here, but rathershould adapt codes already defined.Below is a list of replies ordered by reply code. Some new replies havebeen added for RJE; these are marked by asterisks to aid the reader.Following this list is a list of commands with the replies that arepossible for that command. This list is not considered complete orfinal; 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 minutes125 Data connection already open; transfer starting150 File status okay; about to open data connection200 Command okay202 Command not implemented, superfluous at this site211 System status, or system help reply212 Directory status213 File status214 Help message (on how to use the server or the meaning of aparticular non-standard command. This reply is useful only to the humanuser.)*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 reply220 Service ready for new user221 Service closing TELNET connecton (logged off if appropriate)225 Data connection open; no transfer in progress226 Closing data connection; requested file action successful (forexample, file transfer or file abort.)227 Entering [passive, active] mode230 User logged in250 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 status331 User name okay, need password332 Need account for login350 Requested file action held in abeyance, pending further information354 Start mail input; end with CRLF, CRLF*360 Job <job-id> successfully submitted421 Service not available, closing Telnet connecton. (This may be areply to any command if the service knows it must shut down.)425 Can't open data connection426 Connection trouble, closed; transfer aborted [page 18] NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316An RJE Protocol for a Resource Sharing Network450 Requested file action not taken; file unavailable (e.g., file notfound, no access)451 Requested action aborted; local error in processing452 Requested action not taken: insufficient storage space in system500 Syntax error, command unrecognized (This may include errors such ascommand line too long.)501 Syntax error in parameters or arguments502 Command not implemented503 Bad sequence of commands504 Command not implemented for that parameter530 Not logged in532 Need account for storing files550 Requested action not taken: file unavailable (e.g., file busy)552 Requested file action aborted: exceeded storage allocation forcurrent 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 38316An 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 38316An 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 38316An 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 38316An 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 38316An RJE Protocol for a Resource Sharing NetworkReferences----------Braden, R. 1971 "Interim NETRJS Specifications", RFC189, NIC 7133.Bressler, R.; Guida, R.; and McKenzie, A. 1972 "Remote Job Entry Protocol", RFC407Neigus, N. 1973 "The File Transfer Protocol", RFC542.Neigus, N.; Pogran, K.; and Postel, J. 1974 "A New Schema for FTP Reply Codes", RFC640. [page 24]
NWG/RFC# 725 DAY GRG 25-APR-77 12:41 38316An RJE Protocol for a Resource Sharing NetworkFigures------- +-----------+ ! ! ! 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 38316An 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]
新闻热点
疑难解答
