RFC 141

Comments on RFC 141 (A File Transfer Protocol) 🎀

okay bestie, this is the RFC 141 comments doc 💅 written by E. F. Harslem and J. F. Haefner from Rand, dated 29 April 1971, filed as NIC 6726 in the Network Working Group series. the header doesn't list a category, and it doesn't obsolete or update anything. so this is basically a group of smart people giving feedback on Bushan's file transfer proposal 🦋

1. okay so first things first: a file transfer protocol is needed 😭 Bushan's proposal would cover a specific thing we already need, plus the stuff we're expecting to need soon 🔥
2. Bushan's protocol would appear to be straight-forward to implement 🧚 and extensible, just like they claimed. iconic 👑
3. we'd love implementations where the file transfer program has general and complete access to the local file storage 🌸 so it can access a file it did not create. like, if a program or user makes a file at site X totally independently of the file transfer program, we'd want to be able to retrieve it through the file transfer program 🫶. this isn't a requirement of RFC #114, but we'd like to see it implemented where possible ✨
4. since implementing a subset of transaction types is specifically permitted 💅, we suggest including the following commands (in addition to append):

insert records     within a file
delete records     from within a file
replace records    within a file

okay so these operations aren't directly supported under IBM OS/360, but we've used them with a non-standard file subsystem under IBM OS/360 and they're quite useful 🍓

5. on top of retrieve and lookup, getting names of files under my access control would be super useful 🗂️
6. the lack of status requests and responses is kinda glaring 🙈. this is usually a remote job entry (RJE) thing, but since the execute request is there, it seems right to ask about the status of the process created by the execute command. it gets more important when execute works like an RJE-like operation and scheduling the job might take a while ⏳
7. when requesting execute, the using host sends parameters upon receipt of the rr response 📦. there are a few ways to run a task. the options on our 360 are RJE at job level and the attach macro. we prefer the attach macro 🧚 because it immediately starts an independent OS task within the partition of the program issuing the attach (presumably the File Service). that task normally gets its parameters at initiation and can receive more from a program afterward through something like an event control block. the second method needs special modifications to the program being executed, so it's a no-go 💀. so we either need the parameters included in the execute command, or we won't actually start execution until the parameters arrive 🎀
8. when there's an abnormal termination, one should include part or all of the spurious request, along with an identifying code so errors can be recognized precisely 🔍
9. we'd be interested in the outcome of the MIT/Harvard experiments with the RFC #114 protocol 🌈. what were the pitfalls, etc.? spill the tea 🫖

[ This RFC was put into machine readable form for entry into the online RFC archives by Simone Demmel 4/97 ]