Comments on RFC 123
J. Postel's April 1971 step-by-step reading of the NCP message exchange behind the Initial Connection Protocol.
Postel, J., "Comments on RFC 123", RFC 127, DOI 10.17487/RFC0127, April 1971, <https://www.rfc-editor.org/info/rfc127>.
@misc{rfc127,
series = {Request for Comments},
number = 127,
howpublished = {RFC 127},
publisher = {RFC Editor},
doi = {10.17487/RFC0127},
url = {https://www.rfc-editor.org/info/rfc127},
author = {J. Postel},
title = {{Comments on RFC 123}},
pagetotal = 2,
year = 1971,
month = apr,
} RFC text
Network Working Group J. Postel
Request for Comments # 127 20 April 71
NIC #5843 UCLA
[Category D.1 Computer Science
Updates 123]
Comments on RFC 123
The following is my interpretation of the exchange between NCP's which
would be necessary to carry out the Initial Connection Protocol of RFC
123.
Server NCP User NCP
---------- --------
Listen for Connection on L RTS, U, L, l
STR, L, U, 32 A
Send 32 bits of data
in 1 message on link l
A
(value is S) Receive 32 bits of data
from link l (value is S)
A
CLS, L, U CLS, U, L
STR, S+1, U, B STR, U+1, S, B
s u
RTS, S, U+1, l RTS, U, S+1, l
B c
wait for connection wait for connection
ALL, l , m , b ALL, l , m , b
B B B c c c
data sent on link l data sent on link l
c B
data received on link l data received on link l
B c
l , l , and l are links, m and m are message allocations, b
A B c B c B
and b are bit allocations, and all other symbols are as defined in
c
RFC 123.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Gert Doering 4/97 ]
AI ELI5
On this page
§1An Interpretation of RFC 123
J. Postel of UCLA offers his interpretation of the exchange between Network Control Programs (NCPs) needed to carry out the Initial Connection Protocol of RFC 123. The document is marked as updating RFC 123.
It is a single two-column table, one column for the server NCP and one for the user NCP. All symbols not explained on the page are defined in RFC 123.
One person's idea of the exact lines each side says when two computers first connect.
§2The Message Exchange
The server NCP listens for a connection on L. The user NCP sends RTS, U, L, l, and the server replies STR, L, U, 32. The server then sends 32 bits of data in one message on a link, with value S, and the user receives it.
Both sides then send a CLS. After that the server sends STR, S+1, U, B and RTS, S, U+1, l, while the user sends STR, U+1, S, B and RTS, U, S+1, l. Each side waits for the connection, sends an ALL, and data then flows on the links.
The note closes by explaining that the l, m and b symbols with subscripts are links, message allocations and bit allocations.
First one side knocks, the other sends back a number, and they hang up. Then each uses that number to call the other back on two new lines, and they can finally talk.
- RTS, U, L, lServer is listening for a connection on L.
- STR, L, U, 32
- 32 bits of data (value S)Sent in 1 message on a link.
- CLS, L, U
- CLS, U, L
- STR, S+1, U, B and RTS, S, U+1, l
- STR, U+1, S, B and RTS, U, S+1, l
§3Where It Fits
The note carries no discussion of design or security. It exists to make the ICP of RFC 123 concrete as a sequence of NCP commands. The metadata lists it as updated by RFC 151 and replaced by RFC 145.
For the commands named here (RTS, STR, CLS, ALL), consult the RFC 123 symbols the page refers to rather than this table alone.
It is a script, not a rule book. Later notes fixed it up.