RFC 725

RJE protocol for a resource sharing network

📅 published March 1977, from ietf

Okay bestie, let's get the vibes straight first 🦋. This is NWG/RFC# 725, also known as ARPANET RFC No. 725 ✨. It's also CAC Technical Memorandum No. 86, CCTC-WAD No. 7508, and NIC No. 38316 💅. It's called An RJE Protocol for a Resource Sharing Network, it's by John Day and Gary R. Grossman 🫶, and it's dated March 1, 1977 📅.

It was 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. The work came from the Center for Advanced Computation, University of Illinois at Urbana-Champaign, Urbana, Illinois 61801 🌸. It's approved for release by Peter A. Alsberg, Principal Investigator 👑.

The header stamp reads:

NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316

The title page doesn't name a category or status, and it doesn't say whether this one obsoletes or updates anything, so I'm not going to guess 🙈. What it does say is that it's a paper written to get comments and to see how much the network community wants this kind of procedure 🧐.

Introduction ✨

Here's the outline of the final protocol doc as it's currently planned. Anything with an asterisk is coming later 💅.

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

Okay so for tons of ARPANET users, an RJE protocol is probably just as important, utility-wise, as TELNET (VTP) 💖. Honestly, the stuff TELNET and RJE do is probably what most people on computer networks care about most 😭. For these users the net is a fast, cheap RJE stand-in, the same way TELNET is a phone stand-in for timesharing users 📞. The whole pile of protocols (and their layers) that give these services must be organized to efficiently support a wide variety of applications and user needs 🧩. And they should not put an undue software burden on the user, bestie 🫶.

The "official" NETRJE protocol for the ARPANET got an underwhelming response from users and servers alike 💀. I believe there are two basic reasons 🧐. First, implementing NETRJE takes a large commitment of resources 💸. Second, the protocol creates serious security problems 🚨.

Okay, so 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 🧠. Plus, once an RJE session is going, all three of these protocol implementations will be running for most of the session's life 😵‍💫. This could be a LOT for some systems 🥵. It might not be out of line to make a service carry that, but it is SO out of line to make a user take it on just to get a pretty basic service 🙅‍♀️. Most user installations are all about meeting their users' needs, not building huge piles of network software 💅. (Honestly, one of the better things about the earlier ARPANET protocol designs was that they tried to minimize the work for the user. (Ngl, it must be admitted that compassion for the user was not the reason for this approach 🙈.)

To support a "hot line printer" (aka a job gets auto-printed the second it's done 🖨️), the user must store their user code and password for the output host at the server host 😬. Obviously that's 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 getting victimized by every first year Computer Science student with access to the net 🫣💀.

The RJE protocol proposed here is trying to mitigate the implementation and security problems 🛡️. It's designed to give three levels of service 🎀. A user or server gets to pick whatever level their resources allow ✨. Then the service can be upgraded to cleaner or more sophisticated approaches when and if the opportunity comes up 🦋.

This protocol is described in ARPANET terms 🌐. A bunch of the design, like the reply structure, was made to match existing ARPANET conventions 📐. That makes it easier to understand, and it keeps the discussion on the protocol itself 🧚. Even though it's written in ARPANET terms, it should be applicable to other network environments 💜.

Real talk, this paper is not considered complete in every detail 🙈. It was mostly written to get comments from the network community and to see whether the community even wants to adopt such a procedure 🗳️. We described enough that you can get the vibe of how things are supposed to work, without drowning in the detail that implementation would need 🌊. Below is the outline, and anything with an asterisk is coming later 💅.

Part I THE NETRJE MODELS 🧚

This section is the narrative version of the NETRJE protocol 📖. The formal definition comes in Part II after review 🧐. The narrative should give the general reader the flavor without drowning them in unnecessary detail 🫶. NETRJE gives three different models for job submission and retrieval ✨:

1) RJE using Telnet only
2) RJE using Telnet and Data Transfer
3) RJE using FTP

