Output of the Host-Host Protocol Glitch Cleaning Committee (RFC0107)
Original Publication Date: 1971-Mar-23
Included in the Prior Art Database: 2002-Jan-29
Internet Society Requests For Comment (RFCs)
R.D. Bressler: AUTHOR [+5]
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.
Network Working Group
Request for Comments # 107
NIC # 5806
Output of the Host-Host Protocol
Glitch Cleaning Committee
23 March 1971
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 <=
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
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
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,
| leader |
| | | |
| M1 | S | C |
| | | |
| | ^ |...