From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc39.txt | 171 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 171 insertions(+) create mode 100644 doc/rfc/rfc39.txt (limited to 'doc/rfc/rfc39.txt') diff --git a/doc/rfc/rfc39.txt b/doc/rfc/rfc39.txt new file mode 100644 index 0000000..6581728 --- /dev/null +++ b/doc/rfc/rfc39.txt @@ -0,0 +1,171 @@ + + + + + + +Network Working Group E. Harslem +Request for Comments: 39 J. Heafner + RAND + 25 March 1970 + + + COMMENTS ON PROTOCOL RE: NWG/RFC #36 + + We offer the following suggestions to be considered as additions to + the April 28th 1970 protocol grammar specifications. + + ERROR MESSAGES + + + + It is desirable to include debugging aids in the initial protocol for + checking out Network Control Programs, etc. + + There are three classes of errors--content errors, status errors, and + resource allocation or exhaustion. specifies the class and the + offending member of the class. The command is returned to the + sending NCP for identification and analysis. + + Examples of status errors are: messages sent over blocked links and + attempts to unblock an unblocked link. Examples of content errors + are: an invalid RFC complete; a message sent on a link not connected; + closing of an unconnected link; and an attempt to unblock an + unconnected link. Examples of resource errors are: a request for a + non-existent program and connection table overflow, etc. Resource + errors should be followed by a in response to the . + + QUERIES + + < > + + or + + Queries provide an extension to the facility as well as limited + error recovery, thus avoiding re-initialization of an NCP. + + The first command requests the remote NCP to supply the status of all + connections to the user specified by the user number in . + The second is the reply; contains the connection status + information. If an NCP wants the status of all connections to a + remote HOST, the is zero. + + + + + + +Harlsem & Heafner [Page 1] + +RFC 39 COMMENTS ON PROTOCOL RE: NWG/RFC #36 March 1970 + + + PROGRAM TERMINATION NOTIFICATION + + + + This command supplements rather than replaces . It severs all + communication between a program and those programs in a given HOST to + which it is connected. This command performs what would otherwise be + handled by multiple commands. contains the sender's + user number. + + HOST STATUS + + + + + These messages (HOST coming up and HOST voluntarily going down) are + compatible with asynchronous, interrupt-driven programs, as opposed + to the more conventional post/poll method. + + TRANSMIT AND BROADCAST + + + + + Unlike the previous commands, these are not sent over the control + link, but rather over links assigned to user programs. The prefix of + or indicates, to the receiving NCP, the disposition of + the message body. indicates a message to be passed to a single + process. specifies to the destination NCP that the message is + to be distributed over all receiving connections linked to the + sender. In response to a system call by the user to an NCP + requesting , the NCP generates one to each HOST to which + the sender is connected. + + RFC AND DYNAMIC RECONNECTION + + This protocol is complex; it proliferates control messages; it causes + queues (to become associated with re-entrant procedures) that are + artificially imposed via the protocol (remote AEN assignment); and + discounts the situation where only controlling process "A" has + knowledge that slave process "B" should be "rung out" in a dynamic + reconnection. + + The , etc., are suggestions for inclusion as additions in the + April 28th protocol specifications. The above criticism is, of + course, not intended to affect modification of the RFC structure by + April 28th, nor to reflect on those who planned it. We have not + studied the problem. It is meant, however, to voice our concern + + + +Harlsem & Heafner [Page 2] + +RFC 39 COMMENTS ON PROTOCOL RE: NWG/RFC #36 March 1970 + + + about complexity and resulting response times. This is a difficult + problem and it deserves more study after we have exercised the + current RFC specifications. We hope to offer constructive + suggestions with respect to the RFC in the future. + + + + JFH:hs + + + [ This RFC was put into machine readable form for entry ] + [ into the online RFC archives by Mario Vitale 08/99 ] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Harlsem & Heafner [Page 3] + -- cgit v1.2.3