Browse Prior Art Database

SIFT/UFT: Sender-Initiated/Unsolicited File Transfer (RFC1440)

IP.com Disclosure Number: IPCOM000002268D
Original Publication Date: 1993-Jul-01
Included in the Prior Art Database: 2000-Sep-12
Document File: 7 page(s) / 16K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R. Troth: AUTHOR

Abstract

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.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 17% of the total text.

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.

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