Dismiss
IP.com applications will be updated on Sunday, March 5, from 11 am to 2 pm ET, to add new functionality and content. You may experience brief service interruptions during this period. We apologize for any inconvenience.
Browse Prior Art Database

Possible protocol plateau (RFC0048)

IP.com Disclosure Number: IPCOM000003623D
Original Publication Date: 1970-Apr-21
Included in the Prior Art Database: 2000-Sep-13
Document File: 15 page(s) / 39K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

J. Postel: AUTHOR [+2]

Abstract

We have been engaged in two activities since the network meeting of March 17, 1970 and, as promised, are reporting our results.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 8% 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

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