RFC 141 (rfc141) - Page 1 of 2
Comments on RFC 114: A File Transfer Protocol
Alternative Format: Original Text Document
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