Comments on RFC 123
A short complaint that the 32-bit initial connection rule is awkward for 36-bit machines.
Bhushan, A.K., "Comments on RFC 123", RFC 148, DOI 10.17487/RFC0148, May 1971, <https://www.rfc-editor.org/info/rfc148>.
@misc{rfc148,
series = {Request for Comments},
number = 148,
howpublished = {RFC 148},
publisher = {RFC Editor},
doi = {10.17487/RFC0148},
url = {https://www.rfc-editor.org/info/rfc148},
author = {A.K. Bhushan},
title = {{Comments on RFC 123}},
pagetotal = 1,
year = 1971,
month = may,
} RFC text
Network Working Group A. Bhushan
Request for Comments # 148 MIT -- Project MAC
NIC # 6751 7 May 1971
Categories: D.1
Comments on RFC #123
--------------------
The requirement that byte size 's' be 32-bits for
the initial connection imposes some severe strains on some of
the 36-bit machines. For example, in our PDP-10 (DMCG-
ITS) NCP, we have at present no way of sending or receiving
exactly 32-bits of data. Data is transmitted either in
image mode (36-bit bytes) or in ASCII mode (8-bit characters
with the 8th bit as zero). Perhaps we should permit the
server to send more than 32-bits (say 72-bits) where the
remaining bits could be NULL fillers. The byte size
's' for the connection may be fixed at 8-bits.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by BBN Corp. under the ]
[ direction of Alex McKenzie. 12/96 ]
AI ELI5
On this page
§1The Problem with a 32-Bit Initial Connection
A. Bhushan of MIT Project MAC comments on RFC 123. That RFC requires the byte size s to be 32 bits for the initial connection. The author says this puts severe strains on some of the 36-bit machines.
The example is their PDP-10 (DMCG-ITS) NCP, which has no way of sending or receiving exactly 32 bits of data at present.
The rule asks for exactly 32 bits, but their computer can only handle data in bigger or different-sized pieces.
§2Why It Is Hard and What Is Suggested
Their NCP transmits data either in image mode, which uses 36-bit bytes, or in ASCII mode, which uses 8-bit characters with the 8th bit as zero. Neither gives exactly 32 bits.
The suggestion is to permit the server to send more than 32 bits (say 72 bits), where the remaining bits could be NULL fillers. The byte size s for the connection may then be fixed at 8 bits.
Let the sender use a bigger envelope and fill the extra room with blank paper, so machines with odd hand sizes can still play.
§3Scope of the Comment
The note is one short paragraph. It is phrased as a suggestion ("Perhaps we should permit...") and gives no formal protocol text. The RFC text does not record how the comment was received.
It is a polite suggestion, not an order. Nobody wrote down here what happened next.