RFC 269

Some Experience with File Transfer ✨

• Network Working Group: RFC #269 🎀
• Author: H. Brodie, UCLA-NMC (NIC #7817) 🦋
• Date: 6 December 71 🍓
• Category: File Transfer 💅
• Updates: 122, 238, 172 💖
• Obsoletes: None 🫶

Okay so bestie, UCLA-NMC just finished building a program that uses UCSB's storage through their Simple Minded File System (SMFS). Jim White's RFC #122 explains SMFS if you want the full tea. ☕ How the program works is in Appendix A. 🌸

We learned a LOT while building it and using it, and we think a bunch of it applies to a network-wide File Transfer Protocol. We're hoping this sparks more discussion 💜. Some things in the UCSB protocol deserve a spot in the network-wide one, and some things in the proposed net protocol are sadly missing from UCSB's version. 😭

The Retrieval Glow-Up 🔥

First, the UCSB file retrieval procedure is so good. The user picks a bit count for how many bits to grab in each request. ✨

Each RTF command gives you the next piece of the file, and SPF lets you skip over parts you don't want. Being able to choose the size of each chunk, and jump straight to any part without downloading the whole file, is literally an advantage. 💅 It also makes user programs way easier to write, because you always know exactly what's coming, so parsing the input stream basically disappears. 🧚

Then there's the one request, one response vibe. You never end up sending a request and then getting random pieces of data at random times. Every RTF gets a response that basically says "they're still listening" 🥹, and we think there's a ton to gain from a one request, one response protocol. 👑

Is this slow for big transfers? Nope, not really! SMFS uses a "defaulting" approach, which lets the request messages stay super tiny. 🌈

We also found the mandatory password system at UCSB super easy to use. In our opinion, any server site that advertises file storage can reasonably be expected to require passwords too (see also R. Braden's RFC #238). 🔐

The Missing Piece: "What Files Do I Have?" 🙈

Almost immediately after we started using SMFS, we hit a serious gap. There's no way to ask "what files do I have there?" 💀 The author honestly suspects there are already several files up there he's totally "forgotten" about! 😭

It's reasonable, maybe even necessary, for any server to send back a nicely formatted character string describing the files stored there for that password, user, or whatever division is used. The listing should also include other useful info like date created, size, etc. 📋

Meanwhile UCSB is giving the SEX system valuable "out-of-line on-line" storage 🫧, and we're really looking forward to a widely accepted file transfer protocol running on lots of server sites, hopefully with cheap bulk storage. 🌟

Appendix A: FXFER 🧚

FXFER is a re-entrant program written in Symbol. It's used to send a receive file from UCSB via their Simple Minded File System. For the network interface to SMFS, check RFC #122 by Jim White. 🦋

Files are stored in a paged format, identical to the paged format the tape process uses. Each file looks like this:

<header><data page><data page>...

So a file that Master lists as having n pages takes up 2048 n bytes at UCSB. 💾 The user's sign-on initials serve as both the access and modification passwords. That means if a file is sent under one user's sign-on, only that user can retrieve or delete it. 🔒

Commands 💅

PA - Increments "print All" counter.  Different settings of this
     counter yield different levels of program trace output on
     the console.

NP - No print.  This sets the "Print All" counter to zero.

DF FOO - This deletes the file "FOO" located at UCSB.

PF FOO - This sends the file "FOO", pointed to by the user's root
         directory, to UCSB.  Only read access is needed to "FOO".

GF FOO - The file "FOO" located at UCSB is retrieved and put in the
         user's root (with write access).  Note that it must have been
         sent by the user to have the right password.

RN FOO BAR - Rename the file "FOO" at UCSB to "BAR".  The same password
             restrictions as with PF and GF apply.  (Not yet implemented)

ST - Status.  Tells what program is doing and how much its done.

X - Exit Program.

⏰ If the system and/or UCSB is particularly slow, UCSBFIL may type a time-out message. At that point you can keep going or exit the program. The message explains itself, and so do most of the program's other messages. 🙃

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Nick Christenson 10/97]