Conversations with S. Crocker (UCLA)
RFC 49

Document Type RFC - Unknown (April 1970; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 49 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
NWG/RFC 49      Conversations with Steve Crocker (UCLA)

                          Edwin W. Meyer, Jr.
                            MIT Project MAC
                             April 25, 1970

   (Both my personal opinions and those that I believe represent a
   consensus of the Network Working Group at Project MAC are presented
   here.  The pronouns "I" and "we" are used to distinguish between
   these.)

On April 21 and 23 Thomas P. Skinner and I had telephone conversations
with Steve Crocker at UCLA relating to the network protocol,
specifically regarding our proposal in NWG/RFC 46.  The following items
were discussed.  (I hope that Steve will pardon me if I happen to
misparaphrase him.)

1) Steve stated that he felt that a need for dynamic reconnection would
later be recognized by the network participants.  However, because of a
lack of consensus, it will not be included in the initial
implementation.  (We at Project MAC favor this approach of not including
it initially.)

2) Steve supported the implementation of the INT network command
described in NWG/RFC 46.

This command allows a process that has agreed to accept interrupts over
a socket connection to be reliably interrupted by the process at the
other end.  The interrupt causes a process to abey its current execution
and execute a procedure that it has specified as the INT handler.  (The
NCP does not specify the INT handler.  That is the function of higher
level protocols.)

The INT command is designed specifically for use by a third level User
Control and Communication (UCC) protocol to implement a "quit" signal.
Under such a protocol, both the requestor and the created process agree
that an INT related to a specific socket connection and transmitted over
the NCP control link to the created process is the standard "quit"
signal.  The created process provides an INT handler that implements
this "quit" function.  (This does not preclude a different
interpretation of INT by other third level protocols.)

Although many systems implement the "quit" as a control character in the
Teletype input stream, systems such as CTSS, Multics, and others
implement it as a 200 ms spacing on the line.  We at MAC think that the

                                                                [Page 1]
NWG/RFC 49      Conversations with Steve Crocker (UCLA)

first method is an undesirable implementation within the network (while
the second is impossible).  I put forth several reasons why (and I think
Steve agreed).

(a) The link over which the quit character is to be transmitted may be
blocked.

(b) While the interrupt is most effectively implemented within the NCP,
it is undesirable for the NCP to place any particular structure on the
data being transmitted.  (See discussion below.)  This would be required
if the NCP were to scan a data stream for a control character.

(c) Scanning the input stream greatly reduces NCP efficiency in a
subsystem where speed is critical to effective operation.

Steve pointed out that the implementation of INT as a "quit" should not
necessarily preclude a HOST's interpretation of a control character in
the input stream from also acting as a "quit".

3) Steve is opposed both to including the instance tag in the socket
identifier and reserving a null field in the identifier for future
definition.  He cited several reasons:

(a) Multiple processes of a single user should be indistinguishable to a
foreign process.  (I agree with this in certain cases when processes are
co-ordinated in joint action.  But what about the case where two
processes of the same user both want to independently use the network?)

(b) A process wishing to connect to one of a foreign user's processes
does not know the instance tag of the particular process that he wants,
and he can't easily find out.

(c) If an instance tag should later prove desirable it could be added
with some difficulty.  (I claim that something as fundamental as the
length of a socket identifier will prove very resistant to change.)

Tom stated that perhaps the low order three bits of the user code could
be reserved for later interpretation as an instance tag.  He doesn't
think that a separate field is of great importance.

Steve's arguments seem to have merit.  Perhaps Tom's suggestion is the
way to go.  I am currently undecided on this matter.

4) We all (Steve and MAC) seem to agree that at the NCP level there
should be no special structure imposed on the data transmitted.  To an
NCP all data to be transmitted are bit strings of arbitrary length.  One

                                                                [Page 2]
NWG/RFC 49      Conversations with Steve Crocker (UCLA)

happy result is that the difficult question of character sets does not
have to be resolved at this protocol level.  To include a character set
specification at the NCP level would delay agreement on the protocol and
make this character set more resistant to change.  (If there is to be a
standard character set, we prefer ASCII.  After all, it is the prefered
Show full document text