This gives flexibility for implementors AND users 💖. 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 that best suits their 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 👑.) We'll go through each model in turn and show that each one can provide a useful network RJE function 🔥.

This protocol does not have the security difficulties of the present protocol 🔒. That's because the burden of implementing the "hot line printer" or "hot card reader" gets put on the user system 🧳. So systems that want that facility can still support it 🎀. The user implementation is slightly more complicated, but the trade-off is the increased security of the protocol ✨.

We're assuming end-to-end protocols are available 📡 and give the RJE protocol an ordered, error free bit stream 🧵. It's also assumed that a suitable virtual terminal protocol, like Telnet, is used to format the control connection 🖥️.

RJE Using Only Telnet (VTP) 📞

Bluntly, the goal of this model is an official "quick and dirty" version of the protocol ⚡. Lots of orgs, both users and servers, are stuck needing a service fast or on super tight budgets 💸, so this model is for them 🫶. With it, the user is required only to be able to establish a Telnet connection via the RJE contact socket 📞. Commands, replies, and data all go over that Telnet connection 🌊. Card input or printer output looks like it's 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, like the line printer 🧾. This technique was used with great success in the MARK I ANTS systems, where various devices weren't assigned socket numbers like they were in a TIP 🏆. It's also useful for hosts that only allow program access to the network through the user's Telnet connection 🔌. That 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 so the receiving host knows when to stop diverting the data 🛑. Honest truth: this model will have to handle data traveling on a connection that's basically meant for control 😵‍💫. Using this data transfer mechanism is an intermediate measure required by limited resources 🧃. For now, we'll let it stand that the designers are aware of the problems inherent in embedding commands or replies in the data stream 🙈. The exact resolution gets left to the formal definition ✨.

NETRJE uses a schedule verb, SCHED, for job submission 📅. For this model there are two relevant forms of SCHED 🧩. The first is SCHED <server pathname> 🗂️. This tells the server there's a file at the server site with all the job control info and data needed to define a job 📁. The server will then try to put the job in the job queue, and it will reply to the user with success or failure and possibly a job-id 🎫. You'll use that job-id later to ask about the job's status or grab its output 🔍.

When the job finishes, the server takes one of two actions 🏁:

a) if the user is still logged in, the server will send a reply notifying the user of their 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 other form of SCHED that's relevant to this model has this syntax 🧾:

   SCHED INPUT <CRLF><data><CRLF>.<CFLF>

This lets the user sit down at a terminal and type their own job control or possibly a program ⌨️. It also helps users whose local systems have a facility to transmit files with User TELNET, so they can send their user input job files this way 📤. The RJE Server would insert the job into the local job stream and return the proper indication of success or failure, along with identification of the job 🎉.

Just as SCHED gives several ways to submit a job, the OUTPUT command gives several options for retrieving output 📬. The form

   OUTPUT<job-id><server pathname>DISCARD

is sent to the server to start the output to the user's site, following the output specifications defined by previous OUTDEF commands (see below) 🚀. The optional DISCARD argument to the OUTPUT command indicates, if it's 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's retrieved using the OUTPUT command ⏳. This command will specify the parameters needed to transfer the output to the user, or to define what happens to the output 🧭. We realize that OUTDEF <job-id><server pathname> (which says the output is to be placed in a file described by the pathname) may be difficult for some systems to implement 🥺. Those systems would merely respond negatively, indicating they can't perform the function 🙅‍♀️.

A scenario is in order to illustrate the model 🎬. The user has logged in to Multics and is ready to submit an RJE job like this (XXX will denote the as yet unspecified reply code for the reply) 💻:

   SCHED MY-JOB>TREK

The system responds with a reply saying 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 💫 (to be continued!)

so the job should be sent on the TELNET connection 💖 and then the reply comes back like:

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 ready to receive the output 🫶

