UFT Protocol Specification

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.

Commands

Required:

Optional:

Experimental:

Responses

Types

Required types:

Other types are:

Experimental types:

Concepts

file / metafile
The metafile is sent as plain text while the data, the file itself,
is sent as an octet stream. The metafile describes the file.
The metafile is nothing more or less than the attributes of the file such as name, date stamp, access rights or permission bits, etc.
SIFT job
A UFT transaction can be abstracted into a batch job.
Such an abstraction might be called "a SIFT job"
which can be fed to a TCP client (the usual mode of operation),
saved to disk or tape, or sent to a recipient by other means, like mail.
plain text
Plain text looks the same to the machine as it does to you and me. That is, if some program is to process a plain text file, then it is interpreted the same by the program as it would be by a human. There are no "gotchas" from non-printables or <TAB> -vs- <SPACE>. White space is white space and trailing blanks are not significant. In general, control characters are not allowed.

Plain Text

"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.

The SIFT Job

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.

Protocol Details

FILE   size   from   auth

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.

USER   user
identifies the user to whom this file is being sent
typically the login name of the intended recipient,
but alternatively the ID of a service robot program or process or even just the name of a pre-defined queue
TYPE   type
the transfer representation type: A, I, V, ...

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.

NAME   filename
DATE   yyyy/mm/dd   hh:mm:ss   tz
the date stamp of the file
ISO date format is best for this command
XDATE   ssss
the date stamp of the file in seconds since January 1, 1970 at midnight.
XDATE is more readily processed than DATE and is preferred
DATA   burst size
exact size of this burst of data in octets
(canonicalized data follows)
AUXDATA   burst size
exact size of this burst of auxiliary data in octets
(extended attribute or resource fork data follows)
EOF
end of file
A file in progress is closed and the server prepairs to receive another FILE command.
Alias: CLOSE
QUIT
terminates the session.
Any file in progress is closed as if an EOF had been sent and the connection is dropped.

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.

OWNER   owner
the logon ID of the owning user on the sending system.
The owner might not be the user sending the file.
GROUP   group
the group ID as it is on the sending system.
The sender might not be a member of the owning group.
XPERM   U: owner access   , G: group access   , O: world access   , S: system access
access permissions
The sending system will supply any that are available.
The receiving system will apply any that are applicable.
VERSION   file revision number
the version or revision index for this file
This is typically numeric.
RECFMT or RECORD_FORMAT
for record oriented systems; typically Fixed or Variable.
Proper canonicalization should retain file integrity in case this value is misunderstood between sender and receiver.
RECLEN or RECORD_LENGTH
for record oriented systems; the record length (if RECFMT=Fixed)
or the maximum record length (if RECFMT=Variable)

The following attribute commands typically apply to print jobs.

CLASS
CHARSET
FORM
FCB
DESTINATION
DISTRIBUTION

Responses (again)

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.

UFT/1 or UFT/2?

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.

Credits

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.

--
Rick Troth, Houston, Texas
<troth@casita.houston.tx.us>