RFC 438 (rfc438) - Page 3 of 3
FTP server-server interaction
Alternative Format: Original Text Document
RFC 438 FTP Server-Server Interaction January 1973 1. On success the reply must be the 255 FTP server data socket reply; that is, the 255 reply can not be deferred until receipt of a data transfer command. (This is to allow the user to transmit the server's response to the program at the third site; see the example below.) 2. After a LSTN command the SOCK command is to be interpreted by the server as specification of the acceptable RFC for subsequent data transfer command that use the allocated socket. With this extension to FTP, the RSEXEC program could accomplish the APPEND in the example above as follows: 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 . . . . . . In closing it is appropriate to note that an experimental RSEXEC program of the sort suggested above has been operational 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; in RSP data connections are established in a symmetric way (alternative 1 above). [ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Mirsad Todorovac 5/98 ] Thomas, et. al.