Possible protocol plateau
RFC 48

Document Type RFC - Unknown (April 1970; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 48 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                          J. Postel
Request for Comments: 48                                      S. Crocker
                                                          April 21, 1970

                      A Possible Protocol Plateau

I. Introduction

   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

Postel & Crocker                                                [Page 1]
RFC 48                A Possible Protocol Plateau             April 1970

         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 solutions are also available.  One is to have "double
         padding", whereby the sending Host supplies 10* and the network
         also supplies 10*.  Upon input, a receiving Host then strips
         the trailing 10* 10*.  The other solution is to make use of the
         marking.  Marking is a string of the form 0*1 inserted between
         the leader and the text of a message.  The original intent of
         marking was to extend the leader so that the sending Host could
         _begin_ its text on a word boundary.  It is also possible to
         use the marking to expand a message so that it _ends_ on a word

         Notice that double padding could replace marking altogether by
         abutting the text beginning against the leader.  For 32 bit
         machines, this is convenient and marking is not, while for
         other lengths, particularly 36 bit machines, marking is much
         more convenient than double padding.

         We have no strong preference, partially because we can send
         word fragments.  Shoshani, et al in NWG/RFC #44 claim that
         adjusting the marking does not cause them any problems, and
         they have a 32 bit machine.  Since the idea of marking has been
         accepted for some time, we suggest that double padding not be
         used and that marking be used to adjust the length of a
         message.  We note that if BBN ever does remove the 1 from the
         hardware padding, only minimal change to Host software is
         needed on the send side.

         A much prettier (and more expensive) arrangement was suggested
         by W. Sutherland.  He suggested that the Host/Imp interfaces be
         smart enough to strip padding or marking and might even parse
         the message upon input.
Show full document text