Browse Prior Art Database

Conversations with S. Crocker (UCLA) (RFC0049) Disclosure Number: IPCOM000003631D
Original Publication Date: 1970-Apr-01
Included in the Prior Art Database: 2019-Feb-11
Document File: 5 page(s) / 8K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

E. Meyer: AUTHOR

Related Documents

10.17487/RFC0049: DOI

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 26% of the total text.

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...