RFC 80 (rfc80) - Page 1 of 9
Protocols and Data Formats
Alternative Format: Original Text Document
Network Working Group E. Harslem
Request for Comments: 80 J. Heafner
NIC: 5608 RAND
1 December 1970
PROTOCOLS AND DATA FORMATS
Because of recent discussions of protocols and data formats we issue
this note to highlight our current attitudes and investigations in
those regards. We first discuss some specific sequences, and then
offer some thoughts on two general implementation approaches that
will handle these and other specifics. We wish to place emphasis on
the _general solutions_ and not on the specifics.
INITIAL CONNECTION PROTOCOLS
We wish to make two points concerning specific Initial Connection
Protocols (IPCs). Firstly, the IPC described in NEW/RFC #66--its
generality and a restatement of that ICP. Secondly, a proposal for a
variant ICP using basically the same logic as NWG/RFC #66.
I. NWG/RFC #66
The only technical error in this IPC is that as diagrammed both the
Server and User send ALL messages before the connections are
established which is inconsistent with Network Document No. 1. This
can easily be remedied as will be shown in the restatement below.
In terms of generality, any ICP that is adopted as a standard should
apply to more situations than a process calling a logger. That is,
some Network service processes that hook directly to a user process,
independent of logger action, could perhaps use a standard ICP.
Thus, as is shown below, the process name field of the server socket
should be a parameter with a value of zero being a special case for
loggers.
Restatement of NWG/RFC #66 (using the same wording where appropriate)
1. To initiate contact, the using process attaches a receive
socket (US) and requests connection to process SERV socket #1
in the serving HOST. (SERV = 0 for ICP to the logger.) As a
result the using NCP sends:
Harslem, et. al.