1 files changed, 112 insertions, 0 deletions
diff --git a/doc/rfc/rfc368.txt b/doc/rfc/rfc368.txt
new file mode 100644
index 0000000..5ca7b94
--- /dev/null
+++ b/doc/rfc/rfc368.txt
@@ -0,0 +1,112 @@
+
+
+
+
+
+
+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]
+
+   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]
+