RFC 368 UNKNOWN PROTOCOLS · FEEDBACK

RJE Feedback: Comments on "Proposed Remote Job Entry Protocol"

Technical comments on the proposed Remote Job Entry protocol.

On rfc-editor.org ↗
PUBLISHED
July 1972
AUTHORS
R.T. Braden
STREAM
Legacy
PUBLICATION
July 21, 1972
TYPICAL JOB OUTPUT
about 30 pages
DOI
10.17487/RFC0368

RFC text

Original text · RFC Editor View on rfc-editor.org ↗
Network Working Group                                      R.T. Braden
Request for Comments #368                                  UCLA/CCN
NIC 11015                                                  July 21, 1972
Categories:
Obsoletes:
Updates:

                              COMMENTS ON
                  "PROPOSED REMOTE JOB ENTRY PROTOCOL"

    Chuck Holland's draft proposal (RFC #360) is an excellent
document, very complete and consistent.  Since the final standard RJE
protocol will be widely used on the Network, honing its definition now
will save trouble and discontent later.  Therefore, I will proceed to
make a new suggestions and pick a few nits.

   1.  In my humble opinion, the  command  verb  "BYE"  is  overly
       cute; I would find "QUIT" much less offensive

   2.  The "(pathname)" syntax (p.5) may need some reworking.
       It would be very desirable for all protocols or Network
       access programs to use the same syntax for selecting a
       host and socket and/or file name.  (Note that the FTP
       documents use the term "pathname" in the more
       restricted sense of a local file system name.)

       a.  The PORT construction seems very undesirable,
           since it depends upon a particular bit convention
           of TIP's.  TIP's have bent Network protocols rather
           badly in the past, but surely we don't want to build
           their particular socket system into an official
           protocol.

       b.  For convenience, it may be desirable to allow hex
           and octal socket numbers.

       c.  There will probably be other hosts besides TIP's which
           will use the "(host-socket)" pathname, and some of
           them may want a transmission attribute other than "T".
           The proposed syntax should be changed to allow (attributes)
           in (host-socket)

       d.  I see no reason to exclude attribute "TE", since the control
           characters cr, lf, and ff exist in EBCDIC as well as ASCII.

       e.  There are many EBCDIC codes, and at least 2 ASCII's.  The
           (code) construction needs expansion.

   3.  The syntax of OUT might reflect the fact that pathname is
       required only for (disp) of "(S)".

   4.  It may be desirable to distinguish syntactically (job-id)
       and job-file-id).  For example, this would allow the command

            ABORT (job-file-id)

       to abort the job currently being transmitted, regardless of
       its id (this assumes that multiple jobs for a given user
       are sent sequentially).

   5.  The replies presented in the document are very good, but may
       need some elaboration.  For example, the syntax error messages
       should be more specific.  When the user enters:

            OUT=(H) UCLA91: NE/ARP998.WGW.TEST

       he would like the error message to indicate explicitly that
       the hostname is not valid, rather than merely being told there
       is something wrong with one of the parameters.

   6.  Experience with remote job entry to CCN via the Network has
       shown that the user wants a transmission status command, to
       find out how many records have been sent or received so far.
       The network bandwidth corresponds in order of magnitude to
       one page per second.  The average output for jobs submitted
       to CCN from the Network has contained about 30 pages, so
       significant transmission delays are not unusual.  It is important
       to add a command for this purpose.


         [ This RFC was put into machine readable form for entry ]
         [ into the online RFC archives by BBN Corp. under the   ]
         [ direction of Alex McKenzie.                      1/97 ]

AI ELI5

On this page
PROBLEMChuck Holland proposed a Remote Job Entry protocol for running jobs remotely on the ARPANET, but like any new specification, it had room for improvement and consistency.
MECHANISMR.T. Braden from UCLA reviewed the proposal and offered specific suggestions on syntax, error messages, command names and new features such as a transmission status command.
PROTOCOL IMPROVEMENTThe feedback helped refine the protocol before it became a network standard.

§1Introduction

RFC 368 is a set of comments by R.T. Braden from UCLA on Chuck Holland's proposed Remote Job Entry protocol in RFC 360. Braden calls the proposal excellent and complete, then offers detailed suggestions to improve it before it becomes a network standard.

Someone read a draft of new rules for sending computer jobs over the network and wrote back with ideas to make them better.

§2Detailed Suggestions

Braden suggests several improvements: using the command word QUIT instead of BYE for clarity; making the pathname syntax consistent across all network protocols; allowing hexadecimal and octal socket numbers in addition to decimal; extending the syntax to support transmission attributes like TE for EBCDIC; and expanding the code construction to handle multiple varieties of ASCII and EBCDIC.

He also points out that the PORT construction is problematic because it depends on TIP-specific bit conventions, and argues that protocols should not embed hardware-specific details.

The feedback suggests clearer command names, consistent ways to write addresses, support for different character codes, and avoiding design choices that only work on one type of machine.

§3Operational Experience

Braden adds practical observations from running remote jobs at CCN via the ARPANET. He notes that users need a transmission status command to check progress on large jobs, since network bandwidth was limited and the average output job from the network contained about 30 pages, leading to significant delays. He also suggests more specific syntax error messages to help users diagnose what went wrong.

From experience with real network jobs, people need to check how much data has been sent or received while waiting for a big job to finish.

§4References