Output of the Host-Host Protocol Glitch Cleaning Committee (RFC0107)
Original Publication Date: 1971-Mar-01
Included in the Prior Art Database: 2019-Feb-10
Internet Society Requests For Comment (RFCs)
R.D. Bressler: AUTHOR [+5]
Network Working Group Request for Comments # 107
NIC # 5806
Output of the Host-Host Protocol Glitch Cleaning Committee
UCLA 23 March 1971
Robert Bressler Steve Crocker William Crowter Gary Grossman Ray Tomlinson James Withe
The Host-Host Protocol Glitch Cleaning Committee met for the second time at UCLA on 8, 9 March 1971, after canvassing the network com- munity. [The result of the (slightly larger) committee’s first meeting are documented in RFC #102.] The committee agreed on several modifications to the protocol in Document #1; these modi- fications are listed below.
At each of the meeting, the committee quickly treated all but one of the extant topics. At the first meeting, the bulk of time was spent considering the interrupt mechanism, and that discussion is summarized in RFC #102. At the second meeting, the committee spent almost all of its time discussing the notion of bytes; this dis- cussion is summarized after the list of modifications.
This RFC entirely supercedes RFC #102, and is an official modi- fication of Document #1. A revision of Document #1 will be written shortly which incorporates the changes listed here.
NCP implementers are to incorporate these changes as soon as possible. NCP implementers also are to estimate on what date theis NCP’s will be ready and to communicate this estimate to Steve Crocker or his secretary, Byrna Kristel.
Heretofore, a connection has been a bit stream. Henceforth, it is to be a byte stream, with the byte size, S, indicated in the STR command and in each message. The byte size meets the constraints: 1 <= S <= 255.
The choice of the byte size for a connection is a 3rd level protocol issue, but the size is constant for the life of a connection. Each message must contain an integral number of text bytes (see below).
II Message Format
The message format is changed to the format shown in figure 1.
The fields S and C are the byte size and byte count, respectively. The S field is 8 bits wide and must match the byte size specified in the STR which created the connection. The C field is 16 bit long and specifies the number of bytes in the text portion of the message. A zero value in the C field serves no purpose, but is explicitly permitted.
The M1 and M2 field are each 8 bits long and must contain zero. The M3 field is zero or more bits long and must be all zero. The M3 may be used to fill out a message to a word boundary. It is followed by padding.
The text field consists of C bytes, where each byte is S bit long. The text field starts 72 bits after the start of the message.
The partition of a byte stream into messages is an artifact required by the subnet. No semantic contents be attacched to message boundaries. In particular,
32 bits |<--------------------------------->|
+-----------------------------------+ | | | leader | | | +--------+--------+-----------------+ | | | | | M1 | S | C | | | | | +--------+--------+-----------------+ | | ^ | ...