Browse Prior Art Database

Output of the Host-Host Protocol glitch cleaning committee (RFC0102) Disclosure Number: IPCOM000004865D
Original Publication Date: 1971-Feb-22
Included in the Prior Art Database: 2002-Jan-29
Document File: 5 page(s) / 9K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

S.D. Crocker: AUTHOR


At the NWG meeting in Urbana on 17-19 February 1971, a committee was established to look at the Host/Host protocol and see what changes were immediately desirable or necessary.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 44% of the total text.

Network Working Group                            Steve Crocker, Chairman

Request for Comments: 102                              at BBN, Cambridge

NIC#5763                                            22, 23 February 1971


                       GLITCH CLEANING COMMITTEE

   At the NWG meeting in Urbana on 17-19 February 1971, a

   committee was established to look at the Host/Host protocol

   and see what changes were immediately desirable or necessary.

   The committee is chaired by Steve Crocker, and has eight

   other members:

             Ray Tomlinson                 BBN (Tenex)

             Jim White                     UCSB

             Gary Grossman                 Illinois

             Tom Barkalow                  Lincoln (TX2)

             Will Crowther                 BBN (IMPs)

             Bob Bressler                  MIT (Dynamic Modeling

             Doug McKay                    IBM (Yorktown)

             Dan Murphy                    BBN (Tenex)

   A number of topics were discussed.  On some of these topics, a

   consensus was reached on whether or not to recommend a change, and if

   so, what the change should be.  On the remaining topics, specific

   alternatives were proposed but no consensus was reached.

   The committee will immediately canvas the network community and

   gather reaction to its recommendations and the proposed alternatives.

   The committee will then reconvene at UCLA on 8 March 1971 and decide

   on final recommendations.  Steve Crocker will then write Document #2.

   This sequence is in lieu of the change procedure outlined in NWG/RFC


Crocker                                                         [Page 1]


   Specific Recommendations

   1. The ECO and ERP command should each be 8 bits long.

   2. The ERR command should be 96 bits long.

   3. Message Data Types should be eliminated.  Third-level protocol

      people may reinstate such a mechanism.

   4. The Cease mechanism should be discontinued.

   5. A new pair of one byte commands RST (reset) and RRP (reset reply)

      should be added.  The RST should be interpreted as a signal to

      purge the NCP tables of any existing entries which arose from the

      sending Host.  The RRP command should be returned to acknowledge

      receipt of the RST.  The Host sending the RST may proceed after

      receiving either a RST or a RRP in return.  A RST may be returned

      if the second Host comes up after the first Host.

   6. Although it was suggested at the Urbana meeting that connections

      should be full-duplex, the committee recommends against this


   7. Messages should be an integral number of bytes, and the number of

      bytes and the byte size should be specified in each message.  The

      marking convention should be abandoned and the padding ignored.

      The number of bytes in the message should be a 16-bit number

      following the leader.  The byte size should be in the next 8-bit

      field.  Two suggestions were generated for the starting point of

      the text, and these are explained in the next session.

      For flow control purposes, the number of bits in a message is the

      product of the number of bytes and the byte size.  The leader and

      other fixed format fields are not counted.

   8. The problem of synchronizing the interrupt signal in a console

      input stream was considered.  We consider the console input

      scanner as a process and note two reasonable implementations: it

      may either read characters as...