Well, as I seem to be the sole active coder at present (I hope I am wrong *looks around for Vadi or Chris to contradict him
) and I am not strong in my knowledge of that area of the application I need to get up to speed on it.
My understanding is that according to Telnet protocol rules the Server must assume that the Client is in a WONT
state for ALL sub-options on connection start up and must activate/negotiate each one that it wants to use. Some of those can be enable/disabled by the user for a particular profile with various setting (GMCP, MCCP and MXP come to mind on that score) but nothing should be activated until the Server and the Client (in our case the Mudlet application) have both agreed to use them with a DO/WILL or WILL/DO as per RFC854
In RFC854 it was wrote:...In summary, WILL XXX is sent, by either party, to indicate that party's desire (offer) to begin performing option XXX, DO XXX and DON'T XXX being its positive and negative acknowledgements; similarly, DO XXX is sent to indicate a desire (request) that the other party (i.e., the recipient of the DO) begin performing option XXX, WILL XXX and WON'T XXX being the positive and negative acknowledgments. Since the NVT is what is left when no options are enabled, 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.
and THEN "Sub-negotiation" about the particular option must be undertaken IF that particular option is known about by BOTH parties AND the option has additional details, e.g. parameters, etc. that NEED to be exchanged between them.
As per RFC855
this means that for an option that one party does not understand (acknowledged with a WONT/DONT as appropriate), it can safely ignore anything that the other sends in an attempt to Sub-negotiate that option (by sending a sequence beginning with "IAC SB <option number>...") by just looking for the terminating "... IAC SE" and forgetting anything in between. Now, if Mudlet is not playing by those rules, it would seem to be a bug (and, sadly, those are not unheard
of in it
) and someone (I guess I'm drawing the only straw at the moment so I can't tell if it is the short one) will need to take a look at it...
Option 24 Terminal Type is one that is supposed to be negotiated as the client sends successively more generic responses as per RCF930
and the server is supposed to record all of them until it gets two identical ones in succession which indicated the end of the list. This was extended in RCF1091
in that for clients that can change their terminal characteristics upon request
they must adopt those characteristics AT THE POINT where they return the relevant terminal type. The server, having got to the point where a response is repeated, may then send one or more TTYPE sub-negotiations which causes clients that support the later RFC to wrap around the list and return to the first
(probably most detail/functional) TTYPE mode and proceed to step through them again until the Server stops on the one it wants to use. Clients that do not support RCF1091 (including Mudlet at present) will just ignore this and repeatedly return the most generic (or only TTYPE) they report.
Mudlet does only return a single string as it is currently coded but that will change in the future
as it is something I have had on my to-do list for some time. That was since I found all the places where Mudlet presents a version string and changed all the hard-coded string literals to be a compile time constant set in just one (actually two - but only one is used at a time) places.
The reason for reporting the version in the TTYPE is to help the MUD Server coder to know exactly what type of (Mudlet?) client they are talking to and (we hope) to help them accommodate any issues that older versions might have or use new shiny features that have been lovingly bolted on. If this is not working for a Server then we (the Mudlet "Makers") do want to know about it and I would like to thing we could work with the Server coders to try and resolves things - so please don't think I'm trying to be dismissive - I just want to know where the problem lies and to fix things if the problem is with the Mudlet part of the system; sadly, just because another client does something one way, it may not be the "correct" way but it might indicate that something is not as clearly defined as one might hope...