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
require.
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
MXP, ANSICOL, and BLAH
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> ..}
ex: FOO WILL MXP ANSICOL \
BLAH
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>, ..}
ex: FOO DO MXP ANSICOL
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! *
-Mysid
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/10/01 PDT