RFC 264

RFC 264: THE DATA TRANSFER PROTOCOL 💖

bestie, this is RFC 264 🎀 Here's the title block, served fresh:

• Series: Network Working Group
• RFC number: 264 (NIC 7812)
• Title: THE DATA TRANSFER PROTOCOL
• Authors:
  • A. Bhushan, MIT
  • B. Braden, UCLA
  • W. Crowther, BBN
  • E. Harslem, Rand
  • J. Heafner, Rand
  • A. McKenzie, BBN
  • J. Melvin, SRI
  • B. Sundberg, Harvard
  • D. Watson, SRI
  • J. White, UCSB
• Date: 15 November 1971
• Revision of: RFC 171 (NIC 6793). It doesn't list a category or status in this header, so I'm not guessing one 🙈

Okay so this paper is a revision of RFC 171, NIC 6793 🌸 The changes to RFC 171 are listed right below, and then the protocol gets restated so you have everything in one place 🫶

---

CHANGES TO RFC 171 ✨

1. The sequence number field is changed to 16 bits in the error (Type B5) transactions, which is so iconic because it resolves the ambiguity in the previous specification 👑 Also, 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, since they're 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 🍓

---

I. INTRODUCTION 🌈

Bestie, a common protocol is so needed for data transfer across super different applications 😭 We're talking 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) 💜

Now, yes, it would be possible to cram some or even all of those applications into one all-inclusive file transfer protocol 🙈 But a separation between data transfer and application functions MAY provide flexibility in implementation, and reduce complexity ✨ Separating the data transfer function from the specific application functions MAY also reduce proliferation of programs and protocols 🫶

So we 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 is only about the data transfer protocol. The companion paper (RFC 265) describes the file transfer protocol 🎀

---

II. DISCUSSION 💅

The data transfer protocol (DTP) has three basic jobs 👑 It splits NCP messages into "logical" blocks (transactions, units, records, groups, and files), it lets you separate 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. It only ends when the connection is closed, so the bit stream represents one single transaction for the whole duration of the connection ✨ This mode would be useful for data transfer between hosts and terminal IMPs (TIPs) 🌸

The second mode uses a "transparent" block convention, kind of like the ASCII DLE (Data Link Escape) convention 💜 In "transparent" mode, transactions (which MAY be arbitrarily long) end whenever the character sequence DLE ETX shows up (DLE and ETX are 8-bit character codes) 😭 To stop a DLE ETX sequence from appearing inside the data stream by accident, any DLE gets replaced by DLE DLE on transmission. The extra DLE gets stripped on reception 🙈 The twist is that "transparent" block does not begin with DLE STX. It begins with a transaction type byte instead 🧚 This mode would be useful for data transfer between terminal IMPs 🍓

The third mode uses a count mechanism 💖 Each transaction starts with a fixed-length descriptor field holding separate binary counts of information bits and filler (i.e., not information) bits 🎀 If a transaction has no filler bits, its filler count is zero 🫶 This mode would be useful for most host-to-host data transfer applications 🌈

DTP lets you intermix transfer modes over the same connection, which is giving flexibility 🦋 The transfer mode isn't tied to the connection, only to the transaction ✨ Transfer modes can represent either data or control information 💅 The protocol also lets you separate data and control information at a lower level by providing different "type" codes (see SPECIFICATIONS) for data and control transactions 👑 This provision MAY simplify some implementations 🔥

Implementing only a subset of transfer modes is specifically permitted by DTP 💜 So that hosts using different subsets of transfer modes can still be compatible, an initial "handshake" procedure MAY be used 😭 The handshake involves exchanging information on modes available for receive, which lets host programs agree on transfer modes that are acceptable for a connection 🌸

Using DTP

How DTP gets used depends largely on the applications protocol 💅 It's the applications protocol that defines how transfer modes get used, along with the information separator and abort functions DTP provides (see SPECIFICATIONS) 🦋 For example, in a remote job entry protocol, aborts MAY be used to stop the execution of a job, while in another applications protocol they MAY not cause any action at all 🙈

It SHOULD also be noted that DTP does not define a data transfer service 🧚 There's no standard server socket and no initial connection protocol defined for DTP 💖 What DTP does define is a mechanism for data transfer that can be used to provide services for block data transfers, file transfers, remote job entry, network mail, and other applications 🎀

There are to be no restrictions on how DTP gets implemented at various sites 🌈 DTP MAY be imbedded in an applications program, such as for file transfer, or it MAY be a separate service program or subroutine used by several applications programs 🫶 Another implementation MAY employ macros or UUO's (unimplemented user operations on PDP-10's) to achieve the functions specified in DTP ✨ It's also possible that, in implementation, the separation between the DTP and applications protocols is only at a conceptual level, bestie 👑

