RFC 535

Comments on File Access Protocol

📅 published July 1973, from ietf

RFC 535: Comments on File Access Protocol 🦋

okay bestie, this one is by B. Thomas of BBN-TENEX, dropped in July 1973 (NIC 17454) 💖 It's filed under Protocols and FTP, and it's basically a list of glow-up suggestions for John Day's file access protocol (FAP) from RFC 520 💅 It doesn't obsolete or update anything. It just wants FAP to be as good as local file access 🌸

1. Philosophical comment ✨

okay so the big idea here is that FTP and FAP both want to let a user work with files remotely 🧚 FTP basically takes the stuff you'd normally do at the command line and "slaves" it across the network to the site where the file lives. FAP does the same thing, but for the stuff programs normally do at the operating system or monitor level 🔥 The OPEN, CLOS, SETP, and so on commands in FAP are like attempts at "generic" file system monitor calls 💜 The suggestions below are more ways to make the features local users already have available to remote users through FAP. it's giving consistency, periodt 💅

2. The OPEN command should allow for a third OPEN mode called A for append. ✨

so bestie, FAP's OPEN command should get a third mode, A, for append 🎀 Here's what it would mean for a file and its file pointer:

OPEN A FOO

that would be the same as doing this:

OPEN W FOO
SETP E

the difference is in access control 🔒 A lot of systems let you control write and append access separately. on TENEX, for example, you usually set your MESSAGE.TXT so anyone can append to it but only you can write it 💌 So the append OPEN would work in lots of cases where the write OPEN would fail 😭 The principle is that FAP should (as much as is practical) let remote users access files the same way local users can 🫶

3. Holey files need a way to be found ✨

okay so the protocol lets you make non-sequential files, but once they exist there's no easy way to access them remotely 💀 Imagine sending this to a TENEX server:

OPEN W FOO     //byte size assumed = 36
SETP B
WRITE 512
SETP 1024
WRITE 512
CLOS

that makes a file FOO with two pages (on TENEX, a page = 512 36 bit words) 🍓 They'd be page #0 and page #2, because page #1 doesn't exist, so the file has a "hole" in it 🕳️ Accessing FOO over FAP would be rough unless the remote user already knew its page structure 😩 So FAP needs a way for a user to figure out a file's structure 🔍 I'm thinking a value-returning command that gives back the value the file pointer should be set to in order to point at the first byte of the next used page (block or record) past the current position. call it FNUB (Find Next Used Block) ✨ With that, you could read a holey file like FOO like this:

OPEN R FILE
SETP B
a:      FNUB               //let x=the value returned
        if x=null
           then CLOS
           else ( SETP x
                  READ 512   //page size=512
                  goto a )

ngl this part assumes the remote user knows the block (page) size so they can access the file properly 🙈 Blocks could also be variable size, so maybe FNUB should return two values: the file pointer position of the next block, and that block's size in bytes 🌈

4. Remote users need file status and descriptor info ✨

FAP should let a remote user get certain status and "descriptor" info about a file 📋 This list isn't complete, but these are the things that'd be useful for remote TENEX files:

  • user's access to file: can they read, write, execute, or append the file?
  • size information: byte size used in the last write access (OPEN W) of the file, and file size in bytes (of that size).
  • file access dates: date of create, last read, and last write.
  • on TENEX, a user can set different access control for different pages in the same file 🔐 A remote user should be able to get that access control info about files, and also set it when they create them 👑

5. Multiple file access with handles 🧚

okay this is a big one. there are lots of times a remote user would want to access several files at once, just like a local user can, but FAP as proposed can't do that 😭 (sure, you can always go through an ICP to set up another connection to the server, but ugh 🙄) The fix is simple: add a "file handle" so each FAP command says which file it's talking about 💖 When the user does:

OPEN R FOO

the server's response includes a handle for FOO, and the user uses that handle for every later reference to FOO 🎀 The handle is a string the server picks. it could be the file's name (FOO), a small integer, etc. Using a server-picked handle instead of the full file name means the server doesn't have to re-parse the file name for every command ⚡ For example, this sequence opens one file for reading and one for writing, reads 3 bytes from the first file, computes with that data, and writes a 2 byte result to the second file:

OPEN R FOO   //server returns FH as handle
OPEN W MOO   //server returns MH as handle
READ 3 FH    //user reads data
//User does some computation on the 3 bytes
WRIT 2  MH   //user writes the result
CLOS MH
CLOS FH

reasonable defaults could help with handles too 🌸 for example, a FAP command with no handle refers to the same file as the previous command. The association between a handle and a file is probably better handled with its own FAP command than as a side effect of OPEN, like this:

HNDL FOO

6. Local transformations, but also the option to skip them 🦋

it matters to account for local transformations (see page 3 of RFC 520) 💅 but it's just as important to let a remote user turn them off if they want, so they can access the file exactly as it's stored 🫶 That way, a program that works on a file can work the same whether the file is local (accessed "directly" through system calls) or remote (accessed "indirectly" through system calls that get "trapped" and turned into FAP commands sent to the remote site) 🌈

[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Alex McKenzie with    ]
[ support from GTE, formerly BBN Corp.            10/99 ]
📦 where this page comes from