RFC 48 (rfc48) - Page 2 of 18
Possible protocol plateau
Alternative Format: Original Text Document
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