Browse Prior Art Database

Comments on "Proposed Remote Job Entry Protocol" (RFC0368)

IP.com Disclosure Number: IPCOM000003552D
Original Publication Date: 1972-Jul-21
Included in the Prior Art Database: 2000-Sep-13
Document File: 2 page(s) / 4K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R.T. Braden: AUTHOR

Abstract

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.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 80% of the total text.

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