RFC 438

RFC 438: FTP Server-Server Interaction 🎀

okay bestie, this one is by B. Thomas and B. Clements at BBN-TENEX (NIC 13770), dated 15 January 1973 💅 It's an RFC (a "Request for Comments," the docs that define how Internet protocols work). The header's References line is 354,385,414,418, and the text says the ARPANET File Transfer Protocol is specified by RFC 354 and updated by RFC's 385, 414 and 418 ✨ The header doesn't list a category, status, or anything it obsoletes, so I won't make any of that up 🙈

Intro 🌸

The current ARPANET File Transfer Protocol (FTP), as specified by RFC 354 and updated by RFC's 385, 414 and 418, allows for "third host" participation, but it doesn't say how the process at the third site can be the FTP server at that site 😭 This RFC suggests a simple FTP extension so an FTP user process at one site can get FTP server processes at other sites to work together for it 🫶

Server-server cooperation might sound kinda niche, but ngl it's giving main character energy once you see why it matters. Think about what a Resource Sharing Executive (RSEXEC) needs from FTP. An RSEXEC is a command language interpreter that stretches a user's commands past the edge of their local system 🧚 Among other services, it could give users a network-wide file system, maybe even letting them use partially qualified pathnames that leave out the site specification 🦋

The APPEND Example 💖

Say the RSEXEC gets this user command:

APPEND (FILE) PROG1.PL1 (TO FILE) PROG2.PL1

The two files are at different sites (PROG1.PL1 at SITE1, PROG2.PL1 at SITE2), and neither one is the user's site. The straightforward way for the RSEXEC to "perform" the APPEND is to open FTP control connections to the FTP servers at SITE1 and SITE2. Then it tells the SITE1 server to run:

RETR PROG1.PL1

using data connection C, and tells the SITE2 server to run:

APPE PROG2.PL1

using that same data connection C 🔥

Here's the problem, though 😩 right now there's no way inside FTP to set up that kind of server-server cooperation. The main reason is that FTP treats the two ends of a data connection asymmetrically during connection setup. One end is the "server" end, the other is the "user" end, and each end has its own way of establishing the connection 💅

Two Ways to Fix It 🎀

FTP could be changed to support server-server interaction by:

1. making the establishment of data connections symmetric, or;
2. providing a mechanism for instructing a server to establish its end of a data connection as if it were a user.

The second option probably needs fewer changes to the existing protocol, so that's the one this RFC goes with ✨

The Proposed Extension 🦋

The extension uses the second method. It adds one new command (LSTN) and makes small changes to several existing commands (SOCK, APPE, RETR, STOR) 🌈

a. LSTN (Listen). The LSTN command asks the FTP server to allocate a socket for use as a data connection. To set up the matching data connection, the server listens on the socket it allocated when an appropriate transfer command comes in 👑

LSTN <direction> CRLF

where <direction> is either "S" for send or "R" for receive.

The server replies to LSTN in one of two ways:

1. it refuses to allocate such a socket, or;
2. it sends the user the number of the socket it allocated (the 255 FTP server data socket reply could be used for this purpose).

b. Listening after a transfer command. When an appropriate STOR, RETR or APPE command shows up after a successful LSTN command, the server "listens" for an RFC for the allocated socket. Data transfer can go ahead once the server receives an RFC for the socket and answers with a matching RFC. Once it's established, a data connection that came from a successful LSTN command lasts exactly as long as one set up the usual way 💜

c. Keeping transfers secure. The user can keep their data transfer secure by using the SOCK command to tell the server to accept an RFC for the listening socket only if it comes from a specified host and socket 🔒

d. Changes to the SOCK command. The SOCK command gets two changes:

1. On success, the reply must be the 255 FTP server data socket reply. In other words, the 255 reply can't be held back until a data transfer command arrives. (This lets the user pass the server's response along to the program at the third site. See the example below 🧚)
2. After a LSTN command, the server reads the SOCK command as specifying which RFC is acceptable for the later data transfer command that uses the allocated socket 🫶

The Example, Glowed Up ✨

With this extension, the RSEXEC could do the APPEND from the example above like this 💖

        to SITE1:                       to SITE2:

           .                                .
           .                                .
           .                                .

   1.                                   LSTN R CRLF
                                        (let X = socket
                                         allocated)

   2.   SOCK SITE2,X CRLF
        (let Y = socket in 255
         reply from SITE1)

   3.                                   SOCK SITE1,Y CRLF

   4.  RETR PROG1.PL1                   APPE PROG2.Pl1 CRLF

          .                                 .
          .                                 .
          .                                 .

Closing Thoughts 💅

To wrap up, an experimental RSEXEC program like the one described above has been running on TENEXs for about 8 months 🖥️ It currently uses a private resource sharing protocol (RSP) that includes file transfer operations. RSP supports server-server cooperation, and in RSP data connections are set up symmetrically (alternative 1 above) 👑

---

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Mirsad Todorovac 5/98 ] 🌸