1 files changed, 324 insertions, 0 deletions
diff --git a/doc/rfc/rfc56.txt b/doc/rfc/rfc56.txt
new file mode 100644
index 0000000..3e0b2b2
--- /dev/null
+++ b/doc/rfc/rfc56.txt
@@ -0,0 +1,324 @@
+
+
+
+
+
+
+Network Working Group                                Ed Belove (Harvard)
+Request for Comments: 56                            Dave Black (Harvard)
+                                                       Bob Flegel (Utah)
+                                                 Lamar G. Farquar (Utah)
+                                                               June 1970
+
+
+                          Third Level Protocol
+
+                            Logger Protocol
+
+                          General Description
+
+
+In our view of the world each host has a set of four programs to allow a
+user teletype to communicate with a foreign monitor. The exact
+implementation of these programs is highly installation-dependent.  Thus
+all explanations are meant to describe functional characteristics rather
+than design.
+
+The four programs come in two male/female pairs. A user employs a send-
+logger at his site to communicate with receive-logger at the appropriate
+foreign site in order to establish a full duplex link between the user's
+teletype and the foreign machine's monitor. This puts him in the
+equivalent of a pre-logged in state at the other machine.  After the
+link has been established, the two loggers drop out of the picture, and
+the user is left talking to a sender in his machine, whose main function
+is to take input from the user's teletype and send it down the link that
+was established by the loggers to the receiver in the foreign host which
+passes it along to its monitor (making it look like input from a local
+teletype). Replies from the foreign monitor are given by it to the
+receiver, which transmits them back along the link to the sender, which
+outputs them on the user's teletype. The sender and receiver in each
+machine must either exist in multiple copies, one for each network user,
+or there must be a single copy which can handle all of the network
+users. The loggers, however, need be able to handle only one user at a
+time, since their task is quickly accomplished, leaving them free to
+satisfy other requests.  However there should be some method of queuing
+requests that can not be satisfied immediately. A less satisfactory
+alternative would be to give a busy message to any user who tries to use
+the logger while it is busy. (This, of course, does not preclude the
+possibility of an installation having a re-entrant logger, or of having
+multiple copies of the logger.)
+
+The receive-logger should be user zero in every machine and should
+always be listening to socket zero. (This same thing can be accomplished
+by having the NCP intercept all messages to user zero, socket zero, and
+send them to the receive-logger; but it is simpler and cleaner to have
+
+
+
+                                                                [Page 1]
+
+the logger actually be user zero and have the NCP handle its messages
+the same as everyone else's.)
+
+When the send-logger is called, it pulls a pair of unused sockets (2N
+and 2N+1) from a pool of free sockets and CONNECT from 2N+1 to User 0,
+Socket 0 in the desired foreign host. This activates the receive-logger,
+which accepts the connection if it has an available slot for the foreign
+teletype. He then immediately closes down this connection to allow links
+from other sources to be initiated. If, on the other hand, there is no
+room for the foreign teletype (or if, for some other reason, the
+receive-logger does not wish to connect) the attempted link to socket
+zero is refused. This notifies the send-logger that he cannot log on the
+foreign host and it then notifies the user of this fact. There is no
+guarantee, however, that the close was actually sent by the foreign
+logger. It could have been sent by the NCP if, for example, the pending
+call queue for the socket was overloaded.
+
+If the link to socket zero has been accepted (thus indicating that the
+receive-logger can accommodate the request) after closing that link, the
+receive-logger picks an available pair of sockets (2M and 2M+1) from its
+pool, and connects from 2M+1 to 2N. (It found the identity of 2N when
+its listen was answered by the link with 2N+1.)  The send-logger has
+meanwhile listened to socket 2N and now accepts the link, and CONNECTS
+from 2N+1 to 2M. The receive-logger has been listening to this socket
+and accepts the attempted link.
+
+At this point, there is a full duplex connection between the two
+loggers. They then activate the sender and receiver, which handle all
+other communication between the user and the foreign monitor.  (The
+senders and receivers can be part of the loggers, or can be called by
+them, etc.)
+
+When the user is finished and escapes back to his monitor, it is up to
+the sender to close down the links. On the receiving end, it would be
+highly desirable for the NCP to notify the receiver of this fact, so it
+could log the user off (if he had failed to do that himself) and could
+free any resources that he had been using.
+
+A more formal outline of the proposed protocol described in the scenario
+above follows:
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 2]
+
+   1. Stable state: receive-logger at foreign host listening to User 0,
+   Socket 0.
+
+   2. Local user calls send-logger.
+
+   3. Send-logger calls CONNECT (port, 2N+1, <foreign host#,0,0>).
+
+   4. Send-logger calls LISTEN (port, <local host#, user#, 2N>).
+
+   5. Foreign logger's LISTEN is answered, and he is told local user
+   number, host and #2N+1.
+
+   6. Foreign logger looks for available sockets (2M and 2M+1).  If they
+   exist and it is able to establish connection, it accepts and then
+   immediately closes the link.
+
+   7. Foreign logger calls CONNECT (port, 2M+1, <local host#, user#,
+   2N>).
+
+   8. Foreign logger calls LISTEN (port, <local host#, user#, 2M>).
+
+   9. Send-logger has listened to 2N and accepts link, then calls
+   CONNECT (port, 2N+1, <foreign host#, user#,2M>).
+
+   10. Receive-logger, which is listening on 2M, accepts link.
+
+   11. Loggers activate appropriate handlers.
+
+   12. When the user is finished, sender closes down both links.
+
+This basic method of establishing a full duplex connection should be
+standard throughout the network. The particular way each installation
+handles the implementation of the sender, receiver, and the two loggers
+is of no consequence to the network and is highly machine dependent.
+(Even the fact of needing a sender and receiver is machine dependent in
+that some members of the network might be able to handle their functions
+in other ways.) However, some conventions must be established regarding
+communication between the sender and receiver, or their equivalents.
+
+Network Standard Code
+
+In order to facilitate use of the network, we propose the convention
+that all teletype-to-foreign-monitor communication be done using 128
+character USASCII. (This is the code used by the IMP's and is in the
+appendix to the IMP operating manual.) It makes sense to require
+machines to make only one conversion to a standard code, than to have to
+make conversions to every code on the net.
+
+
+
+
+                                                                [Page 3]
+
+In addition, since most of the network machines use ASCII as their
+internal character code, it will be no trouble for them. Even those
+machines that use a different code must translate to and from ASCII in
+order to communicate with local teletypes. Extending this translation to
+the network should cause very little trouble. We envision this
+translation as taking place in the sender and receiver, but again that
+is implementation dependent.
+
+If ASCII is adopted as a standard, we would suggest that all non-ASCII
+machines create a monitor to the machine's internal code. This would
+make the complete character set available to those who wished to use it
+(and were willing to write a simple conversion routine for the local
+machine.) In this way, those users who wanted to could use any machine
+on the net from their teletype, without requiring their machines to have
+records of all the network codes, and yet could use the full power of
+the foreign machine if they wanted.
+
+Again, this standard applies only for teletype-to-foreign-monitor
+communication.
+
+Break Characters
+
+A standard way of handling the break character has to be established for
+the network and be included in the protocol. Problems with the break
+character arise in several contexts. First, there are two distinct
+purposes served by the break character. One is as a panic button. This
+says, "I do not care what is happening, stop and get me out to monitor
+level now." This command is executed immediately upon receipt, and is
+most commonly used to get out of a program that one does not want to be
+in (e.g., one that is in an infinite loop, etc.)
+
+The other purpose that is served is that of an exit from a subsystem, or
+on a machine with a forking structure as a method to get back to the
+next higher level fork. This second purpose is not an immediate one in
+that the user wants the system to finish all that he has told it to do
+before exiting.
+
+We assume that there does not exist in every system 1) a way of
+performing each of these functions, or 2) a clear cut distinction
+between the calling and operation of the two. Furthermore, there are
+subtle distinctions as to how each system treats the commands.
+
+The panic button function can easily be performed by the proposed
+control command <INT>. This function must be accomplished by using a
+control command, since a program can enter a state where it is accepting
+no input: hence, the program cannot be aborted by sending it a message
+down the teletype link. There is no reason to worry about the race
+condition caused by sending this command down the control link since its
+
+
+
+                                                                [Page 4]
+
+whole purpose is to force the machine to disregard everything else the
+user has sent.
+
+In our implementation of this, we would ask the user to specify to the
+logger a seldom used character that he wants to be his foreign panic
+button. Then, it would be a simple task for the sender to map this
+character into an <INT> command, which the foreign machine must
+interpret properly. This scheme would work well for most machines, but
+some may lend themselves to different ways of generating the <INT>.
+
+The other problem that presents itself is what to do if the foreign
+machine's "exit" character is the same as the local machine's.  The
+problem is that while a user is talking to a foreign machine, he would
+want to be in a transparent mode, where everything he types is sent
+directly to the other machine. The way he would get himself out of this
+mode is to type either his machine's "exit" character or its panic
+button. Thus, if the foreign machine has the same one, there would be no
+way to send it. The way out of this is the same as above--merely a
+mapping of another seldom used character into the foreign machine's
+"exit" character. This type of mapping can be carried as far as each
+installation deems necessary. Giving the user complete control over
+translation is helpful in that it allows him to user characters that his
+teletype cannot generate.
+
+Command Message Formats
+
+Each site should establish its now conventions about when to send a
+monitor command string, and in what size chunks. When performing a
+routine operation, one might want to send several command lines as a
+single message. If working with the monitor as usual, a reasonable break
+point might be at every carriage return. When using a highly interactive
+language such as QED, one might decide character-by-character
+transmission was a necessity. We feel that each user should have the
+choice between these three methods (and possible more). Furthermore, the
+user should be able to change between each mode at will. The differences
+in syntax of the send-message commands mentioned above should be noted.
+For the first, a special send-message command character must be defined,
+and it should not be sent along with the message. For the second, the
+carriage return acts dually as the send-message command and as a command
+delimiter. Therefore it must be sent with the message. Finally, the case
+of character-by-character transmission with its implicit send command
+should pose no significant problems.
+
+
+
+
+
+
+
+
+
+                                                                [Page 5]
+
+The preceding discussion is meant to imply also that the receiver must
+be able to buffer up each of the above types of transmission into a form
+acceptable to its own monitor interface.
+
+In addition, all echoing should be done in the local host, with the
+foreign machine suppressing its echoes (if it can.)
+
+
+We would like to thank Carl Ellison (of Utah) for his valuable
+suggestions and criticisms of this work, and Jim Curry (of Utah) for his
+encouragement and support of the effort.
+
+
+       [ This RFC was put into machine readable form for entry ]
+          [ into the online RFC archives by Jon Ribbens 7/97 ]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 6]
+