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: 2019-Feb-10
Document File: 9 page(s) / 12K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R. Troth: AUTHOR

Related Documents

10.17487/RFC1440: DOI

Abstract

This document describes a Sender-Initiated File Transfer (SIFT) protocol, also commonly called Unsolicited File Transfer (UFT) protocol. This memo defines an Experimental Protocol for the Internet community.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 20% 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.

Troth [Page 1]

RFC 1440 SIFT/UFT July 1993

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 ACKs (signals positive acknowledgement) or NAKs (signals negative acknowledgement). The target host may reject a file for various reasons, most obvious being 1) that there is no local user matching the intended user, or 2) that there is not enough space to hold the incoming file.

Most UFT commands are parametric. That is, they don’t necessarily invoke an action as much as change parameters of the one action, transfer of the file(s) being sent. This means that UFT is suitable for encapsulation in some higher-level "env...

Processing...
Loading...