29 May, 2011, Mastermosley wrote in the 1st comment:
Votes: 0
If a client requests a feature that I don't support, or rather not support, is it imperative that I "WONT" or would the client insinuate that by the lack of response? It doesn't seem very clear in the RFC.
29 May, 2011, Idealiad wrote in the 2nd comment:
Votes: 0
Yes, send WON'T.

the DON'T and WON'T responses are guaranteed to leave the connection in a state which both ends can handle. Thus, all hosts may implement their TELNET processes to be totally unaware of options that are not supported, simply returning a rejection to (i.e., refusing) any option request that cannot be understood.

a. Parties may only request a change in option status; i.e., a
party may not send out a "request" merely to announce what mode it
is in.

b. If a party receives what appears to be a request to enter some
mode it is already in, the request should not be acknowledged.
This non-response is essential to prevent endless loops in the
negotiation. It is required that a response be sent to requests
for a change of mode – even if the mode is not changed.
29 May, 2011, Twisol wrote in the 3rd comment:
Votes: 0
Similarly, be sure to send DONT if they send a WILL for something you don't want them to enable. If you want to poke around a working Telnet implementation, I've written a Telnet library called Anachronism. It's on GitHub, and it implements the Q Method of option negotiation, which ensures that you don't accidentally get into request loops.
30 May, 2011, Mastermosley wrote in the 4th comment:
Votes: 0
Alright thanks guys. Is there a list of client term types and their corresponding clients?
30 May, 2011, Scandum wrote in the 5th comment:
Votes: 0
There's no good resource that I know of. One thing you might find interesting is MTTS: http://tintin.sourceforge.net/mtts/

Hard to tell if it'll gain popularity at this point, but implementation is fairly easy if you already have a telnet handler.