RFC 1440

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

Okay bestie, so this is RFC 1440 💖 It was written by R. Troth at Rice University for the Network Working Group, and it's dated July 1993. It's an Experimental category document, so it's more of a "let's try this out" vibe than a standard 🧪 The title block doesn't list any RFCs that it obsoletes or updates, so it's standing on its own ✨ This is part 1 of 2, and Section 4 (where the commands live) is coming up next 💅

Status of this Memo ✨

Okay, this part is the official fine print 📜 This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard. They're literally asking for discussion and suggestions for improvement 💬 For the standardization state and status of this protocol, check the current edition of the "IAB Official Protocol Standards" 📚 And 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). SIFT and UFT are synonyms all the way through, so don't get confused 💌 The word "unsolicited" does NOT mean the file is unwanted. It just means the receiver didn't start the transaction 🫶

Sender-Initiated File Transfer is different from other file transfer methods because the sender doesn't need an account or any registration on the target host system. The receiving user may also have fewer steps to take to grab the file(s) sent ✨ Unlike traditional file transfer, UFT is super handy for background or deferred operation, though it can also run immediately, even interactively 🚀

2. Rationale 🧠

Certain non-IP networks, notably NJE based networks like BITNET, let you send a file to another user outside of the realm of "mail" 📨 The file isn't seen as correspondence and isn't processed by a mail user agent. This convenient service is missing from the standard TCP/IP suite, and that's kind of a big deal 😤 The author maintains that traditional electronic mail is not suited to non-correspondence file transfer. There should be a means of sending non-mail, kind of like sending parcels instead of surface mail 📦 Several groups and individuals have shown interest in this type of service 🙌

3. Specification 📮

We define sender-initiated file transfer for IP as a TCP service like this: 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 whole job stream can be thought of as the concatenation of two files: 1) a control file, and 2) a data file. The control file is plain text. The data file can be any of several formats, but it's 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, and the most obvious ones are 1) there's no local user matching the intended user, or 2) there's not enough space to hold the incoming file 🙅‍♀️

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

When files arrive at the destination host, they're kept in a public area, say /usr/spool/uft, until they're 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 those cases, UFT may be transported via MIME (Multipurpose Internet Mail Extensions) as Content-Type: application/octet-stream. The 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's encoded in BASE64 when it's 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 🧚

Job Entry capability ✨

The target "user" may actually be no user at all, but may be the name of some software service engine. An example of this is the job entry queue, which is available as a pseudo-user on many NJE networked hosts 🖥️💜

5. Details ✨

Okay bestie, this is the good part 💅 Commands are command words, sometimes followed by tokens separated by white space. Command lines are ASCII and end with CR/LF 🌸 White space can be any mix of blanks or tab characters, but ordinary blank space (ASCII 0x20) is strongly recommended 🫶

One connection (one socket) handles both commands and data 🦋 While a data burst is coming in, command interpretation pauses. Command lines get read until CR/LF, and data bursts get read until burst-size octets have arrived. Then command interpretation picks back up ✨ Once data transmission has started, the only valid commands are DATA, EOF, ABORT and QUIT 🚫 EOF makes the server close the file on the receiving end and go back to normal command processing. ABORT means the client wants to toss a file that was only partly sent 🗑️ QUIT closes any open file, closes the connection, and can show up anywhere in the job 👋

For the daring, there's a "fast" mode 😈 If the burst-size token is left out of DATA, processing switches to data mode and the stream is read until the client closes the connection. In this case, no EOF or QUIT gets sent.

NOTE: With the former mode of operation, the connection may remain open indefinitely passing multiple files, while in this latter case the connection must close to terminate the transaction.

Acknowledgement is a simple "NULL ACK" 🍓 A server accepts a command by sending back a single packet that starts with a NULL character, decimal 0. Anything else may be treated as a negative acknowledgement, and the client should close the connection. Any characters after the NULL may be ignored. An ACK response packet may signal only one acknowledgement.

When a client first connects, the server immediately sends a herald in this form 🧚

xxx hostname UFT 1.0 server-version xxx

Here "xxx" stands for arbitrary data. The first "xxx" must be a single blank delimited token. 1.0 is the protocol version. Hostname is the IP name of the host where the server is running. Server-version is the name and level of the UFT server code on this host.

A US English server might send something like this:

100 ricevm1.rice.edu UFT 1.0 VM/CMS-0.9.2 ready.

The herald is partly for client/server synchronization, but mainly for protocol agreement 🤝 There may be future versions of UFT beyond 1.0 that support more features than what's outlined here. The herald tells you what level of UFT the server will accept, so it's giving "here's my version, can you handle it?" 💜

The FILE Command 📄

FILE    size    from    [auth]

The size is in bytes and may be followed by an 'M', 'K', or 'G', meaning Mega, Kilo, or Giga 📦 Size may be an inexact value, since the data file will be read until one of the end-of-file indications above is received. The size is used to answer the question, "is there room for it?" 🏠

The from token is the login name of the user sending this file 🙋

