Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

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

IP.com Disclosure Number: IPCOM000001878D
Original Publication Date: 1971-Mar-23
Included in the Prior Art Database: 2002-Jan-29
Document File: 13 page(s) / 18K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R.D. Bressler: AUTHOR [+6]

Abstract

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.

This text was extracted from an ASCII text 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        |

                |        |        |                 |

                +--------+--------+-----------------+

                |        |        ^                 |

...