Browse Prior Art Database

Bytes (RFC0128) Disclosure Number: IPCOM000004871D
Original Publication Date: 1971-Apr-01
Included in the Prior Art Database: 2019-Feb-10
Document File: 2 page(s) / 2K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

J. Postel: AUTHOR

Related Documents

10.17487/RFC0128: DOI

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

Network Working Group J. Postel Request for Comments: 128 UCLA Category: C.2, D. Computer Science NIC #5844 21 April 71 Obsoletes: none Updates: none


It is somewhat unclear what to do with the Byte size parameter now allowed by the 2nd level protocol. I can conceive of an implementation in which the 3rd level programs never see this parameter. Crocker implies in RFC 123 that control of this parameter is given to the 3rd level programs and that both sender and receiver may specify values of the byte size to the NCP.

There are at least two interpretations if the sender and receiver specify different byte sizes.

I. The first is that the connection is illegal.

II. The second is that the NCP must parse the data stream on receipt from the network and into a buffer according to be byte size of the sender, and subsequently parse the data stream on transfer from the buffer to the receiver. In this second case there are two sub cases.

A. One is to consider bits as the basic unit.

For example, if the sender specified byte size = 5 and the receiver specified byte size = 3 then

Receiver NCP Sender -+---+---+---+---+ +--------+ +-----+-----+--- |000|001|010|011| <--- | Buffer | <--- |00000|10100|11 -+---+---+---+---+ +--------+ +-----+-----+---

B. The other is to consider bytes as the significant unit and pad (on the right or left?) or truncate to make things fit, or other transformation.

At UCLA-Computer Science we are contemplating allowing sender and receiver to specify different...