The RFC Archive
 The RFC Archive   RFC 368   « Jump to any RFC number directly 
 RFC Home
Full RFC Index
Recent RFCs
RFC Standards
Best Current Practice
RFC Errata
1 April RFC



IETF RFC 368

Comments on 'Proposed Remote Job Entry Protocol'

Last modified on Wednesday, March 5th, 1997

Permanent link to RFC 368
Search GitHub Wiki for RFC 368
Show other RFCs mentioning RFC 368







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.




                                                             PAGE 1 top


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 ] PAGE 2 top

Comments on 'Proposed Remote Job Entry Protocol' RFC TOTAL SIZE: 3883 bytes PUBLICATION DATE: Wednesday, March 5th, 1997 LEGAL RIGHTS: The IETF Trust (see BCP 78)


RFC-ARCHIVE.ORG

© RFC 368: The IETF Trust, Wednesday, March 5th, 1997
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement