RFC 520

RFC 520: A Proposed File Access Protocol Specification 🎀

Title block, the tea ☕💖

• Network Working Group 🌸 is the group this is from.
• Author: J. Day, of the Center for Advanced Computation 👑
• Request for Comments: 520
• NIC: 16819
• Date: 25 June 1973 📅
• Category or status: the original doesn't say
• Obsoletes and updates: the original doesn't list any

---

Cover Note 💌

okay so John Day is sliding into the network mail with a whole proposal, and it's giving collaborative 🫶 Attached is a proposal for the File Access Protocol, aka FAP. FAP is an extension to FTP. He thinks the spec is pretty general and a good jumping-off place 🦋 He's hoping it fits the idiosyncrasies of most systems, so if it would be an inordinate burden on yours, he really wants to hear about it 💅

He also wants several levels of implementation specified later, once everyone knows how hard it is to actually build this 🧚

Next, rumors say FAP will allow creating and transferring what TENEX calls "holey" files. But he's not sure of all the implications 🙈 Like, what happens (or should happen) when a "holey" file gets moved to a site that doesn't really have that concept? He's begging the TENEX crowd for comments 🥹

He also thinks FAP could be made easier for record oriented systems. That would probably need an extra command or parameter to say all operations are in terms of records. Comments invited 💜

In the long run though, he's kind of hoping FAP gets thrown away 😭 The commands just add a finer structure to the present RETR, STOR, and APPE without much extra overhead. This sequence:

OPEN R FOO.BAR CRLF
      READ ALL CRLF
      CLOS CRLF

is equivalent to RETR FOO.BAR CRLF. So FAP could be merged with FTP into one richer, more coherent whole ✨

Also, while writing this, he ran into how bad reply codes for protocols are. Three digits is nowhere near enough 💀 As an interim fix, he suggests a five digit reply, with two digits for specific categories (like Primary access, FTP results, etc.) and two digits for specific results. Meanwhile, the NWG should start thinking about a general reply code scheme that doesn't need revising every two years 🔥

Comments, complaints, etc. are welcome. He can be reached through network mail at ISI (DAY) or Multics (DAY Cnet), or by phone at the University of Illinois, (217) 333-6544 📞

---

Title Page 📄

                                 A
                              Proposed
                        File Access Protocol
                            Specification

                              John Day

                               6/7/73

I. INTRODUCTION 🦋

so the whole point of the File Access Protocol is giving processes a way to access non-local files, either sequentially or non-sequentially 🧚 Unlike the proposed Mail Protocol, FAP is an extension of FTP and not a subsystem. Overall, FAP is compatible with the rest of FTP. Any modifications that are needed are specified below 💅

The big idea is letting processes tell the remote file system where in the file they want the next operation to start and how much data to move 👑 So only the part of a file a process needs for its computation has to be transferred, instead of the whole thing. That keeps transmission times and storage requirements held down. Honestly, the reasoning behind a File Access Protocol on the network is the same reasoning behind "random-accessed" files in a standard operating system 🥹

FAP uses the connection model, data representations, and transmission methods of FTP. All data transmissions in FAP are handled according to the description in FTP Section III.C, with these changes:

• In Stream mode, the minimum byte size goes up to 4 bits.
• Another control code, value 4, is used to mean "end of transmission". A combination of EOT, EOR, or EOF can be indicated by the proper control code.
• Because of this, you don't have to close the connection after each access. (That's a practice that's not highly recommended, btw 🙈)
• In Block mode, bit 5 of the descriptor field of the header is set to note that this block is the end of transmission.

FAP also uses a File Pointer (FP) 🎀 The file pointer points into the file and marks where the next FAP read or write will start. It's a general mechanism for addressing a file, and it should be flexible enough to handle both stream and record oriented systems ✨

II. PROBLEMS OF IMPLEMENTATION 🔧

Okay, real talk: as usual, not every system is going to be able to implement this protocol in its full generality 😭 The rule here is that no host should be required to provide network users with a service it doesn't provide its local users, just so the protocol is "complete" 🫶

Some systems allow "random" access to some kinds of files but not others. In that case, the implementation should just match that. Not all operations are valid for all kinds of files 🌈

Some systems can't move the byte pointer backwards without opening and closing the file. They don't have to do this (although they can if they want to 💖). But they should allow "spacing" down a file some distance before starting a transfer 🧚

Some systems may not allow read and write access without closing and reopening the file. Those systems should not be required to do both 💅

In general, the rules of implementation are:

1. If a system normally allows that particular kind of access to that particular file, then it should be allowed. If not, the system should not be forced to implement it. (In many cases, the legality can't be known until the operation is attempted. In other words, you can't tell from the first two cases above whether they're legal when the file is opened, only on the read or write that violates the implementation restrictions 🙈)
2. A system should not try to simulate a facility if the simulation has side effects. For example, if simulating the ability to move the byte pointer to the desired position has side effects, then the simulation should be left to the process accessing the file 👑
3. All implementors should make known the capabilities of their implementations via NIC documents 📚

III.2.4 READ <arg> 📖✨

Okay so, READ is the command that tells the server to send bytes from the file over to the user, bestie. 💌 The number of bytes is in the size of the logical byte size, and it's giving precision. 💅 The argument can be a <decimal number> or ALL. ALL means everything from wherever the file pointer currently is all the way to the end-of-file. 🌊

Now here's where it gets spicy. 🌶️ If you ask for more bytes than the file actually has, the server should send you the bytes from the current position up to the end-of-file, and then reply with EOF: <byte number> so you know exactly where the end is. 🥺 If the file is Record structured and your READ asks for more than what's left in the record, you get the bytes in that record from the file pointer, and then the server sends EOR: <byte number> to mark the end of the record. 🧾✨

After a READ, the file pointer is updated: it moves forward by however many bytes were actually moved. 📍 The EOF condition is the one exception, and it leaves the pointer at E. 🫶

Replies 🎀

258      480
402      481
450      482
452      500-507
455

---

III.2.5 WRITe <arg> 🌸

WRITe is the vibe where the server accepts as many bytes as you specify from the user. 🙌 The result updates the value of the file pointer, so the pointer always keeps up. 📍 The argument can be a <decimal number> or ALL, and ALL means all data from the present position of the byte pointer to the end-of-file (or beyond, bestie 👀).

Here's the best part: a write comes with an implied "append" 💖. That only happens if any previous information has already been sent (like allocation), and if the file's access privilege allows it. 🔐 Now, if your write asks for more bytes than fit between the file pointer and the end-of-file, and expansion isn't allowed, nothing gets sent and the file pointer doesn't move at all. 🙅‍♀️ The server then returns an error that tells you the byte position of the EOF. 💀

If the file is Record structured and a WRIT tries to move more bytes than the record holds, the file pointer stays put and the server sends back EOR: <byte number> to note the end of record. 🧚

Replies 💜

258      480
402      481
450      482
452      500-507
453

---

III.2.6 CLOS 🦋

CLOS instructs the server to "close" the file that's currently open, if there is one. 🚪 Getting a CLOS when nothing is open is totally fine, it's not an error at all, no cap. 🙅‍♀️ What it does is basically tell the server, "hey, stop sending my operations to that file." 🛑

Also, if the server gets an OPEN while it already has a file open, it should close the open file and then open the new one. 🔄 That's the server being a good multitasker. 👑

Reply 🍓

258

---

IV. SUMMARY ⭐

IV.1 SYNTAX 💻

Here's the whole command lineup in one place, so you can screenshot it and save it forever. 📸

   OPEN <direction> <pathname> CRLF
   CLOS CRLF
   SETP <byte pointer arg> CRLF
   GETP CRLF
   READ <transfer argument> CRLF
   WRIT <transfer argument> CRLF

   <direction>::= R|W|B

   <byte pointer argument>::= B|E|<decimal number>

   <transfer argument>::=ALL|<decimal number>

   <byte number>::= <decimal number>

IV.2 REPLIES USED BY FAP 🎀

This is the full reply cheat sheet, and honestly it's iconic. 🤩 Every code and what it means, all in one spot.

   258    Operation successful
   402    Command not implemented for requested value or action
   433    Cannot transfer files w/o valid account. Enter account &
          resend command.
   450    FTP: file not found
   451    FTP: file access denied
   452    FTP: file transfer incomplete, data connection closed.
   453    FTP: file transfer incomplete, insufficient storage space.
   454    FTP: cannot connect to your data socket
   455    FTP: file system error not covered by other reply codes.
   457    FTP: transfer parameters in error.
   480    EOR: <byte number>
   481    EOF: <byte number>
   482    File not open for operation
   483    FP: <byte pointer>
   500    Last command line completely unrecognized.
   501    Syntax of last command is incorrect.
   502    Last command invalid (ignored), illegal parameter combination.
   504    Last command invalid, action not possible at this time.
   505    Last command conflicts illegally with previous command(s).
   506    Last command not implemented by the server.
   507    Catchall error reply.
   550    Bad pathname specification (e.g., syntax error).

---

         [ This RFC was put into machine readable form for entry ]
               [ into the online RFC archives by Via Genie ]