Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Thoughts and Reflections on NWG/RFC 54 (RFC0057)

IP.com Disclosure Number: IPCOM000003661D
Original Publication Date: 1970-Jun-19
Included in the Prior Art Database: 2000-Sep-13
Document File: 3 page(s) / 8K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

M. Kraley: AUTHOR [+2]

Abstract

In the course of writing NWG/RFC #54 several new ideas became apparent. Since these ideas had not previously been discussed by the NWG, or were sufficiently imprecise, it was decided not to include them in the official protocol proffering. We thought, however, that they might be proper subjects for discussion and later inclusion in the second level protocol.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 36% of the total text.

Network Working Group Mike Kraley (Harvard)

Request for Comments #57 John Newkirk (Harvard)

June 19, 1970

Thoughts and Reflections on NWG/RFC #54

In the course of writing NWG/RFC #54 several new ideas became

apparent. Since these ideas had not previously been discussed by the

NWG, or were sufficiently imprecise, it was decided not to include them

in the official protocol proffering. We thought, however, that they

might be proper subjects for discussion and later inclusion in the

second level protocol.

I. Errors and Overflow

In line with the discussion in NWG/RFC #48, we felt that two

types of errors should be distinguished. One is a real error, such as

an RFC composed of two send sockets. This type of error can only be

generated by a broken NCP. In the absence of hardware and software

bugs, these events should never occur; the correct response upon

detection of such an event was outlined in the description of the ERR

command in NWG/RFC #54.

The other "error" is an overflow condition arising because

finite system resources are exhausted. An overflow condition could

occur if an RFC was received, but there was no room to create the

requisite tables and queues. This is not a real error, in the sense

that no one has done anything incorrect (expect perhaps the system

planners in not providing sufficient table space, etc.) Further, a

recovery procedure can be well defined, and simply entails repeating the

request at a future time. Thus, we believe an overflow condition should

be distinguished from a real error.

In NWG/RFC #54 an overflow condition was reported by returning

a CLS, as if the connection had been refused. This sequence performs

the necessary functions, and leaves the connection in the correct state,

but the initiating user is misinformed. He is deluded into thinking

that he was refused by the foreign process, when, in fact, this was not

the case. In certain algorithms this difference is crucial.

In further defining error conditions, we felt that it would

be helpful to specify why the error was detected, in addition to

specifying what caused the error. While writing the pseudo-Algol

program mentioned in NWG/RFC #55 we differentiated 9 types of errors

(listed below). We would, therefore, like to propose the extension of

the ERR message to include an 8-bit field following the op code to

designate the type of error. This would be followed by the length and

text fields, as before. We propose these error types;

0. UNSPECIFIED ERROR

1. HOMOSEX (invalid send/rcv pair in an RF...