RFC 1440 (rfc1440) - Page 2 of 9

SIFT/UFT: Sender-Initiated/Unsolicited File Transfer

RFC 1440                        SIFT/UFT                       July 1993


3.  Specification

   We define sender-initiated file transfer for IP as a TCP service as
   follows: a receiver program (the server or "daemon") listens on port
   608 for inbound connections.  Client programs connect to this port
   and send a sequence of commands followed by a stream of data.  The
   entire job stream may be thought of as the concatenation of two
   files, 1) a control file, and 2) a data file, where the control file
   is plain text and the data file may be any of several formats, but is
   stored and sent as binary.  After each command, the receiver either
   ACKs (signals positive acknowledgement) or NAKs (signals negative
   acknowledgement).  The target host may reject a file for various
   reasons, most obvious being 1) that there is no local user matching
   the intended user, or 2) that there is not enough space to hold the
   incoming file.

   Most UFT commands are parametric.  That is, they don't necessarily
   invoke an action as much as change parameters of the one action,
   transfer of the file(s) being sent.  This means that UFT is suitable
   for encapsulation in some higher-level "envelope", such as mail.
   However, the obvious prefered medium for UFT is TCP.

   When files arrive at the destination host, they are kept in a public
   area, say /usr/spool/uft, until accepted or rejected by the recipient
   user or discarded for age by the system.  This staging area is public
   in the sense of shared space, not unrestricted access.  Exactly how
   long files may remain unprocessed and exactly how large these
   transient files may be is a local administrative or implementation
   decision.

   But not all hosts have IP connectivity; not all hosts will want to
   put up yet another server; not all hosts will be on the unrestricted
   side of a "fire wall" that only passes mail.  In such cases, UFT may
   be transported via MIME (Multipurpose Internet Mail Extensions) as
   Content-Type: application/octet-stream.  UFT commands then become
   parameters to the Content-Type field and the data file is carried as
   the mail body.  While the data file is carried in raw (binary) form
   over TCP, it is encoded in BASE64 when carried by mail.

   UFT supports several representation types.  The receiving host should
   accept any file type sent.  If the representation type is not
   meaningful to the target host system, then it should be treated as
   "binary" (image).  The data file (body) should be processed as little
   as possible until the target user (recipient) acts to accept
   (receive) it.  The commands from the client may be stored in the form
   of a plain-text file so that processing otherwise foreign to the
   receiver may be off-loaded from the TCP listener.  So there are
   actually two files: the command sequence and the file body.



Troth