This is the specification for UFT protocol
(Unsolicited File Transfer),
also known as
SIFT (Sender-Initiated File Transfer).
It might be wise to discontinue use of the word
"unsolicited" and replace it with "universal".
This document obsoletes RFC 1440. Within this scope, the protocol described in RFC 1440 is referred to as UFT/0. What is outlined here we call UFT/2, making mention of the basic differences between that and UFT/1.
Required:
- FILE size from auth
- USER user
- TYPE type
- DATA burst size
- EOF
- QUIT
Optional:
- NAME filename
- DATE yyyy/mm/dd hh:mm:ss [tz]
- AUXDATA burst size
- CLASS
- CHARSET
- RECFMT or RECORD_FORMAT
- RECLEN or RECORD_LENGTH
- FORM
- FCB
- DESTINATION
- DISTRIBUTION
- XDATE seconds since epoch
- OWNER
- GROUP
- XPERM access permissions
- VERSION file version
Experimental:
- PIPE name from auth
- COMPRESS
- ENCRYPT
- 100 spontaneous server response, "info"
- 200 ACK (acknowledgment)
- 300 more requried (more required from client)
- 400 NAK (client error or temporary error)
- 500 NAK (server error or pernanent error)
- 600 required server response
Required types:
- A ASCII (plain text; CR/LF delimited lines)
- I "image" (binary)
Other types are:
- N NETDATA (proprietary, but common)
- M mail (in ASCII plain text form)
- V variable-length records (16-bit length field)
Experimental types:
- B "binary"; alias for I (image)
- E EBCDIC (plain text; NL (0x15) delimitted; blank (0x40) padded)
- F fixed-length records (sent as binary)
- T "text"; explicit alias for ASCII
- U "unformatted"; explicit alias for "binary"
- W wide var-length records (32-bit length field)
- X extra-wide var-length records (64-bit length)
"plain text" is the common thread among all general purpose computing systems. Most of the well known, certainly all of the commercially successful, programming languages are represented in plain text. E-mail is sent as plain text. And the best web authors write HTML with a plain text editor.
Plain text looks the same to the computer as it does to you. TAB and SPACE (or BLANK) characters are treated the same. Trailing white space is ignored.
UFT commands (client to server) are plain text. A CR/LF pair terminates the command line, but otherwise control characters are not allowed. Any mixture of BLANKs and/or TABs is treated as a single instance of white space. Trailing white space is ignored unless quoted, and quoting is beyond the scope of this document.
A UFT transaction can always be abstracted to a slightly higher level such that the file being sent can be "batched" for other handling than client/server. Such an abstraction is called a "SIFT job".
The specification of a SIFT job varies from one platform to the next, but is always based directly upon the on-the-wire specification of a UFT job.
The size parameter can be an inexact value. In fact, it can be left as 0, because its sole purpose is to answer the "can this file fit" question, which doesn't strictly have to be answered yet. Size is a decimal number.
Why the ambiguity?
Ideally, before the transaction gets underway, it would be nice if the client and server both know how much data they'll be carrying. The server should know how much data it will get "dumped on it" and the client should know if the job will be able to complete. Better to send an estimate than to start the transfer only to have to abort or restart later with adjustments.
Enter Fudge Factor Engineering. Not all systems which participate in a UFT transaction keep track of the the exact number of bytes in a file (some systems are record oriented, etc). Not all ways of using UFT make the number available beforehand (sending the output from a pipeline or a program, for example). Even on a wholly stream-oriented system like UNIX, one cannot readily tell how many bytes a text file will contain when canonicalized to network format. (NVT) But in most cases an estimate can be derived.
UFT's TYPE value could conceivably be replaced with
a MIME Content Type value,
except that Content Type doesn't always clearly address
canonicalization, which is essential to interoperability.
TYPE M indicates that SIFT/UFT can be used to carry e-mail. But, SIFT itself can be carried by e-mail. Technically, it is possible for SIFT to be carried on top of mail which is then carried over UFT, or for mail to be carried by SIFT over mail. Things could get out of hand, but a pure implementation must allow for such combinations.
One of EOF or QUIT is required to close a file in transit without discarding it on the receiving end. Without one of those, the server presumes that something catastrophic happened to the client leaving the file incomplete.
The following attribute commands typically apply to print jobs.
Commands are acknowledged by a response that starts with a "2". Commands are rejected by a response starting with either a "4" or a "5". The digit "1" indicates a response that is informational, not final. The digit "3" indicates a response that requests more information. The digit "6" is for a response that is not final, but carries information explicitly requested by the client.
A response from the server (receiver) to the client (sender) looks something like
nnn message
where nnn is a unique three digit number starting with one of the above, 1, 2, 3, 4, 5, or 6. All other leading digits and letters are reserved, other characters (punctuation, etc) being in error.
The big advantage of unique message codes is that each response can be mapped to specific text in the local language of the client.
In UFT/2, the server sends a 2xx "herald" immediately upon accepting the connection from the client. A UFT/1 server sends a 1xx herald. The significant difference between a UFT/1 server and a UFT/2 server is how they respond to a DATA command. A UFT/1 server does not send a 300 range "waiting for more" reply and the placement of its 200 range "received data okay" reply is not clear and should only be expected at the end of the burst. Implementors should avoid writing UFT/1 servers but should code clients to be able to talk to them.
Thanks to the following people for
significant help with SIFT/UFT:
David Lippke, Bill Manning, Eric Thomas, John Klensin,
Valdis Kletnieks, Arty Ecock, Bill Hunter, Rob van der Heij,
and others about whom I'll be embarrassed to have left out.
Special thanks to the IBM Endicott team, not only for using Internet SENDFILE, but also for making the best O/S in the world.
--