RFC 44 Comments on NWG/RFC 33 & 36 April 1970
III. After a connection has been established, we see no reason for
keeping the "foreign socket" in a local connection table. Since
there is a one-to-one correspondence between a link number of
the foreign Host and a foreign socket number, we can use the
link number in the commands. Thus, except for the RFC command,
all commands can use link numbers and therefore eliminate a 40-
bit foreign socket number in every entry of the connection table
(size being critical for some Hosts). We note that if
connections will be multiplexed over links as suggested in RFC
#38, then the foreign socket would be needed in the connection
table.
IV. In RFC#33 the term PORT was introduced. Although this is
private to every Host, we have a comment. If ports are used
such that there is a one-to-one correspondence between a port
for some user and a socket, then ports are completely redundant.
However, a Host may wish to multiplex ports over connections, in
which case an additional mechanism is needed.
To summarize the last four comments, we suggest that in the initial
version the following system calls and commands will be used (most of
them in RFC 33 and 36).
System Calls:
1) INITIATE
2) ACCEPT
3) SWITCH
4) LISTEN
5) CLOSE
6) TRANSMIT
Commands: Commands 0, 1, 3, 4 as in RFC #36 (pp.5) and in addition: 1) BLOCK: BLK
2) CLOSE: CLS
V. In addition to the above it seems necessary to decide on the following issues one way or the other together with the first version of the protocol (perhaps by setting a date for people to express their preferences and decide accordingly). All of these issues were mentioned in the meeting at UCLA on March 17, 1970, but were put aside. 1. "Double padding" - when a message does not end on a word boundary. Two possible solutions were mentioned: a) Hosts provide their padding in addition to the IMP's padding (double padding). Shoshani, et al.
