Bytes
An open question about different byte sizes at the two ends of a connection.
Postel, J., "Bytes", RFC 128, DOI 10.17487/RFC0128, April 1971, <https://www.rfc-editor.org/info/rfc128>.
@misc{rfc128,
series = {Request for Comments},
number = 128,
howpublished = {RFC 128},
publisher = {RFC Editor},
doi = {10.17487/RFC0128},
url = {https://www.rfc-editor.org/info/rfc128},
author = {J. Postel},
title = {{Bytes}},
pagetotal = 2,
year = 1971,
month = apr,
} RFC 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
BYTES
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 byte sizes and consider bits as the
basic unit (Case II.A.). This does not rule out our considering the
second subcase (Case II.B.). We may allow 3rd level programs to
specify a library or user supplied routine to perform the
transformation between sender and receiver bytes. Perhaps these
transformation routines would be written in the Data Reconfiguration
Language.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Duncan de Waal 03/98 ]
ISO Plain Language
On this page
§1The Byte-Size Mismatch
The second-level protocol allows sender and receiver to specify byte sizes to the NCP. Jon Postel says it is unclear what to do when the two values differ.
The note presents two main interpretations: treat the connection as illegal, or require the NCP to parse data from the sender and then parse it again for the receiver.
The two ends of a connection may group bits into bytes of different sizes. The note asks whether the connection should be refused or the NCP should handle the difference.
§1Reparse Bits or Transform Bytes
Under the reparsing approach, the NCP buffers the incoming stream according to the sender's byte size and then reads it according to the receiver's size. The example uses sender bytes of 5 bits and receiver bytes of 3 bits, treating bits as the basic unit.
A second subcase treats bytes as the significant unit and considers padding, truncation or another transformation. The note asks whether these transformations should be supplied by third-level programs.
One option is to treat the stream as bits and regroup them for the receiver. Another is to transform each sender byte into a receiver byte, perhaps using a routine provided by a higher-level program.
§1UCLA's Tentative Approach
UCLA-Computer Science is considering allowing different byte sizes at the two ends and treating bits as the basic unit. The note says this does not rule out considering transformations, including a library or user-supplied routine that a third-level program specifies.
These are considerations, not a final rule in RFC 128.
UCLA is considering allowing different byte sizes and regrouping bits. It also leaves open whether programs should provide other transformations.