diff options
Diffstat (limited to 'doc/rfc/rfc141.txt')
-rw-r--r-- | doc/rfc/rfc141.txt | 115 |
1 files changed, 115 insertions, 0 deletions
diff --git a/doc/rfc/rfc141.txt b/doc/rfc/rfc141.txt new file mode 100644 index 0000000..eae4071 --- /dev/null +++ b/doc/rfc/rfc141.txt @@ -0,0 +1,115 @@ + + + + + + +Network Working Group E. F. Harslem +Request for Comments: 141 J. F. Haefner +NIC 6726 Rand + 29 April 1971 + + COMMENTS ON RFC 141 (A FILE TRANSFER PROTOCOL) + + 1. A file transfer protocol is needed. Bushan's proposal would + satisfy a particular current need that we have, as well as short-term + envisioned needs. + + 2. Bushan's protocol would apear to be straight-forward in + implementation, and extensible as claimed. + + 3. We would like to see implementations of such protocol be + accomplished such that the file transfer program has general and + complete access to the local file storage. That is, it should be + able to access a file that it did not create. For example, if a + program or user creates a file at site X (completely independent of + the file transfer program), it would then be desirable to be able to + retrieve the file via the file transfer program. This is not a + requirement of RFC #114 but we would like to see it implemented where + possible. + + 4. Since implementation of a subset of transaction types is + specifically permitted, we suggest inclusion of the following + commands (in addition to append). + + insert records within a file + delete records from within a file + replace records within a file + + Although these operations are not directly supported under IBM + OS/360, we have used them with a non-standard file subsystem under + IBM OS/360 and find them quite useful. + + 5. In addition to retrieve and lookup, get names of files under my + access control would be useful. + + 6. The absence of status requests and responses is apparent. + Although this is typically a function associated with a remote job + entry (RJE) system, since the execute request is present it would + seem appropriate to inquire about the status of the process created + by the execute command. This becomes increasingly more important + where the execute is implemented as an RJE-like operation and + scheduling time of the job might be prolonged. + + + + + +Harslem & Haefner [Page 1] + +RFC 141 Comments on RFC 141 April 1971 + + + 7. When requesting execute, the using host sends parameters upon + receipt of the rr response. Executing a task can be implemented in + several ways. The options our 360 affords are RJE at job level and + the attach macro. Our preference would be the attach macro which + immediately initiates an independent OS task within the partition of + the program issuing the attach (presumably the File Service). Such a + task normally receives parameters upon initiation and can thereafter + receive parameters from a program via some mechanism such as an event + control block. The second method requires special modifications to + the program being executed; hence, it is not desirable. Therefore, + we either need the parameters included in the execute command or will + not actually start execution until parameters are received. + + 8. Upon abnormal termination, one should include part or all of the + spurious request as well as an identify- ing code to facilitate + precise error recognition. + + 9. We would be interested in the outcome of the MIT/ Harvard + experiments with the RFC #114 protocol. What were the pitfalls, + etc.? + + + + [ This RFC was put into machine readable form for entry ] + [ into the online RFC archives by Simone Demmel 4/97 ] + + + + + + + + + + + + + + + + + + + + + + + + + + +Harslem & Haefner [Page 2] + |