I've been told by the developer of a MOO display utilities package (I'm assisting him with this project) - and apparently, MUSHclient responds to IAC DO MXP with IAC WONT MXP, no matter what the MXP preferences are set to.
MXP Telnet negotiation
Posted by Fwongo on Wed 27 Jun 2001 06:33 PM — 8 posts, 38,745 views.
The MXP telnet negotiation is described in great detail in this post Telnet negotiation
This conforms to the standard described in RFC 854 and RFC 855, partly reproduced below:
Thus, for option "ABC", which requires subnegotiation,
the formats of the TELNET commands are:
IAC WILL ABC
Offer to use option ABC (or favorable acknowledgment
of other party's request)
IAC DO ABC
Request for other party to use option ABC
(or favorable acknowledgment of other party's offer)
IAC SB ABC <parameters> IAC SE
One step of subnegotiation, used by either party.
Therefore the MUD is incorrectly sending IAC DO MXP, it should send IAC WILL MXP.
So, the guy who I'm helping says:
----
ByteNik says, "Uhm, no."
ByteNik says, "Tell him is way is wrong, and to read the RFC. tell him to come on here if he needs help."
ByteNik says, "zMud won't respond to his way, even. :P"
ByteNik says, "cya"
---
Now if zMud doesn't respond to your way correctly, and zMud is the main implementation, d'you think you should at least support that way?
----
ByteNik says, "Uhm, no."
ByteNik says, "Tell him is way is wrong, and to read the RFC. tell him to come on here if he needs help."
ByteNik says, "zMud won't respond to his way, even. :P"
ByteNik says, "cya"
---
Now if zMud doesn't respond to your way correctly, and zMud is the main implementation, d'you think you should at least support that way?
Since my friend here finds it necessary to quote me exactly instead of writing a message, since the message sounded at least a bit rude, I'll try to explain what I'm seeing.
When I send <IAC><DO><MXP> to zMud, it replies <IAC><WILL><MXP>. When I send <IAC><WILL><MXP> to zMud, it replies with <IAC><DO><MXP>. MUSHclient supports only sending the request the second way. From my understanding of the RFC, the first way is proper and the second way is implemented only for systems who support it incorrectly. If not, I just corrected the author of SimpleMU incorrectly, so the next version is going to have a nice big bug in it. =P
Note the following from RFC854:
WILL (option code) 251:
Indicates the desire to begin performing, or confirmation that you are now performing, the indicated option.
DO (option code) 253:
Indicates the request that the other party perform, or confirmation that you are expecting the other party to perform, the indicated option.
The two sequences seem to be very similar. However, <DO> states that you are requesting the -other- party to begin the indicated option. Since I am the server, I'd be expecting the -client- to do the option MXP. <WILL> states that -you- are either performing or want to perform the indicated option, which coming from the server would mean that the server wishes to start MXPing. Since the option is to determine if the client -supports- MXP, its the client that performs the action and the server that requests it, which seems to indicate that it should send <IAC><DO><MXP> to the client. This seems even more so in MUSHclient, where the client has to perform the action of enabling MXP in it. The server isn't performing any action.
--ByteNik
When I send <IAC><DO><MXP> to zMud, it replies <IAC><WILL><MXP>. When I send <IAC><WILL><MXP> to zMud, it replies with <IAC><DO><MXP>. MUSHclient supports only sending the request the second way. From my understanding of the RFC, the first way is proper and the second way is implemented only for systems who support it incorrectly. If not, I just corrected the author of SimpleMU incorrectly, so the next version is going to have a nice big bug in it. =P
Note the following from RFC854:
WILL (option code) 251:
Indicates the desire to begin performing, or confirmation that you are now performing, the indicated option.
DO (option code) 253:
Indicates the request that the other party perform, or confirmation that you are expecting the other party to perform, the indicated option.
The two sequences seem to be very similar. However, <DO> states that you are requesting the -other- party to begin the indicated option. Since I am the server, I'd be expecting the -client- to do the option MXP. <WILL> states that -you- are either performing or want to perform the indicated option, which coming from the server would mean that the server wishes to start MXPing. Since the option is to determine if the client -supports- MXP, its the client that performs the action and the server that requests it, which seems to indicate that it should send <IAC><DO><MXP> to the client. This seems even more so in MUSHclient, where the client has to perform the action of enabling MXP in it. The server isn't performing any action.
--ByteNik
OK, I'll tell you where I am coming from with this. The MXP spec does not specifically say which exact protocol it uses, however the document lists MXP right next to MCCP (near the end) where it says "You can also use the Telnet option to determine if the client supports the MUD Sound Protocol (MXP) or the MUD Compression Protocol (MCP). "
It seems reasonable that in the absence of an explicit direction in the MXP spec that the protocol would be the same as for MCCP, since they are mentioned in the same sentence. The protocol for MCCP is very specific, and is at: The Mud Client Compression Protocol.
Here the author makes it very clear that the *server* sends IAC WILL COMPRESS and the *client* replies IAC DO COMPRESS. Therefore I implemented it the same way for MXP.
I don't want to get into a big argument about which is right, and I can see your point - maybe MCCP is backwards? In the next release of MUSHclient I will accept either way, I trust that will resolve the issue.
I would like to also suggest that you amend your server to send the additional sequence to actually start using MXP (same as is done for MCCP).
Otherwise (as currently happens in zMUD) the *query* about whether you support MXP actually turns it on, which is not really desirable. I think that the query about the capability to support, and the request to commence using that feature, should be two separate sequences.
This sequence is:
Server is ready to start sending MXP
(Sent from server to client)
Otherwise (as currently happens in zMUD) the *query* about whether you support MXP actually turns it on, which is not really desirable. I think that the query about the capability to support, and the request to commence using that feature, should be two separate sequences.
This sequence is:
Server is ready to start sending MXP
(Sent from server to client)
<IAC><SB><MXP><IAC><SE>
which in hex is: 0xFF 0xFA 0x5B 0xFF 0xF0
Hi,
I'm working on integrating MXP support into LPMud.... What is needed to get MushClient to work with the On Command option of Use Mxp?
Thanks
Bob
I'm working on integrating MXP support into LPMud.... What is needed to get MushClient to work with the On Command option of Use Mxp?
Thanks
Bob
#define IAC_SB (char)IAC, (char)SB
#define SE_NUL (char)SE, '\0'
#define IAC_SE_NUL (char)IAC, SE_NUL
#define WILL_SE_NUL (char)WILL, SE_NUL
#define TELOPT_MXP 91
const char mxp_advertise_buf[]= { IAC, WILL, TELOPT_MXP, '\0'};
const char mxp_start_buf[]= { IAC_SB, TELOPT_MXP, IAC_SE_NUL};
send mxp_advertise_buf[] to the connection
if you receive IAC DO MXP from the connection after this then
send mxp_start_buf[] to the connection
- Kalahn
Developer of the Dawn of Time Codebase
http://www.dawnoftime.org/