SIFT/UFT: Sender-Initiated/Unsolicited File Transfer
RFC 1440

Document Type RFC - Experimental (July 1993; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1440 (Experimental)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                           R. Troth
Request for Comments: 1440                               Rice University
                                                               July 1993

          SIFT/UFT: Sender-Initiated/Unsolicited File Transfer

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard.  Discussion and
   suggestions for improvement are requested.  Please refer to the
   current edition of the "IAB Official Protocol Standards" for the
   standardization state and status of this protocol.  Distribution of
   this memo is unlimited.

1.  Introduction

   This document describes a Sender-Initiated File Transfer (SIFT)
   protocol, also commonly called Unsolicited File Transfer (UFT)
   protocol.  The acronyms SIFT and UFT are synonymous throughout this
   document.  The term "unsolicited" does not imply that the file is
   unwanted, but that the receiver did not initiate the transaction.

   Sender-Initiated File Transfer contrasts with other file transfer
   methods in that the sender need not have an account or any
   registration on the target host system, and the receiving user may
   have less steps to take to retrieve the file(s) sent.  Unlike
   traditional file transfer, UFT lends itself handily to background or
   deferred operation, though it may be carried out immediately, even
   interactively.

2.  Rationale

   In certain non-IP networks, notably NJE based networks such as
   BITNET, it is possible to send a file to another user outside of the
   realm of "mail".  The effect is that the file sent is not perceived
   as correspondence and not processed by a mail user agent.  This
   convenient service is missed in the standard TCP/IP suite.  The
   author maintains that traditional electronic mail is not suited to
   non-correspondence file transfer.  There should be a means of sending
   non-mail, analogous to the sending of parcels rather than surface
   mail.  Several groups and individuals have shown an interest in this
   type of service.

Troth                                                           [Page 1]
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
Show full document text