The Data Transfer Protocol
RFC 264

Document Type RFC - Unknown (January 1972; No errata)
Obsoleted by RFC 354
Updated by RFC 310
Obsoletes RFC 171
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 264 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         A. Bhushan
Request for Comments: 264                                            MIT
NIC: 7812                                                      B. Braden
                                                             W. Crowther
                                                              E. Harslem
                                                              J. Heafner
                                                             A. McKenzie
                                                               J. Melvin
                                                             B. Sundberg
                                                               D. Watson
                                                                J. White
                                                        15 November 1971

                       THE DATA TRANSFER PROTOCOL

   This paper is a revision of RFC 171, NIC 6793.  The changes to RFC
   171 are given below.  The protocol is then restated for your


   1) The sequence number field is changed to 16 bits in the error (Type
      B5) transactions, thus resolving the ambiguity in the previous
      specification.  In addition, the information separators (Type B4)
      transactions shall also contain a 16-bit sequence number field.

   2) The modes available (Type B3) transactions shall define only the
      modes available for receive, instead of both receive and send.  In
      simplex connections modes available transactions should not be
      sent as they are meaningless.  In full-duplex connections, the
      modes available transactions are still required.

   3) The code assignments for "End Code" in information separators and
      for "function" in abort transactions have been changed to reflect
      a numerical order rather than "bit-coding".

   4) Minor editorial changes.

Bhushan, et. al.                                                [Page 1]
RFC 264                The Data Transfer Protocol       15 November 1971


      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 may
      provide flexibility in implementation, and reduce complexity.
      Separating the data transfer function from the specific
      applications functions may also reduce proliferation of programs
      and protocols.

      We have therefore defined a data transfer protocol (DTP) which
      should be used for transfer of data in file transfer, remote job
      entry, and other applications protocols.  This paper concerns
      itself only with the data transfer protocol.  A companion paper
      (RFC 265) describes the 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.

Transfer Modes

      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) convention.  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
Show full document text