---

🧚 part 1 of 2 done! part 2 is coming up next 💜

III. SPECIFICATIONS ✨

1. Byte Size for Network Connection 🎀

Okay so the standard byte size for network connections using DTP is 8 bits 💖. Other byte sizes that applications protocols specify are also allowed by DTP 🌸. For this doc, bytes are assumed to be 8 bits unless it says otherwise 💅.

2. Transactions 🦋

At the DTP level, everything sent over a connection is a sequence of transactions 🫶. DTP is the one that sets the rules for delimiting transactions, so it's the boss of where each one starts and ends 👑.

2A. Types 👑

The first 8-bit byte of each transaction SHALL define a transaction type, as shown in the table below 😭. Fun fact: these code assignments don't clash with the ones in the TELNET protocol 💅. Transaction types get referred to by their hexadecimal code. You can read more about them in Section 2B 🧠.

    Code                    Transaction Type
Hex     Octal

B0      260             Indefinite bit stream -- data.
B1      261             Transparent (DLE) block--data.
B2      262             Descriptor and counts--data.
B3      263             Modes available (handshake).
B4      264             Information Separators.
B5      265             Error codes.
B6      266             Abort.
B7      267             No operation (NoOp).
B8      270             Indefinite bit stream--control.
B9      271             Transparent (DLE) block--control.
BA      272             Descriptor and counts--control.
BB      273
through through         Unassigned but reserved for DTP.
BF      277

2B. Syntax and Semantics 🧚

2B.1 Type B0 and B8 (indefinite bitstream modes) transactions 🌊

Okay so B0 and B8 transactions only end when the NCP connection is "closed" 🔒. DTP doesn't define any other escape convention at this level 🙅. Also, it SHOULD be noted that closing a connection in bitstream mode counts as an implicit file separator (see Section 2B.5) 🤯.

2B.2 Type B1 and B9 (transparent block modes) transactions 🧱

B1 and B9 transactions end when the byte sequence DLE ETX shows up 🛑. The sender SHALL replace any DLE in the data stream with DLE DLE 🔁, and the receiver SHALL strip the extra DLE ✂️. The transaction is assumed to be byte-oriented.

Now, DLE is Hex '90' or Octal '220'. That's different from the ASCII DLE, which is Hex '10' or Octal '020). [2] 🙃 ETX is Hex '03' or Octal '03', same as ASCII ETX 💜.

2B.3 Type B2 and BA (descriptor and counts modes) transactions 🧮

These transactions have three fields: a 9-byte (72-bit) descriptor field, shown below, plus variable-length info and filler fields (zero length is allowed too) ✨. The total length of a transaction is (72+info+filler) bits.

|<B2 or BA>|<Info count>| <NUL> <Sequence #>| <NUL> |<filler count>|
|<-8-bit-> |<--24-bit-->|<8-bit><--16-bit-->|<8-bit>|<---8-bit---->|
|<--------------------72-bit descriptor field--------------------->|

Info count is a binary count of the bits in the info field, not counting descriptor or filler bits 🔢. Info bits are capped at (2**24 - 1), since the info count field has 24 bits.

Sequence # is a sequential, round-robin count of B2, BA, and B4 transactions 🔁. It's super helpful for debugging and error control, since you can use sequence numbers to check for missing transactions and track down errors 🕵️. Hosts that don't want to implement this mechanism SHOULD have all 1's in the field. The count SHALL start from zero and keep going up to all 1's, then reset to all zeros. The permitted sequence numbers are one greater than the previous one, all 1's, and zero for the first transaction only.

Filler count is a binary count of the bits used as fillers (so, not information) after the end of the meaningful data 🧽. The number of filler bits is capped at 255, since the filler count field has 8 bits.

The NUL bytes MUST contain all 0's 🫧.

2B.4 Type B3 (modes available) transactions 🎀

These are fixed at two bytes long 📏. The first byte is B3, and the second byte tells the other side which transfer modes are available for receive.

+-----------------+---------------------+
|Type             |     I receive       |
|        B3       |                     |
|                 |0|0|BA|B2|B9|B1|B8|B0|
+-----------------+---------------------+

The modes get indicated with bit-coding, like in the diagram above 🧩. When a bit is set to logical "1", it means the matching mode is handled by the sender's receive side. The two most significant bits SHOULD be set to logical "0" 🙈. Mode available transactions don't matter at all in a simplex connection. You'll find how type B3 gets used in section 3B.

