The Data Transfer Protocol
RFC 171

Document Type RFC - Unknown (June 1971; No errata)
Obsoleted by RFC 264
Updated by RFC 238
Updates RFC 114
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 171 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
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
                                                            Eric Harslem
                                                            John Heafner
                                                             John Melvin
                                                             Dick Watson
                                                            Bob Sundberg
                                                               Jim White
                                                            23 June 1971

                       THE DATA TRANSFER PROTOCOL


   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.


   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 the above modes to be intermixed over the same
   connection (i.e., mode is not associated with connection, but only
   with transaction).  The above transfer modes can represent transfer
   of either data or control information.  The protocol allows for
   separating data or control information at a lower level, by providing
   different "type" codes (see SPECIFICATIONS) for data and control
   transactions.  This provision may simplify some implementations.

   The implementation of a workable [2] subset of the above modes is
   specifically permitted by DTP.  To provide compatibility between
   hosts using different subsets of transfer modes, an initial
   "handshake" procedure is required by DTP.  The handshake involves
Show full document text