This whole exchange lets the user do output diversion at his local site if he needs to 🔀, and he gets to do it after he has confirmed the server is ready. Very responsible of him 💅

If the user didn't want to wait around and just logged off after getting the successful submission, no stress 😌 The next time he logs in, he can ask for the status of the job, or of all jobs under his usercode, and then go ahead and output any or all of them.

RJE with TELNET and Data Transfer ✨

The previous model was a minimal implementation for NETRJE. This one gives you better data transfer facilities without needing an FTP implementation 🎀 It needs no new commands, but it does handle connections differently, so the data is not required to flow on the command connection (see Fig. 2). Data goes over separate default connections (unless something else is specified), just like in the CCN NETRJS protocol. The difference is that for this protocol, the defaults are the same offsets from the control connection that FTP uses 🦋

The Server knows this model is in use when it gets either an INDEF command or a SCHED command with no arguments. The INDEF command lets the user point to a socket other than the default socket as the source of the input. Once the Server gets a SCHED or INDEF that signals this technique, it will try to connect to the right socket. If a SCHED command was sent, the user protocol interpreter can start sending cards as soon as the data connection is set up. (It is assumed that the user interface has already told the RJE protocol interpreter where the cards are coming from.) If the command was INDEF, the Server won't start reading until it receives the SCHED 🥺 Similarly, when the output is ready, the user sends either an OUTDEF or an OUTPUT command to set things up and start the printing. The INDEF and OUTDEF commands used with this mode can also move data to or from a TIP or printer 🖨️

This model needs actual data transfer formats defined for the reader and printer lines. We propose adopting the formats and connection schemes of the present FTP 🤝 That has the advantage of not requiring extra coding for users who already have FTP implementations. It also lets them organize their FTP and NETRJE implementations so they can take advantage of common algorithms. People might easily mistake this for a revival of the Data Transfer Protocol, so be warned 👀 Some thought on a more rigorous definition of a Data Transfer Protocol for the common use of FTP and RJE might be worth doing in the future 💜

Okay let's run a scenario 🎬

The user wants to submit a card deck to the Server. He types

SCHED<CRLF>

The Server opens a connection to the user's default card reader socket and, on the control connection, sends a reply to the user:

XXX attempting connection to card reader.

When the connection is opened, another reply comes in:

XXX transfer started

and when it's completed:

XXX JOB XA 1423 was successfully submitted.

When the job completes and the completion message is sent to the user, he may want to send the output to his TIP printer on socket Y. He types

OUTDEF XA1423 255, Y

(255 being his host address). The Server then tries to connect to the socket and replies

XXX printer connection successful.

Once the user is satisfied that everything is in readiness, he types

OUTPUT XA1423

and the Server starts sending and replies to the user

XXX print started.

When the transfer is complete, the Server closes the data connection and sends an appropriate reply ✅

NETRJE Using FTP 🦋

This model (illustrated in Fig. 3) uses FTP to move the files around. For some systems, this kind of model is easier for more sophisticated RJE setups 🧚 It's especially helpful if users want to take input from the local file system, or send output to the local file system, instead of an actual card reader or line printer. Using the local file system isn't prohibited by the Data Transfer model, but it may be easier to approach through FTP. Using FTP with NETRJE also lets you use the FTP server-server transfer mechanism to generate input from, or direct output to, a third host 🌈

The only new facilities this model needs are the commands INPATH and OUTPATH 🎀 When using FTP to send input to the Server, the user has to know where to send the job so that it enters the job stream. The INPATH command returns a legal pathname as its reply. So the scenario for job submission goes like this: the user sends an INPATH command, and the Server replies with a legal Server pathname for the user. The user process starts sending the input to that file using FTP. When the transfer is complete, the user sends a SCHED <server pathname> command. Once the job has finished, the pathname created for the user may or may not destroy the input file 🤷‍♀️ The OUTPATH command works in a similar way to identify the pathname for the output, so the output can be retrieved by FTP. Some systems may define file names so that the user can derive them from the parameters of their job 🧠

