mrc@TOMOBIKI-CHO.CAC.WASHINGTON.EDU (Mark Crispin) (04/20/89)
Although this RFC is well-intentioned, I am opposed to several of its principles on the grounds that many (most?) implementors of TELNET clients or servers will not go to the level of detail specified by this RFC to get correct behavior. This level of detail is perhaps necessary for the more complex TELNET options, but for the most important ones - binary, echo, and suppress-GA - a simpler implementation model will suffice. This simpler model does violate several of the rules of the draft RFC. However, the "violations", for the most part, take the form of timing races in which the "correct" behavior often produces results that are not necessarily superior. The model does, however, prevent the endless protocol loop. In this model, you send a negotiation *only* when the state of an option changes at your end. In other words, you send a negotiation to notify the other end of your new state. Your new state is set either by your own action (the user gives a command to change binary mode, or an initial flurry of DO/WILL negotiations you set when you open a connection, etc.) or because you received a change of state from the other end. You are permitted to reject a state change to ON (WILL/DO) by sending the corresponding (DONT/WONT). You are forbidden from rejecting a state change to OFF (WONT/DONT) although at a later time, as the result of some human action, you may try changing the state to ON again if you want. The previous principle means that you can only inflict your "desired state" on the other end when the connection starts up. You must implement the state where no TELNET options are enabled and not try to change out of it *except* at initial startup. Technically, this model violates TELNET and certainly violates the draft RFC. However, there is no way the other end can determine this (except, of course, for the more esoteric TELNET options which have subsequent subnegotiations), and it is better to have a simple TELNET that doesn't loop than a possibly broken complex TELNET. -- Mark -- -------