home *** CD-ROM | disk | FTP | other *** search
-
-
-
-
-
-
- Network Working Group 29 April 1971
- Request for Comments: 141 E. F. Harslem - Rand
- NIC 6726 J. F. Haefner - Rand
-
-
- COMMENTS ON RFC #114 (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 pro- gram 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
- trans- fer 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.
-
- 7. When requesting execute, the using host sends parameters upon
- receipt of the rr response. Executing a task can be implemented in
-
-
-
- [Page 1]
-
- 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 ]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- [Page 2]
-
-