Possible protocol plateau (RFC0048)
Original Publication Date: 1970-Apr-21
Included in the Prior Art Database: 2000-Sep-13
Internet Society Requests For Comment (RFCs)
J. Postel: AUTHOR [+2]
We have been engaged in two activities since the network meeting of March 17, 1970 and, as promised, are reporting our results.
Network Working Group J. Postel
Request for Comments: 48 S. Crocker
April 21, 1970
A Possible Protocol Plateau
We have been engaged in two activities since the network meeting of
March 17, 1970 and, as promised, are reporting our results.
First, we have considered the various modifications suggested from
all quarters and have formed preferences about each of these. In
Section II we give our preferences on each issue, together with our
Second, we have tried to formalize the protocol and algorithms for
the NCP, we attempted to do this with very little specification of a
particular implementation. Our attempts to date have been seriously
incomplete but have led to a better understanding. We include here,
only a brief sketch of the structure of the NCP. Section III gives
our assumptions about the environment of the NCP and in Section IV
the components of the NCP are described.
II. Issues and Preferences
In this section we try to present each of the several questions which
have been raised in recent NWG/RFC's and in private conversations,
and for each issue, we suggest an answer or policy. In many cases,
good ideas are rejected because in our estimation they should be
incorporated at a different level.
A. Double Padding
As BBN report #1822 explains, the Imp side of the Host-to-Imp
interface concatenates a 1 followed by zero or more 0's to fill
out a message to an Imp word boundary and yet preserve the
message length. Furthermore, the Host side of the Imp-to-Host
interface extends a message with 0's to fill out the message to
a Host word boundary.
BBN's mechanism works fine if the sending Host wants to send an
integral number of words, or if the sending Host's hardware is
capable of sending partial words. However, in the event that
the sending Host wants to send an irregular length message and
its hardware is only capable of sending word-multiple messages,
some additional convention is needed.
One of the simplest solutions is to modify the Imp side of the
Host-to-Imp interface so that it appends only 0's. This would
mean that the Host software would have to supply the trailing
1. BBN rejected the change because of an understandably strong
bias against hardware changes. It was also suggested that a
five instruction patch to the Imp program would remove the
interface supplied 1, but this was also rejected on the new
grounds that it seemed more secure to depend only upon the Host
hardware to signal message end, and not to depend upon the Host
software at all.
Two other solution...