Browse Prior Art Database

Output of the Host-Host Protocol Glitch Cleaning Committee (RFC0107)

IP.com Disclosure Number: IPCOM000001878D
Original Publication Date: 1971-Mar-01
Included in the Prior Art Database: 2019-Feb-10
Document File: 12 page(s) / 12K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R.D. Bressler: AUTHOR [+5]

Related Documents

10.17487/RFC0107: DOI

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 22% of the total text.

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

[Page 1]

Introduction

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.

[Page 2]

Modifications

I Bytes

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,

[Page 3]

32 bits |<--------------------------------->|

+-----------------------------------+ | | | leader | | | +--------+--------+-----------------+ | | | | | M1 | S | C | | | | | +--------+--------+-----------------+ | | ^ | ...

Processing...
Loading...