RFC 368

Comments on "Proposed Remote Job Entry Protocol"

πŸ“… published July 1972, from ietf

COMMENTS ON "PROPOSED REMOTE JOB ENTRY PROTOCOL" ✨

Okay so this one is from the Network Working Group 🧚 It's Request for Comments #368 (also NIC 11015) by R.T. Braden of UCLA/CCN, dated July 21, 1972. The Categories, Obsoletes, and Updates fields are all blank 🫢

Chuck Holland's draft proposal, RFC #360, is an excellent document 😭 It's super complete and consistent. Since the final standard RJE protocol is gonna get used all over the Network, polishing it now saves trouble and drama later πŸ’… So I've got a few new suggestions and some nits to pick πŸŽ€

  1. The command verb BYE is kinda overly cute πŸ™ˆ I would way rather see QUIT, ngl.
  2. The (pathname) syntax (p.5) might need some reworking πŸ¦‹ It would be super 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 feels very undesirable πŸ’€ since it depends on a particular bit convention of TIP's. TIP's have bent Network protocols rather badly in the past, and 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 using 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).

  1. The replies 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. Main character energy for the error messages, honestly πŸ’…

  1. 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 ] 🌸

πŸ“¦ where this page comes from