1 files changed, 218 insertions, 0 deletions
diff --git a/doc/rfc/rfc295.txt b/doc/rfc/rfc295.txt
new file mode 100644
index 0000000..40fdf47
--- /dev/null
+++ b/doc/rfc/rfc295.txt
@@ -0,0 +1,218 @@
+
+
+
+
+
+
+NWG/RFC #295                             JBP 2-JAN-72 15:35  8355
+Protocol Workshop Report
+
+Report of the Protocol Workshop
+
+   12 October, 1971
+
+   By Jon Postel.
+
+Introduction
+
+   This is a report on the decisions reached at the protocol workshop
+   held in conjunction with the Network Working Group meeting held in
+   Cambridge from 10 to 14 October, 1971.
+
+   The workshop addressed itself to protocols of four types: IMP-Host,
+   Host-Host, Initial Connection, and Process-Process.
+
+IMP-Host Protocol
+
+   The idea of IMP provided status reports to be exchanged via new
+   IMP-Host protocol messages was discussed and rejected because it was
+   felt that the level of state information which could be reported was
+   not sufficient to be worth the trouble of implementing this mechanism.
+
+Host-Host Protocol
+
+   The Host-Host Protocol was discussed and several problems were brought
+   to light, among them were the following listed together with the
+   group's recommendations.
+
+      The GVB - RET mechanism may prove useful sometime in the
+      future so it will be retained though no one appears to be
+      using it now, however spontaneous RET commands are
+      explicitly prohibited.
+
+      The ECO - ERP commands are useful and should be supported,
+      but spontaneous ERP commands are explicitly prohibited.  A
+      further restriction is that a second ECO will not be sent
+      until the first ECO has been answered.  Note that any of
+      the following may be an answer to an ECO: ERP, RST,
+      "Destination dead", or "Incomplete Transmission".
+
+      The RST - RRP commands are useful, but the proper use of
+      these commands for determining the status of host software
+      is still open for discussion (please direct comments to Jon
+      Postel), however spontaneous RRP commands are explicitly
+      prohibited.
+
+
+
+                                                                [Page 1]
+
+NWG/RFC #295                             JBP 2-JAN-72 15:35  8355
+Protocol Workshop Report
+
+   The problem of unmatched CLS commands are discussed and four
+   "solutions" were proposed:
+
+      Hold forever
+
+      Send a RST and clear the entry
+
+      Clear the entry and possibly mess up a future connection
+
+      Assign socket numbers in a sequential fashion to reduce
+      the possibility of confusion and clear the entry.
+
+   Note that the first two suggestions follow the protocol while the last
+   two do not.
+
+   The idea of flow control on the control link was suggested.  A Request
+   for Comments is to be prepared exploring this idea more fully.
+
+   The usefulness of the ERR command is compromised if the receiver
+   mearly throws it out.  Thus ERR's are to be logged, if at all
+   possible, and checked out with the sending site.
+
+   The NCP document should make clear the implications of queueing or not
+   queueing STR & RTS commands.
+
+Initial Connection Protocol
+
+   The Initial Connection Protocol (ICP) was discussed and found to be
+   satisfactory however the following points were stressed:
+
+     The socket number sent by the logger (S) must be in
+     agreement with the socket numbers used in the STR & RTS
+     sent by the logger.
+
+     The implications of queueing or not queueing of RTS & STR
+     commands should be made clear in the ICP document.  This is
+     particularly important if the user chooses the "listen"
+     option.
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 2]
+
+NWG/RFC #295                             JBP 2-JAN-72 15:35  8355
+   Protocol Workshop Report
+
+Telnet Protocol
+
+   The Telnet committee has been reactivated to consider the following
+   problems:
+
+     Clarification of the terminology half duplex, full duplex,
+     character mode, line mode, ASCII, and echoing.
+
+     Clarification of the end of line convention. Especially to
+     answer the question "Should there be a special end-of-line
+     character?"
+
+     Clarification of the conditions for leaving Hide-your-input mode.
+
+     Clarification of the operation of Break and Synch.
+
+     Specification of a server-to-user Synch.
+
+     Clarification of the definition of the Network Virtual Terminal.
+
+     Preparation of a new document defining the Telnet protocol
+     with the above improvements.
+
+The protocol workshop did agree that:
+
+  It is the servers option for disconnection to imply logout
+  or not.
+
+  It is the servers option for logout to imply disconnection
+  or not.
+
+  Extra characters used locally to fill the time for format
+  effectors to take effect should not be sent over the
+  network
+
+  Synch means to examine the data stream from the current
+  point to a data mark (x'80').  If any break type characters
+  (e.g. etx, sub, Break) are found they are to have their
+  normal effect.
+
+  Upper and lower case are to be available to all Telnet users.
+
+Data and File Transfer Protocol
+
+   The Data and File Transfer Committee will report separately.
+
+
+
+                                                                [Page 3]
+
+NWG/RFC #295                             JBP 2-JAN-72 15:35  8355
+Protocol Workshop Report
+
+       [ This RFC was put into machine readable form for entry ]
+       [ into the online RFC archives by BBN Corp. under the   ]
+       [ direction of Alex McKenzie.                   12/96   ]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 4]
+