doc: Add RFC documents

1 files changed, 171 insertions, 0 deletions

diff --git a/doc/rfc/rfc513.txt b/doc/rfc/rfc513.txt
new file mode 100644
index 0000000..1611069
--- /dev/null
+++ b/doc/rfc/rfc513.txt
@@ -0,0 +1,171 @@
+
+
+
+
+
+
+Network Working Group                                     Wayne Hathaway
+RFC # 513                                                        AMES-67
+NIC # 16444                                                  30 May 1973
+
+
+               COMMENTS ON THE NEW TELNET SPECIFICATIONS
+
+I would like to make the following comments on the proposed new TELNET
+Protocol Specification (NIC # 15372) and TELNET Option Specification
+(NIC 15373).  In general I feel the new TELNET protocol is far superior
+to the previous version.  There are, however, a few items of substance
+which I feel should be changed, as well as some recommended editorial
+changes.
+
+I feel the most significant error concerns the "Note on 'Sub-
+negotiations'" section of the Option Specification (page 2).  The
+problem stems from the statements "Each party is presumed to be able to
+parse the parameter(s)" and "Finally, if parameters in an option
+'subnegotiation' include a byte with a value of 255, it is not necessary
+to double this byte in accordance with the general TELNET IAC."  These
+two statements make the completely unwarranted but all too prevalent
+assumption that there is only one "Telnet Interpreter" and that all
+TELNET functions are carried out by it.  In particular, problems arise
+when a TELNET "synch" is received, and the receiving NCP is required to
+scan the input looking for "interesting" things.  If the subnegotiation
+was in fact being carried out by a user process (and not the "TELNET
+interpreter") then that user process is probably the only one that knows
+how to interpret the SB parameters; the NCP itself would have no way of
+parsing them.  As a solution to this problem I propose that all
+subnegotiation parameters be delimited at the end (perhaps with the same
+TELNET command SB) and that they be required to obey all TELNET rules,
+including doubling of IAC's.  It may be argued that the user process
+interpreting the SB itself should do the scanning for "interesting"
+things, but I do not feel that this burden should be place on all user
+processes.
+
+The solution to the above problem is in fact fairly simple to define and
+implement.  The general problem, however, is one of not taking proper
+cognizance of what I called "user processes" (processes which are not
+network standards, but which are simply programs attempting to do work
+using the network).  I feel we must be more careful to shape all future
+network standards with these very real user processes in mind if in fact
+the network will ever be as useful as is possible.
+
+The second item I object to is the incredibly loose definition of
+"interesting" things (an aside: words which are so imprecise as to
+require quotation marks should never appear in protocol specifications).
+The specifications do define some of these "interesting" things (eg,
+
+
+
+Hathaway                                                        [Page 1]
+
+RFC 513        COMMENTS ON THE NEW TELNET SPECIFICATIONS        May 1973
+
+
+most TELNET commands) but they then include "and perhaps other
+characters or character strings as well".  To eliminate the difficulty
+of implementing an undefined set of "interesting" things, I would
+propose that the set of "interesting" things, contain only the DM
+command itself.  The TELNET "synch" would thus be defined as "discard
+all input up to and including the next DM command."  This change should
+cause no problems with user-generated "interesting" things if they are
+sent after the "synch" (as specified in the proposed new File Transfer
+Protocol Specifications).  System-generated signals (such as option
+requests) could be discarded, however, so some additional discussion is
+in order.  If the recommendation that requests not be sent except when
+something changes is followed, the spontaneous generation of
+"interesting" things by TELNET itself (whatever that implies) would seem
+to be rare, especially at the same time that users are generating
+"synch's".  A more positive solution could be had by defining a "synch
+response" (SR) TELNET command.  The SR command would be sent when the
+INS and DM had both been processed (ie, when the "synch" had been
+completely received).  If a process should ever receive an SR when it
+has an option request outstanding, the request has been discarded and
+must be repeated.  User processes which carry on option negotiations
+would be the generators of any "synch's" so they can handle discarded
+option requests as desired.  Note that this assumes that the TELNET
+process itself will never generate a spontaneous "synch"; comments are
+solicited on this.  Another possible solution would be to define a
+"TIMING-MARK" TELNET command (see "TELNET Timing Mark Option", NIC #
+16238), which would be sent immediately following the DM of a "synch".
+The response to the TIMING-MARK (also to be defined) would mean the same
+as the proposed SR command.
+
+The final non-editorial comment concerns the need for some means of
+specifying horizontal tab positions and use.  This is quite a nuisance
+when dealing with systems which normally handle tabs for local
+terminals.  Perhaps this issue can be best handled with an appropriate
+option; comments are solicited.
+
+The only editorial comments are on the TELNET Protocol document, which I
+reference below by page number.
+
+On page 8 the parenthetical comment "(i.e., when a process at one end of
+a TELNET connection is 'blocked on input')" should either be removed or
+rewritten to avoid the (to me) incomprehensible phrase "blocked on
+input."  If additional discussion is felt to be necessary, I would
+propose "i.e., when a process at one end of a TELNET connection cannot
+proceed without additional input)."  If examples are felt necessary, I
+would propose "(e.g., in the state characterized by the Multics term
+'blocked on input')."  The parallel could also be drawn between the GA
+and the concept of a "read command" being issued to request more input.
+
+
+
+
+Hathaway                                                        [Page 2]
+
+RFC 513        COMMENTS ON THE NEW TELNET SPECIFICATIONS        May 1973
+
+
+On page 10 I feel that there needs to be some more discussion of the
+Abort Output (AO) command, particularly the statement that it "allows a
+process... to run to completion... but without sending the output to the
+user's terminal."  The problem is that nothing is said about when output
+is to resume (presumably at the next system prompt character).  I
+realized that the AO is meant only to invoke this function on systems
+which already provide it, but it would seem to be more useful if more
+fully specified.
+
+On page 11 I do not understand what the example "(e.g., an over-strike)"
+is trying to say.  Speaking of an overstrike on output would imply to me
+that both characters are to be printed in the same print position,
+reducing the EC to a backspace.  Some more discussion should also be
+added as to what EC (and EL) mean on output (if anything).
+
+On page 11 I would like to see the word "promptly" (which is in
+quotation marks) either eliminated or defined, as per my earlier aside
+comment.  The phrase "if necessary" in the last line also seems
+unnecessary.
+
+On page 12 my proposed redefinition of "interesting" signals would
+remove the middle paragraph entirely and would modify the third
+paragraph substantially.  The line "discard all characters which would
+have had an effect on the NVT printer" should be changed, however, as it
+seems BELL's should also be discarded.
+
+On page 14 I see no reason why the sequence "CR NUL" is required to
+generate a "CR" only, and also object to "and the CR character must be
+avoided in other contexts."  Either some supporting discussion should be
+added or this restriction should be removed.
+
+
+
+
+
+
+
+
+
+
+       [ This RFC was put into machine readable form for entry ]
+       [ into the online RFC archives by Alex McKenzie with    ]
+       [ support from GTE, formerly BBN Corp.             9/99 ]
+
+
+
+
+
+
+
+
+Hathaway                                                        [Page 3]
+