2B.5 Type B4 (information separator) transactions 🍓

These are a fixed four bytes long 📦. The first byte is B4, the second byte is the separator, and the third and fourth bytes hold a 16-bit sequence number.

+------------+------------+-------------------------+
|Type        |  End Code  |      Sequence Number    |
|     B4     |            |            |            |
|            |            |            |            |
+------------+------------+------------+------------+

These are the separator codes that have been assigned:

    Code                      Meaning
Hex             Octal

01              001             Unit separator
02              002             Record separator
03              003             Group separator
04              004             File separator

Files, groups, records, and units can be data blocks that a user defines as such 🗂️. The one rule is the hierarchy File>Groups>Records>Units (where '>' means 'contains'). So a file separator marks not only the end of a file, but also the end of the group, record, and unit. Lowkey genius 🧠.

These separators can give you a handy "logical" split of data at the data transfer level 🍰. Their use is governed by the applications protocol.

2B.6 Type B5 (error codes) transactions 🚨

These are a fixed four bytes long 🪧. The first byte is B5, the second byte is an error code, and the third and fourth bytes may point to the sequence number of the transaction where the error happened.

+------------+------------+-------------------------+
|Type        |  End Code  |      Sequence Number    |
|     B5     |            |            |            |
|            |            |            |            |
+------------+------------+------------+------------+

These error codes are assigned:

    Error Code            Meaning
Hex             Octal

00              000       Undefined error
01              001       Out of sync. (type code other
                          than B0 through BF).
02              002       Broken sequence (the sequence # field
                          contains the first expected but not
                          received sequence number).
03              003       Illegal DLF sequence (other than DLE
                          DLE or DLE FTX).
B0              260
through         through   The transaction type (indicated by
BF              277       by error code) is not implemented.

The error code transaction only exists for error control 🛠️. DTP does not require the receiver of an error code to take any recovery action. The receiver MAY discard the error code transaction. Also, DTP doesn't require that sequence numbers be remembered or sent 🤷‍♀️.

2B.7 Type B6 (abort) transactions 🛑

These are a fixed two bytes long ✂️. The first byte is B6, and the second byte defines the abort function.

+------------+------------+
|Type        |  Function  |
|     B6     |            |
|            |            |
+------------+------------+

These abort codes are assigned:

    Abort Code                  Meaning
Hex             Octal

00              000             Abort preceding transaction
01              001             Abort preceding unit
02              002             Abort preceding record
03              003             Abort preceding group
04              004             Abort preceding file

DTP does not require the receiver of an abort to take any specific action, so a sender SHOULD NOT make any assumptions about it 🙅‍♀️. How abort gets handled is left for higher-level applications protocols to specify 💖.

Real talk: don't assume an abort did anything specific on the other end. DTP just doesn't promise that 😭.

2B.8 Type B7 (NoOp) transactions 🫥

Type B7 transactions are one byte (8-bit) long, and they mean no operation 😴. These MAY be useful as fillers when the byte size used for network connections is something other than 8 bits.

3. Initial Connection, Handshake and Error Recovery 🤝

3A.

DTP doesn't specify how connections get established 🔌. It's up to the applications protocol (like a file transfer protocol) to pick whatever mechanism suits its needs. [3]

3B.

The first transaction after a full-duplex connection is made will be type B3 (modes available), which tells the other side the transfer modes available for receive 🎉. Type B3 isn't applicable in simplex connections. It's the sender's job to choose a mode the receiver can accept. [4] If there's no acceptable mode available, or if the chosen mode isn't acceptable, the connection MAY be closed 🚪.

3C.

DTP doesn't specify any error recovery mechanisms 🙃. The applications protocol MAY implement its own error recovery and further error control mechanisms 🛡️.

---

Endnotes 📝

[1] The term transaction is used here to mean a block of data defined by the transfer mode.

[2] This assignment was made to be consistent with the TELNET philosophy of maintaining the integrity of the 128 Network ASCII characters.

[3] It is, however, RECOMMENDED that the standard Initial Connection Protocol as specified in RFC 165 or any subsequent standard document be adopted where feasible.

[4] It is suggested that when available, the sender SHOULD choose 'descriptor and count' mode (Type B2 or BA). The 'indefinite bitstream' mode (Type B0 or B8) SHOULD be chosen only when the other two modes are not available.

         [ This RFC was put into machine readable form for entry ]
            [ into the online RFC archives by Ryan Kato 6/01 ]