doc: Add RFC documents

1 files changed, 165 insertions, 0 deletions

diff --git a/doc/rfc/rfc230.txt b/doc/rfc/rfc230.txt
new file mode 100644
index 0000000..5c79949
--- /dev/null
+++ b/doc/rfc/rfc230.txt
@@ -0,0 +1,165 @@
+
+
+
+
+
+
+Network Working Group                           T. N. Pyke, Jr.
+Request for Comments  230                       NBS
+NIC 7647                                        24 September 1971
+Category: C5
+Reference #203
+
+
+                       TOWARD RELIABLE OPERATION
+                OF MINICOMPUTER-BASED TERMINALS ON A TIP
+
+
+
+       The present protocol for communication between a TIP and
+attached terminals requires character-oriented transmission and
+provides for no error control. In the design of this protocol, it was
+apparently assumed that the majority of terminals attached to a TIP
+would be interactive, be normally used in a character-by-character
+mode both for transmission to and from the terminal, and normally
+support a human user who would in effect be in the communication loop.
+The human user would thus be in a position to detect any significant
+telecommunication-induced errors both by direct observation of the
+character stream and, more importantly, by examining the computer
+output in the context of his ongoing interaction.
+
+       The effectiveness of this means for error detection and
+initiation of corrective measures when necessary is not adequate in
+the following cases:
+
+     a. For terminal-TIP communication at a medium or
+     higher data rate (say 1200 bps or higher) it is quite possible
+     that the human will skim computer output and not be an
+     effective character-by-character error detector. In
+     particular, when both user input and computer output
+     contain numerical data it is possible that significant
+     undetected errors could occur.
+
+     b. For terminals located at a distance from the TIP
+     and connected either by a private line or the switched
+     network more errors may be introduced than with a
+     terminal local to the TIP (see Note 1). When a large
+     number of user terminals are connected to TIP's through
+     telecommunications facilities, whether within a single
+     organization or, even more likely, when users and user
+     groups not needing the full TIP capability are connected
+     to a remote TIP, this problem may arise.
+
+
+
+
+
+
+                                                                [Page 1]
+
+     c. For terminals containing a substantial amount of logic,
+     including possibly a minicomputer, a human user is very
+     likely not in the direct terminal-TIP communications loop.
+     This case is important, since both alphanumeric and full
+     graphics terminals containing minis are now becoming
+     popular.
+
+     d. An interesting potential application of the network is to
+     provide support for minicomputers used for process
+     control and other laboratory measurement functions. In
+     providing software support for such minis as well as
+     acquiring data from them usually there is no human user
+     in the communication loop.
+
+     e. A number of sites already offer a remote job entry
+     service. Although the present sites assume that the unit
+     record devices such as card readers and line printers are
+     files within a multiprogrammed system at another site, it
+     appears natural that remote batch terminals be attached
+     to the network through TIP's. Here again, there would be
+     no human in the loop between the terminal and the TIP.
+
+       In addition to some degree of error control on these types of
+terminal loops, it may be desirable to provide for block-oriented data
+transmission, at least for terminals of types (d) and (e) and possibly
+(c) above. It is possible that error control utilizing block
+transmission can be superimposed on the present TIP-terminal
+communication protocol. Data blocks, including error control and block
+delimiting information, can be multiples of a single character in
+length. The communication channel would still not be as fully utilized
+as for conventional synchronous block communication, since start and
+stop bits for each character would need to be transmitted. This loss
+is not substantial and does occur now for 2000 bps TIP-terminal
+communication.
+
+         There are at least two ways to implement such a protocol on
+top of the existing TIP-terminal communication protocol. In both
+cases, the remote terminal would have to handle both originate and
+receive error and block control procedures:
+
+     a. Through an addition to TIP software, the controlled
+     communication loop could terminate in the TIP, thus
+     providing error control only where it is most needed,
+     between the TIP and the terminal. This, however, would
+     involve additional TIP software and a block buffering
+     capability which may put an excessive load on the TIP.
+
+
+
+
+
+                                                                [Page 2]
+
+     b. The other end of the block transmission error control
+     loop could be in the serving host system, either in an
+     applications program or in system support software.
+
+       If the remote end of the block transmission error control loop
+is in the serving host, then this software could possibly be used for
+host-to-host, end-to-end error control in addition to
+host-host-terminal end-to-end error control. For host-to-host
+communication, however, there would be a slight loss in efficiency due
+to the imbedded character-oriented format, unless an option were
+provided in which start/stop bits were not required.
+
+
+-------------------------------
+Note 1: The most recent published data concerning data transmission
+error performance of the switched telecommunications network is
+provided in the 1969-70 Connection Survey conducted by Bell
+Laboratories. The results are published in The Bell System Technical
+Journal, Vol. 4, No. 50, April 1971.  In this survey, 12 receiving and
+92 transmitting sites in the U.S. and Canada were used with standard
+Bell System Dataphone datasets used at both ends.  At both 1200 and
+2000 bps, approximately 82% of the calls had error rates of 1 error in
+10^5 bits or better, assuming an equal number of short, medium, and
+long hauls.
+
+       The results of this survey for low-speed, start/stop data
+transmission at rates up to 300 bps indicate a character error rate of
+1 error in 10^4 characters or better on 77.6% of all calls made within
+the survey. It is interesting to note that only 48.3% of the low-speed
+data tests completed were error-free. These tests were nominally 40
+minutes in length.
+
+       For voice grade private line data channels, the Bell System
+technical reference, "Transmission Specifications for Voice Grade
+Private Line Data Channels," dated March 1969 reports "When a Bell
+System dataset is combined with the recommended channel, the expected
+long term average error rate of the system is 1 error in 10^5 bits or
+better during normal transmission conditions. "
+
+
+
+       [ 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 3]
+