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