As per Relevance of the word representation, we have this rfc below:
Network Working Group R.
Request for Comments: 1440 Rice
July 1993
SIFT/UFT: Sender-Initiated/Unsolicited File
Status of this
This memo defines an Experimental Protocol for the
community. It does not specify an Internet standard. Discussion
suggestions for improvement are requested. Please refer to
current edition of the "IAB Official Protocol Standards" for
standardization state and status of this protocol. Distribution
this memo is unlimited
1.
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
document. The term "unsolicited" does not imply that the file
unwanted, but that the receiver did not initiate the transaction
Sender-Initiated File Transfer contrasts with other file
methods in that the sender need not have an account or
registration on the target host system, and the receiving user
have less steps to take to retrieve the file(s) sent.
traditional file transfer, UFT lends itself handily to background
deferred operation, though it may be carried out immediately,
interactively
2.
In certain non-IP networks, notably NJE based networks such
BITNET, it is possible to send a file to another user outside of
realm of "mail". The effect is that the file sent is not
as correspondence and not processed by a mail user agent.
convenient service is missed in the standard TCP/IP suite.
author maintains that traditional electronic mail is not suited
non-correspondence file transfer. There should be a means of
non-mail, analogous to the sending of parcels rather than
mail. Several groups and individuals have shown an interest in
type of service
Troth [Page 1]
RFC 1440 SIFT/UFT July 1993
3.
We define sender-initiated file transfer for IP as a TCP service
follows: a receiver program (the server or "daemon") listens on
608 for inbound connections. Client programs connect to this
and send a sequence of commands followed by a stream of data.
entire job stream may be thought of as the concatenation of
files, 1) a control file, and 2) a data file, where the control
is plain text and the data file may be any of several formats, but
stored and sent as binary. After each command, the receiver
ACKs (signals positive acknowledgement) or NAKs (signals
acknowledgement). The target host may reject a file for
reasons, most obvious being 1) that there is no local user
the intended user, or 2) that there is not enough space to hold
incoming file
Most UFT commands are parametric. That is, they don't
invoke an action as much as change parameters of the one action
transfer of the file(s) being sent. This means that UFT is
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
area, say /usr/spool/uft, until accepted or rejected by the
user or discarded for age by the system. This staging area is
in the sense of shared space, not unrestricted access. Exactly
long files may remain unprocessed and exactly how large
transient files may be is a local administrative or
decision
But not all hosts have IP connectivity; not all hosts will want
put up yet another server; not all hosts will be on the
side of a "fire wall" that only passes mail. In such cases, UFT
be transported via MIME (Multipurpose Internet Mail Extensions)
Content-Type: application/octet-stream. UFT commands then
parameters to the Content-Type field and the data file is carried
the mail body. While the data file is carried in raw (binary)
over TCP, it is encoded in BASE64 when carried by mail
UFT supports several representation types. The receiving host
accept any file type sent. If the representation type is
meaningful to the target host system, then it should be treated
"binary" (image). The data file (body) should be processed as
as possible until the target user (recipient) acts to
(receive) it. The commands from the client may be stored in the
of a plain-text file so that processing otherwise foreign to
receiver may be off-loaded from the TCP listener. So there
actually two files: the command sequence and the file body
Troth [Page 2]
RFC 1440 SIFT/UFT July 1993
Job Entry capability
The target "user" may actually be no user at all, but may be
name of some software service engine. An example of this is
job entry queue available as a pseudo-user on many NJE
hosts
4. Essential commands and Syntax
FILE size sender [auth
USER
TYPE type [parm
Representation Types
TYPE A ASCII, CR/LF (0D/0A
B binary (image; octet stream
C ASCII, CC, CR/LF (ASA print
U unformatted (binary; image
V var-length records (16 bit
W wide var-len records (32 bit
X extra-wide var-length (64 bit
I image (binary; octet stream
E EBCDIC, NL (15)
F reclen fixed-length records (binary
N
M ASCII,
Additional Parameters
NAME
DATE date time [time-zone
CLASS
FORM paper-form-code or print-stock-
DEST
DIST | BIN | BOX distribution-code or mail-
FCB | CTAPE forms-control-buffer or carriage-
UCS | CHARSET | TRAIN print-train or character-
LRECL logical-record-
RECFM record-
Troth [Page 3]
RFC 1440 SIFT/UFT July 1993
BLKSIZE block-
MODE file access
File disposition commands
DATA [burst-size
5. Details
Commands consist of command words, possibly followed by
delimited by white space. Command lines are ASCII terminated
CR/LF. White space may be composed of any mixture of blanks or
characters, but use of ordinary blank space (ASCII 0x20) is
recommended
One connection (one socket) is used for both commands and data
While a data burst is being received, command interpretation
suspended. Command lines are read until CR/LF; data bursts are
until burst-size number of octets are received, at which
command interpretation is resumed. After data transmission
begun, the only commands valid are DATA, EOF, ABORT and QUIT.
causes the server to close the file at the receiving end and
to normal command processing. ABORT signals that the client
to discard a file partially transmitted. QUIT closes any open file
closes the connection, and can appear anywhere in the job
For the daring, a "fast" mode is available. If the burst-size
is omitted from the DATA command, processing switches to data
and the stream is read until the client closes the connection.
this case there is no EOF or QUIT command sent. NOTE: with
former mode of operation, the connection may remain open
passing multiple files, while in this latter case the connection
close to terminate the transaction
Acknowledgement is by simple "NULL ACK". A server accepts a
by sending a single packet back to the client that starts with a
character, decimal 0. Anything else may be considered
acknowledgement, and the client should close the connection.
characters following the NULL may be ignored. An ACK response
may signal only one acknowledgement
When a client first connects to a server, the server
Troth [Page 4]
RFC 1440 SIFT/UFT July 1993
sends a herald of the form
xxx hostname UFT 1.0 server-version
where "xxx" represents arbitrary data. The first "xxx" must be
single blank delimited token. 1.0 is the protocol version.
is the IP name of the host where this server is running. Server
version is the name and level of UFT server code on this host
A US English server might send
100 ricevm1.rice.edu UFT 1.0 VM/CMS-0.9.2 ready
The purpose of this herald is partly for client/
synchronization, but mainly for protocol agreement. There may
future versions of UFT beyond 1.0 which support more features
are outlined here. The herald indicates what level of UFT the
will accept
The FILE Command
FILE size from [auth
The size is in bytes and may be followed by an 'M', 'K', or 'G',
indicating Mega, Kilo, or Giga. Size may be an inexact value (
data file will be read until one of the above end-of-file
is received). The size specified is used to answer the question, "
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.
are several ways that it might be added to UFT over TCP, but
author will wait for authentication developments by others to come
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
The recipient is a valid local user or service name
The USER command is required in any transaction. Without it,
destination of the file is unknown
Troth [Page 5]
RFC 1440 SIFT/UFT July 1993
The TYPE Command
TYPE type [parm
Some representation types need additional specification. As
example, the type "F" (fixed length, record oriented) obviously
more qualification. How long are these fixed length records?
record length in ASCII decimal should follow the "F" resulting in
command like "TYPE F 80".
UFT types V, W, X use a tape model for file transfer. Files
transit consist of blocks that vary in size based on the range
sizes specifiable with 16, 32, or 64 bits, respectively. Whether
blocking is significant to the recipient is the decision of
recipient, but if the file originally had some kind of blocking,
is preserved without additional processing. In the stream, the 16,
32, or 64-bit block length is prepended to each record in TCP/
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
A name should typically be associated with the file being sent
although this is not mandatory. This is a mixed case
delimitted by white space. If the filename contains blanks or
space, it must be quoted. Quotation is not valid within
filename. ASCII control characters (hex 00 thru 1F and 80 thru 9F
are not valid as part of the filename. Some characters may
special meaning to the receiving operating system and their effect
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
sent and applied to the copy at the receiving site. The form is
mm/dd/yy and hh:mm:ss. A time zone is optional. If the time zone
omitted, local time is assumed. If the DATE command is omitted,
and date of arrival are assumed
Troth [Page 6]
RFC 1440 SIFT/UFT July 1993
The DATE command is optional
The DATA Command
DATA [burst-size
If no data bursts have yet been received since the connection
opened or since an EOF or ABORT was received, the server opens a
file on the receiving end and writes this burst of data to it.
file may have already been created by a prior DATA command.
can be any number of DATA commands; most files will be sent
many data bursts. If burst-size is supplied, then burst-size
of octets are read and appended to the open file on the receiving
and the server returns to the command state. If no burst-
parameter is given, then the TCP stream is read until it is closed
(this is the "fast" mode mentioned above
The DATA command must come after FILE, USER, TYPE, and any
parametric commands and must come before any EOF or ABORT command
The file need not be complete before an ABORT can be received
carried out, but the DATA command must have completed (burst-
number of octets must have been read), thus ABORT is not possible
"fast" mode
The EOF Command
This signals the server that the entire file has been sent.
server then closes the file and ensures that it is disposed
appropriately, usually just placing it where a user-level
can retrieve it later
The ABORT Command
This signals the server that the client is unable or unwilling
finish the job. The file should be discarded and the server
return to normal command processing
The QUIT Command
This signals the server that all work is complete. Any open
should be closed and delivered. The TCP stream will be closed
Troth [Page 7]
RFC 1440 SIFT/UFT July 1993
Other commands
CLASS
FORM paper-form-code or print-stock-
DEST
DIST distribution-code or mail-
FCB forms-control-buffer or carriage-
CHARSET print-train or character-
The above are relevant to print jobs sent to a print server
LRECL logical-record-
RECFM record-
BLKSIZE block-
MODE file access
6.
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
for
BITNET -- "Because It's Time"; academic
based on NJE
MIME -- RFC 1341; Multipurpose Internet Mail Extensions
Borenstein &
FTP -- File Transfer Protocol; STD 9, RFC 959;
Postel &
SMTP -- STD 10, RFC 821; Simple Mail
Protocol;
LPR -- UNIX Programmer's Manual, LPD(8);
4.2BSD Line Printer Spooler
7. Security
Security issues are not discussed in this memo
Troth [Page 8]
RFC 1440 SIFT/UFT July 1993
8. Author's
Rick
Rice
Information
Houston, Texas 77251
Phone: (713) 285-5148
Fax: (713) 527-6099
EMail: troth@rice.
Troth [Page 9]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
