RFC 48 (rfc48) - Page 2 of 18

Possible protocol plateau

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
         boundary.

         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.





Postel & Crocker