Browse Prior Art Database

Conversations with S (RFC0049)

IP.com Disclosure Number: IPCOM000003631D
Original Publication Date: 1970-Apr-25
Included in the Prior Art Database: 2000-Sep-13
Document File: 5 page(s) / 12K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

Crocker (UCLA). E. Meyer: AUTHOR

Abstract

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

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 23% 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

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