The auth token is an unimplemented authentication ticket. Authentication is not ensured in the protocol as described. There are several ways it might get added to UFT over TCP, but the author will wait for authentication developments by others to come to fruition before implementing any. When UFT is piggy-backed on mail, authentication is left to the mail transfer system 📬

The FILE command is required in any transaction 🔥

The USER Command 👤

USER    recipient

The recipient is a valid local user or service name 💖

The USER command is required in any transaction. Without it, the destination of the file is unknown 🗺️

The TYPE Command 🎀

TYPE    type   [parm]

Some representation types need extra specification. The type "F" (fixed length, record oriented) obviously needs more qualification, like how long those fixed length records are. A record length in ASCII decimal should follow the "F", giving a command like TYPE F 80 ✨

UFT types V, W, X use a tape model for file transfer. Files in transit consist of blocks that vary in size, based on the range of sizes you can specify with 16, 32, or 64 bits, respectively. Whether the blocking matters to the recipient is the recipient's decision, but if the file originally had some kind of blocking, it's preserved without additional processing. In the stream, the 16, 32, or 64-bit block length gets prepended to each record in TCP/IP network order 🧩

Type N (NETDATA) is an IBM representation common on NJE networks 🖥️

The TYPE command is required in any transaction 💅

The NAME Command 🏷️

NAME    filename

A name should typically be associated with the file being sent, though it isn't mandatory. This is a mixed case token delimited by white space. If the filename contains blanks or white space, it must be quoted. Quotation is not valid within the filename. ASCII control characters (hex 00 thru 1F and 80 thru 9F) are not valid as part of the filename. Some characters may have special meaning to the receiving operating system, and their effect is not guaranteed 🙈

The NAME command is optional 🌈

The DATE Command 🗓️

DATE    date    time    [time-zone]

The time stamp on the file as it appears at the sending site may be sent and applied to the copy at the receiving site ⏰ The form is US mm/dd/yy and hh:mm:ss. A time zone is optional. If the time zone is omitted, local time is assumed. If the DATE command is omitted, the time and date of arrival are assumed 🕰️

The DATE command is optional 🌸

The DATA Command 📦

DATA  [burst-size]

If no data bursts have been received yet since the connection was opened, or since an EOF or ABORT was received, the server opens a new file on the receiving end and writes this burst of data to it. The file may have already been created by a prior DATA command. There can be any number of DATA commands, since most files get sent in many data bursts 🫧 If burst-size is supplied, then burst-size octets are read and appended to the open file on the receiving end, and the server returns to the command state. If no burst-size parameter is given, the TCP stream is read until it's closed. (This is the "fast" mode mentioned above, bestie 🚀)

The DATA command must come after FILE, USER, TYPE, and any other parametric commands, and it must come before any EOF or ABORT command. The file doesn't need to be complete before an ABORT can be received and carried out. However, the DATA command must have completed (burst-size octets must have been read), so ABORT isn't possible in "fast" mode 🙅‍♀️

The EOF Command 🔚

EOF

This signals the server that the entire file has been sent. The server then closes the file and makes sure it's disposed of appropriately, which usually just means placing it where a user-level application can retrieve it later 🎉

The ABORT Command 🛑

ABORT

This signals the server that the client is unable or unwilling to finish the job. The file should be discarded, and the server should return to normal command processing 💔

The QUIT Command 👋

QUIT

This signals the server that all work is complete. Any open file should be closed and delivered. The TCP stream will then be closed ✨

Other Commands 🖨️

CLASS       class
FORM        paper-form-code  or  print-stock-code
DEST        destination
DIST        distribution-code  or  mail-stop
FCB         forms-control-buffer  or  carriage-tape
CHARSET     print-train  or  character-set

The above are relevant to print jobs sent to a print server 🖨️💜

LRECL       logical-record-length
RECFM       record-format
BLKSIZE     block-size
MODE        file access permissions

---

6. References 📚

• NJE -- Network Job Entry; IBM publication SC23-0070, "Network Job Entry; Formats and Protocols"
• NETDATA -- see IBM publication aann-nnnn (SC24-5461); VM/ESA: CMS Application Development Reference for Assembler
• BITNET -- "Because It's Time"; academic network based on NJE protocol
• MIME -- RFC 1341; Multipurpose Internet Mail Extensions; Borenstein & Freed
• FTP -- File Transfer Protocol; STD 9, RFC 959; Postel & Reynolds
• SMTP -- STD 10, RFC 821; Simple Mail Transfer Protocol; Postel
• LPR -- UNIX Programmer's Manual, LPD(8); 4.2BSD Line Printer Spooler Manual

7. Security Considerations 🔐

Security issues are not discussed in this memo. 😱 Full stop, so keep that in mind when you're reading this one.

8. Author's Address 💌

Rick Troth is the author of this memo 🫶

Rick Troth
Rice University
Information Systems
Houston, Texas 77251

Phone: (713) 285-5148
Fax: (713) 527-6099
EMail: troth@rice.edu