Browse Prior Art Database

Possible protocol plateau (RFC0048) Disclosure Number: IPCOM000003623D
Original Publication Date: 1970-Apr-01
Included in the Prior Art Database: 2019-Feb-11
Document File: 18 page(s) / 25K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

J. Postel: AUTHOR [+1]

Related Documents

10.17487/RFC0048: DOI

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 9% of the total text.

Network Working Group J. Postel Request for Comments: 48 S. Crocker UCLA 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 reasoning.

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