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.