Re: [CODE] [NEWBIE]? MXP - tough luck telnet users?

From: Mysidia (
Date: 07/12/00

On Wed, 12 Jul 2000, StormeRider wrote:

   Indeed, for the purposes of any existing MXP implementation, the
solution would be to prompt for MXP and either not display it or strip it
when an option on a player/descriptor is off, or to provide just a toggle
command like 'color'.

For later...

   What should happen is a way should be added into the protocol
to negotiate support with the client, so that the user of the client
can easily set up that they want to use the protocol and users of
other clients don't run into any problems if they need to connect
later with telnet -- specialty protocols over a line that wouldn't
normally support them should always have negotiation with the client
to minimize the pain for terminal users.

   I would suggest having an 'option-negotiation' as part of the start of
the login sequence, a separate protocol; support of which MXP itself would

   Begin by having the server initiate the conversation using a message
prefixed with a command character followed by a list of the outbound
special protocols/devices the server is able to support:

(FOO being the special command character -- negotiating with extensions
 to the MXP protocol itself might be viable but could prove annoying,
 and I think protocol negotiation could benefit non-MXP special-protocols
 as well; 'FOO' could be most any character that the mud doesn't normally
 allow to be sent-out/receive from players, but unless the negotiation could
 be made to fully fit within the telnet protocol, it shouldn't use the telnet
 protocol's value for IAC; the rest of the constants (other than the protocol
 constants) ought to just use the same values as in the telnet protocol.)

[FOO, WILL, WONT, DO, and DONT are all 'constant' one-letter tokens
 as are the protocol identifiers such as

 WILL/WONT/DO/DONT having the same values they have in the telnet protocol
 -- matter of fact, this thought is basically to use a slightly-warped
 version of the telnet protocol's option-negotiation except with
 a different command character.  (see RFC 855, 2400, 854); (it can be
 safely presumed that no matter what the client's running it supports the
 telnet protocol and that it is not safe to randomly stuff in
 new telnet protocol options -- or perhaps use of the extended telnet
 protocol options TOPT-EXTOP would be appropriate here instead of
 adding another protocol and TOPT_EXT_MXP could be one of the options)]


FOO WILL {<Supportedprotocol> \
          <Supportedprotocol> ..}


   Once the client sees the server's protocol advertisment it then knows
that it's safe to advertise its own outbound protocols.

ex:     FOO WILL MXP

   The client and server then concurrently request the protocols
from the other side that each wants;  either side keeps track
of protocols supported on both ends of the connection separately and
can turn on/off the protocols at either endpoint at any time --
same general rules as the telnet protocol.

FOO DO { <protocol1>, <protocol2>, ..}


   Would enable MXP and ANSICOL and would exclude 'BLAH'.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

   Something like 'ANSICOL' that's supported by clients that comply with
the telnet protocol could be assumed in some kind of middle-status as
a server-outbound protocol where it's presumed on until the client
demonstrates that it supports protocol negotiation; then it would have
to explicitly enable use of it.

* Just a few insane ideas! *

     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     |  |

This archive was generated by hypermail 2b30 : 04/10/01 PDT