Note on Replies 🎀

In all of the examples above, we have held off on defining actual reply codes 🙈 The intent is to use the same reply structure, and where it makes sense 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 that let you evaluate both the protocol and its implementation 💅 These serve two functions: 1) they let the protocol designer evaluate the protocol and make improvements, and 2) they let the user of the protocol know how expensive it is and demand improvements. The proposed NETRJE protocol provides two sets of measures, one for a particular session and one for overall performance. You can get these measurements with the MEASURE command, which takes an argument with three possible values: JOB (job statistics and cost measurements), SESSION (measurements taken for this session), and GLOBAL (overall measurements of the performance of the protocol and its implementation). The command returns the measurements in a fixed format reply 📈

The measurements reported for a job are:

CPU time,
I/O operations,
storage space time product,
job cost in dollars,
elapsed time the job waited before being executed, and
elapsed time for the job to execute.

The measures taken from a session are:

number of bits transferred,
transmission rate of input or output transfers,
the amount of CPU time, storage space-time product, and I/O operations for the session.
cost in dollars and cents.

The measures to be taken globally are:

frequency of commands and possibly command forms,
model frequency (which submission/retrieval model used),
transmission mode frequency,
total number of sessions,
transmission rate: average, std. deviation, upper and lower bounds (also by transmission mode),
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 management and systems personnel have some indication of how the facility is being used.)

It's clear that some measures (like transmission rate) may be hard to get when NETRJE is using FTP 😬 That's unavoidable, since FTP is not metered. The most straightforward fix is also to meter FTP (hint 😉). For the final definition, a close look will be taken at the subset that should be required. Comments are welcome! We believe strongly that it's very important to know how a facility like this gets used, as well as how well it performs 💜

Part II. Preliminary Definition of NETRJE Commands 👑

heads up: this part is a very preliminary definition, meant for discussion only 🫣

For discussion purposes, this section gives a very preliminary definition of the NETRJE commands and their replies. The goal is a brief but not exhaustive definition of each command and its major replies, just to give the flavor of the protocol. We're not doing this to discourage nit-picking by critics (we may well overlook the obvious sometimes), but just to speed up writing 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 do the normal jobs of logging the user into the system. The replies to them are the standard ones in FTP. It was never clear why "account" wasn't included in the old NETRJE 🤔 Presumably, if it's necessary for an FTP or Telnet user, it'll be necessary for an RJE user too.

REINIT

This command reinitializes the state of the NETRJE server process so it's ready for a new user. If a transfer of data is in progress for the previous user, it's allowed to finish first ⏳

ABORT

This command is used to abort a data transfer. It only means something to the Server if the data is being transferred over the Telnet connection or the default data sockets. If FTP is being used, running this command is the responsibility of the USER NETRJE process 🛑

BYE

This command makes the Server log the user out and close the Telnet connection. If a data transfer is in progress, the command's action is delayed until the transfer is complete 👋

`SCHED <input part><output part>`

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 gets the input described by the <input part> entered into the RJE job stream, and the output produced gets disposed of according to the <output part> 🧃 A null condition for either argument means the information was already specified earlier or is the default.

For the <input part>, the <empty> can mean two things. If an INDEF command has already specified a <server pathname>, input to the job stream is taken from the file that name points to. If the INDEF command has specified that the input comes from a CCN-like data transfer socket, then SCHED <empty> is the signal for the Server to start reading data 📥

The DISCARD modifier, if it's there, means the file should be discarded after it's been transmitted, or after it's been received and executed 🗑️ If the input stream is going over the Telnet connection, the source can be a local device or a human user. This is for mini-hosts that can't use one of the other techniques, and for the user who wants to enter job control directly at their terminal ⌨️

