MXP modes - secure, open and locked

MXP is designed to allow players to use the tags directly, for example in "say" or "chat".

The problem with allowing this is that players may annoy others by using MXP tags to do things to other players, like turning MXP off, making large headings, and so on.

To prevent this the MXP spec defines three modes:

* Open mode - where "open" tags are allowed
* Secure mode - where all tags are allowed
* Locked mode - where tags are not interpreted at all

These modes are established by an "escape sequence", similar to the ANSI sequences used to colour text in bold, red, and so on.

Note that modes do not necessarily pertain to an entire line, you can switch modes in the middle of a line.

Open mode

This mode is used to allow a "harmless subset" of MXP commands, such as <b> for bold, and <i> for italic.

Open mode is the default mode after a newline is received (unless the <MXP DEFAULT_OPEN> or <MXP DEFAULT_LOCKED> tags have been received, see below).

To switch to open mode the following sequence is sent from the server to the client:



<esc>[0z



which in hex is: 0x1B 0x5B 0x30 0x7A

At present the following tags are allowed in open mode:



<bold> or <b>

<underline> or <u>

<italic> or <i>

<color> or <c>

<font>

<strike> or <s>

<strong>

<small>

<tt>

Note - if a "secure" tag is received on an open line MUSHclient does not display it. However an error message will appear in the error log, if you have the MXP debug level (Configuration -> Output tab) set to anything other than "none".

Secure mode

This mode is used to allow all MXP tags, including those that define new elements or entities.

To switch to secure mode the following sequence is sent from the server to the client:



<esc>[1z



which in hex is: 0x1B 0x5B 0x31 0x7A

Locked mode

This mode is used to temporarily disregard MXP tags on a line. Thus a line can be sent "verbatim" including MXP tags. For example help text:



Type <west> to go west.

In this case the word <west> would not be interpreted as an MXP tag.

To switch to locked mode the following sequence is sent from the server to the client:



<esc>[2z



which in hex is: 0x1B 0x5B 0x32 0x7A

Reset

To allow the client to close any outstanding tags, and return to "normal" operations MUSHclient supports the "reset" sequence. This:

* Closes any outstanding tags (eg. implies </send> if a <send> was outstanding)
* Resets colours to white on black, no underline, no bold, no italic.

This is useful to make sure that output is "back to normal" after (say) a chat line.

You might want to implement the server to routinely send the reset sequence every time it sends the player prompt.

To send the "reset" sequence the following sequence is sent from the server to the client:



<esc>[3z



which in hex is: 0x1B 0x5B 0x33 0x7A

You can also achieve the same effect by sending the MXP tag <reset>.

After the earlier post some changes were made to the concept of modes in MXP. This is my summary of them ...

Rule 1. You have 6 modes:

0 - open
1 - secure until newline
2 - locked until newline
5 - open until mode changed
6 - secure until mode changed
7 - locked until mode changed

These modes are indicated by receiving ESC [ n z from the server, where "n" is the mode. There is no other way of changing modes (eg. by tags), except as described below.

Further I would be personally happy to do away with any other ones (like 10 onwards) as I think they are better provided with the existing tag mechanism, and you don't get into arguments about whether switch to (say) 20 constitutes a mode change, is open or secure, closes existing tags, and so on.

Rule 2. "Mode Changed" in rule (1) would be defined as:

Getting a new mode, other than the current mode, and other than:

3 - reset
4 - temporary mode change to secure mode

Rule 3. Newlines. When in modes 1 or 2, receiving a newline ( \n ) resets to mode 0.

Note that it is undefined what receiving a carriage-return ( \r ) does, but personally I ignore them.

In any other mode receiving a newline has no effect (on modes).

Also see rule 6.

Rule 4. Reset (3) does not change the mode, however it:

closes all open tags (whether open or secure)
sets colour to ANSI white on black (whatever that is for the user's palette)
cancels bold, underline, italic
resets to the default font, if applicable

The purpose of this is to close outstanding tags (eg. so a rogue <send> doesn't underline the next 10 pages of text), and to ensure that the player sees normal white-on-black text.

Rule 5. Mode 4 - secure mode for next tag:

Changes to secure mode, providing the very next character in the input stream is a "<"
Once that tag is processed, successfully or otherwise (in terms of syntax) the mode reverts to whatever it was before receiving the ESC [4z

In other words, receiving ESC [4z does not constitute a permanent mode change, and does not change what will happen when the next newline is received.

Rule 6. Any open tags are automatically closed on a mode change from open to not open

Therefore a change of 0 to 5, or 5 to 0 would not count as a mode change.

If ESC [4z is received, and the current mode is open, then the temporary change to secure does constitute a change from open to not open, and thus any open tags are closed.

Under this rule, no secure tags will be closed, only open ones.

Note - I am not certain whether tags are also closed when receiving a newline in open mode (mode 0 or 5). Can someone clarify this?

Rule 7. The initial mode at world startup, after disconnect/reconnect, or after turning MXP off and on again (if that is possible), is mode 0.

We need to be sure what mode we are starting in. :)

Rule 8. Any attempt by the server to use secure tags in open mode will result in that tag being discarded and not acted upon.

This includes closing tags, eg. </send>.

Rule 9. In locked mode no tags are interpreted at all - text is processed "as is".

Thus, "<", ">" and "&" have no special significance in locked mode.

Rule 10. This protocol is stream-oriented, not line-oriented.

Thus, apart from the special cases above where receiving newline changes modes, it is quite possible to switch modes frequently in one line of text.

Rule 11. When a newline is received, AND the mode is currently open, any outstanding open tags which were opened in "open" mode are closed.

However, if a secure tag is reached then the automatic closing stops.

The point of the "open" mode rule, is that a tag that is opened in secure mode (whether or not it is an open tag itself) is not automatically closed on a newline.