Browse Prior Art Database

The Data Transfer Protocol (RFC0171)

IP.com Disclosure Number: IPCOM000002549D
Original Publication Date: 1971-Jun-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

A. Bhushan: AUTHOR [+9]

Related Documents

10.17487/RFC0171: DOI

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 21% of the total text.

Network Working Group Abhay Bhushan Request for Comments: 171 MIT NIC 6793 Bob Braden Categories: D.4, D.5, and D.7 UCLA Updates: 114 Will Crowther Obsolete: None Alex McKenzie BBN Eric Harslem John Heafner Rand John Melvin Dick Watson SRI Bob Sundberg HARVARD Jim White UCSB 23 June 1971

THE DATA TRANSFER PROTOCOL

I. INTRODUCTION

A common protocol is desirable for data transfer in such diverse applications as remote job entry, file transfer, network mail system, graphics, remote program execution, and communication with block data terminals (such as printers, card, paper tape, and magnetic tape equipment, especially in context of terminal IMPs). Although it would be possible to include some or even all of the above applications in an all-inclusive file transfer protocol, a separation between data transfer and application functions would provide flexibility in implementation, and reduce complexity. Separating the data transfer function would also reduce proliferation of programs and protocols.

We have therefore defined a low-level data transfer protocol (DTP) to be used for transfer of data in file transfer, remote job entry, and other applications protocols. This paper concerns itself solely with the data transfer protocol. A companion paper (RFC 172) describes file transfer protocol.

II. DISCUSSION

The data transfer protocol (DTP) serves three basic functions. It provides for convenient separation of NCP messages into "logical" blocks (transactions, units, records, groups, and files), it allows for the separation of data and control information, and it includes some error control mechanisms.

Bhushan, et al. [Page 1]

RFC 171 THE DATA TRANSFER PROTOCOL June 1971

Three modes of separating messages into transactions [1] are allowed by DTP. The first is an indefinite bit stream which terminates only when the connection is closed (i.e., the bit stream represents a single transaction for duration of connection). This mode would be useful in data transfer between hosts and terminal IMPs (TIPs).

The second mode utilizes a "transparent" block convention, similar to the ASCII DLE (Data Link Escape). In "transparent" mode, transactions (which may be arbitrarily long) end whenever the character sequence DLE ETX is encountered (DLE and ETX are 8-bit character codes). To prevent the possibility of a DLE ETX sequence occurring within data stream, any occurrence of DLE is replaced by DLE DLE on transmission. The extra DLE is stripped on reception. A departure from the ASCII convention is that "transparent" block does not begin with DLE STX, but with a transaction type byte. This mode will be useful in data transfer between terminal IMPs.

The third mode utilizes a count mechanism. Each transaction begins with a fixed-length descriptor field containing separate binary counts of information bits and filler bits. If a transaction has no filler bits, its filler count is zero. This mode will be useful in most host-to-host data transfer applications.

DTP allows for...

Processing...
Loading...