Comments on RFC 123
A step-by-step interpretation of the NCP exchange for 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 ]
ISO Plain Language
On this page
§1A Reading of the Initial Connection Protocol
J. Postel describes his interpretation of the exchange between Network Control Programs (NCPs) needed to carry out the Initial Connection Protocol in RFC 123. The document presents the exchange as a two-column table, with one column for the server NCP and one for the user NCP.
The note says that symbols not explained in its table are defined in RFC 123.
This note shows the messages that each NCP sends during connection setup. It is an interpretation of RFC 123, not a separate detailed protocol specification.
§2The NCP Message Exchange
The server NCP listens for a connection on L. The user NCP sends RTS, U, L, l; the server responds with STR, L, U, 32 and sends 32 bits of data in one message on link l. The user receives the data, whose value is S.
Both sides then send CLS. They exchange further STR and RTS messages, wait for the connections, and send ALL allocations. The table then shows data sent and received on link l. The note defines its subscripted symbols as links, message allocations, and bit allocations.
The table first shows the server sending 32 bits to the user, then both sides closing that link. They establish further links and allocations before exchanging data.
§3How This Note Fits
RFC 127 is a comment that sets out one author's interpretation of the NCP exchange in RFC 123. The note points readers back to RFC 123 for the meanings of symbols it does not define.
The unit metadata says RFC 127 updated RFC 123, was later updated by RFC 151, and was obsoleted by RFC 145.
This document is a step-by-step explanation of an earlier connection procedure. RFC 145 later obsoleted it.