I think telnet clients accept the new environ option, so you'd be wasting bandwidth, and I don't think new-environ implements an array option - and it has unneeded functionality. NEW-ENVIRON isn't very clearly defined either. ZMP and particularly MXP come with a lot of overhead and as pointed out by elanthis, they leave the interface design up to the server instead of the client.

The main advantage of MSDP is that it is the easiest to implement and identical to MSSP, which should make implementation even easier for the 12 muds that implemented the telnet version of MSSP so far. The way I'll implement MSDP in tintin the user will have to script the MSDP negotiation - so that'd be part of the interface script the user has to write and it avoids wasting bandwidth, which auto enabling would result in.

ZMP is just a way to send data. It can be used in exactly the way you want here. It doesn't leave things up to the server any more than your proposal does.

So is MXP. It's the overhead that is the issue. Can I claim tintin supports MXP if I add an MXP event handler? I don't think so.

And I'd say the same goes for ZMP once more packages are released, where as an event handler is all that's required for a fully MSDP compliant mud client.

The only "overhead" with ZMP is that instead of sending this:
var name | var value
you send (something like) this:
zmp.var | var name | var value

Is that really your problem or is there something else at play?

Scandum means the "overhead" of needing to implement packages.

It's really just a different approach to design. He wants to make implementing the core code of a client very easy while putting the burden on the user to script up his UI. Developers like you and I prefer to ask the client author to put in more effort in exchange for creating a better out-of-the-box user experience. I don't like his approach, but it's not wrong, and there's no reason MSDP and ZMP can't coexist even.

That said, I don't understand what you mean about NEW-ENVIRON, Scandum. Can you explain more? What is not well defined about it? What makes it heavier? What use cases for arrays do you have that can't just be supported by sending \t or : or even \n in the variable data?

But you don't have to implement whole packages to accomplish exactly this in ZMP. You can have a dirt-simple zmp.var type command, and avoid creating Yet Another Data Protocol.

I agree that our other discussions about encoding more semantics are quite different, but we don't need to go there in order to accomplish something like this.

It could be just me, but I find the telnet rfcs rather vague. NEW-ENVIRON forces you to specify what kind of variable you're transmitting, and I'd dislike building a protocol on top of another protocol. There's nothing though that stops a mud from employing new-environ in a msdp like fashion, but msdp would be cleaner.

I'll simply add event handlers for mxp, zmp, new-environ, and msdp, and see where things go.

Client side the code is very easy:

#event {IAC WILL MSSP}
{
        #send {\xFF\xFD\x46\} \\ iac do mssp
}

#event {IAC SB MSSP}
{
        #variable {%0} {%1}
}

The event handler automatically splits up a mssp subnegotiation into var/arg events.

Wait… isn't that what you're doing anyhow?

If you used NEW-ENVIRON, you wouldn't be building a new protocol. You'd just be defining a list of MUD-related variables as a recommendation to MUD server authors to use with NEW-ENVIRON.

It just seems a bit silly to me to consume another TELNET option. Especially since MSDP is just MSSP with a different set of variables…. why not just add these to MSSP and state that the MUD can send these variables to the client at any time, and that clients that support MSSP should expose all MSSP variables to scripts with events for when they get updated? Two birds, one stone.

You could still just do MSSP/MSDP using NEW-ENVIRON, granted, but if you're that opposed to it, so be it.