The empty for output means either the primary output file of the job (the default), or a previously specified server pathname (set with the OUTDEF command) 📄

Successful replies to this command should indicate any job-id assigned by the local RJE system, along with other status information. Failure would happen because files didn't exist, access was denied, and so on ❌

`OUTPUT <output spec>`

OUTPUT <output spec>

<output spec>::= <job-id><xmsn part>|<job-id><server pathname>

<xmsn part>::= <empty>| /<IO params>

<IO params>::= <xmsn params>, <dest>

This command tells the Server what output is to be sent to the

user, how it's getting sent, and to whom 💌 The <IO params> part lets you pick a host and socket so the output can go to a TIP printer, or ride on the Telnet connection, or go to the default data sockets. This argument also decides the format and representation of the data. 🎀

When the Server gets this command, it'll go ahead and transmit the output to the host in the way you asked for. The reply structure depends on how the output gets moved, and we'll dig into that more later. ✨

INPATH

This command hands the user a legal pathname at the Server. The user can then transfer their input to that pathname for eventual submission to the RJE facility. 📥

OUTPATH

This one does a similar job to INPATH, just on the output side. 🦋

DISCARD

DISCARD   <job-file-id>  |  <server pathname>

This lets the user destroy input or output files associated with a job. Bye bye, files 🗑️💅

INDEF and OUTDEF

INDEF     <job-id><I/O params>

OUTDEF    <job-id><I/O params>

These commands let the user set the parameters needed to send input or retrieve output. This command specifies how the data will be transferred and specifies format, etc. Main character energy for your data's delivery plan 🚚🌸

CANCEL

CANCEL <job-id>

This command lets a job get cancelled from the RJE job stream. Sometimes you just have to let it go 🫶

STATUS

STATUS <status arg>

status arg ::= <empty>|<user id>|<job-id>|<job-id><blank><job-file-id>

This command lets the user check the status of the RJE session, all jobs under their usercode, a specific job, or the output of a specific job. Checking in is literally the whole vibe 👀💜

ALTER and SITE

ALTER <job-id><site specific option>

SITE <site specific option>

These commands pass site specific commands to the Server RJE system. ALTER is meant to affect specific jobs, while SITE is for commands with more global effect. They could be merged into one. Okay but why are they separate though 🤔🍓

OP

OP <operator message>

This command lets messages get sent to the operator at the Server site. Hi operator, we see you 🧚

Reply Codes for the Proposed NETRJE

The reply codes for this protocol follow the model proposed for the new FTP specification in RFC 640 🦋 As a reminder, here's the pertinent info 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, so 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.
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's honestly hard to pin down what "transient" means, especially 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 for telling 4yz apart from 5yz: 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 their 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 their 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 their 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 accounting 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.

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 should adapt codes already defined. Don't freestyle the codes, bestie 💅

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,

For 110, the text is exact and not left to the particular implementation; it must read:

   MARK yyyy = mmmm

Here yyyy is the user-process data stream marker, and mmmm is the 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
*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
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

      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
      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

      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
      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

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.

Figures

the reference list is complete, and it's been an absolute serve 🌈👑

okay bestie, the diagrams are where it all clicks 🎀✨ Figure 1 is the simplest setup: everything (RJE commands, replies, and data) rides one telnet connection 💖

   +-----------+
   !           !
   !  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.

Figure 2 gets a little more going on 🦋 Commands and replies still go over telnet, but the data moves through its own data transfer modules, which connect to the user's local file system and card readers or line printers on one side and the server's RJE system on the other 🌸

   +-----------+
   !  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.

Figure 3 is the FTP version 🧚 Same idea, but there's an extra FTP module on the user side and the server side, sitting alongside the RJE module on its own telnet connection. The data still moves through the data transfer modules, and the server side here is a file system rather than an RJE system 💜

   +-----------+
   !  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.

📦 where this page comes from

ietf: rfc725 1977-03
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms