Comments on the new Telnet specifications(1)

　　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,　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".