Mud Terminal Type Standard  
Get TinTin++ Mud Client at SourceForge.net. Fast, secure and Free Open Source software downloads
MUD servers often want to know the various capabilities of a Mud Client. While various methods exist there is no consistent nor guaranteed way to do so.
The Mud Terminal Type Standard seeks to address these issues by providing a transparant and straight forward standard for Mud Clients to communicate their terminal capabilities. It does so by extending and standardizing RFC1091 which describes the Telnet Terminal-Type Option.

The TTYPE Protocol

TTYPE is implemented as a Telnet option RFC854, RFC855. The server and client negotiate the use of the TTYPE option as they would any other telnet option as detailed in RFC1091. Once agreement has been reached on the use of the option, option sub-negotiation is used to exchange information between the server and client.

Server Commands

IAC DO   TTYPE    Indicates the server wants to receive TTYPE information.
IAC DONT TTYPE    Indicates the server wants to discontinue receiving TTYPE information.

Client Commands

IAC WILL TTYPE    Indicates the client will send TTYPE information.
IAC WONT TTYPE    Indicates the client will not send TTYPE information.

Handshake

When a client connects to a TTYPE enabled server the server should send IAC DO TTYPE. The client should respond with either IAC WILL TTYPE or IAC WONT TTYPE. Once the server receives IAC WILL TTYPE the client and the server can send TTYPE sub-negotiations.
The client should never initiate a negotiation, in the case this does happen the server should abide by the state change. To avoid trigger loops the server should not respond to negotiations from the client, unless it correctly implements the Q method in RFC 1143.

Disabling TTYPE

When a typical MUD server performs a copyover it loses all previously exchanged TTYPE data. If this is the case, before the actual copyover, the MUD server should send IAC DONT TTYPE, the client in turn should fully disable and reset its TTYPE state. After the copyover has finished the server and client behave as if the client has just connected, so the server should send IAC DO TTYPE.

TTYPE definitions

TTYPE            24

IS 0
SEND 1

Example TTYPE handshake

server - IAC DO TTYPE
client - IAC WILL TTYPE
server - IAC SB TTYPE SEND IAC SE
client - IAC SB TTYPE IS "TINTIN++" IAC SE
server - IAC SB TTYPE SEND IAC SE
client - IAC SB TTYPE IS "XTERM" IAC SE
server - IAC SB TTYPE SEND IAC SE
client - IAC SB TTYPE IS "MTTS 137" IAC SE
server - IAC SB TTYPE SEND IAC SE
client - IAC SB TTYPE IS "MTTS 137" IAC SE
The quote characters mean that the encased word is a string, the quotes themselves should not be send.

Mud Client Name

As RFC1091 details the server can request TTYPE information using sub-negotiations. On the first TTYPE SEND request the client should return its name, preferably without a version number and in all caps.

Mud Client Terminal Type

On the second TTYPE SEND request the client should return a terminal type, preferably in all caps. Console clients should report the name of the terminal emulator, other clients should report one of the four most generic terminal types.
"DUMB"              Terminal has no ANSI color or VT100 support.
"ANSI"              Terminal supports all ANSI color codes. Supporting blink and underline is optional.
"VT100"             Terminal supports most VT100 codes, including ANSI color codes.
"XTERM"             Terminal supports all VT100 and ANSI color codes, xterm 256 colors, mouse tracking, and the OSC color palette.
If 256 color detection for non MTTS compliant servers is a must it's an option to report "ANSI-256COLOR", "VT100-256COLOR", or "XTERM-256COLOR". The terminal is expected to support VT100, mouse tracking, and the OSC color palette if "XTERM-256COLOR" is reported.
Mud Terminal Type Standard

On the third TTYPE SEND request the client should return MTTS followed by a bitvector. The bit values and their names are defined below.
          1 "ANSI"              Client supports all ANSI color codes. Supporting blink and underline is optional.
          2 "VT100"             Client supports most VT100 codes.
          4 "UTF-8"             Client is using UTF-8 character encoding.
          8 "256 COLORS"        Client supports all xterm 256 color codes.
         16 "MOUSE TRACKING"    Client supports xterm mouse tracking.
         32 "OSC COLOR PALETTE" Client supports the OSC color palette.
         64 "SCREEN READER"     Client is using a screen reader.
        128 "PROXY"             Client is a proxy allowing different users to connect from the same IP address.
         
The client should add up the numbers of all supported terminal capabilities and print it as ASCII in decimal notation. In the case that a client supports ANSI, UTF-8, as well as 256 COLORS, it should respond with "MTTS 13", which is the sum of 1, 4, and 8. The reporting of UTF-8 should be implemented as a user setting, unless the client is certain that a Unicode font is being used.
Cycling

RFC1091 allows for cycling through a list of terminal types in order to select one. Implementing this behavior is optional, but the client must properly report the end of the cycle.
At the fourth TTYPE SEND requests the client should repeat the previous response, reporting MTTS followed by a bitvector. Receiving the same terminal type twice indicates to the server that the end of the list of available terminal types has been reached. If the server sends additional requests the client can either continue to respond with MTTS <bitvector>, reset its cycling state to the initial state and start over, or ignore the request.
If the server sends IAC DONT TTYPE the client's cycling state should be reset to the initial state, as if the client just connected to the server. This behavior allows recovering from a copyover.
Proxies

It's suggested for proxies adding MTTS support to also implement the NEW-ENVIRON telnet option as per RFC1572. Using the NEW-ENVIRON option the server can send: IAC SB NEW_ENVIRON SEND VAR "IPADDRESS" IAC SE. When receiving this send request the proxy should respond with: IAC SB NEW_ENVIRON IS VAR "IPADDRESS" VALUE "<user's ip address>" IAC SE.
The quote characters mean that the encased word is a string, the quotes themselves should not be send.

Links

If you have any comments you can email me at mudclient@gmail.com.

Clients

TinTin++ Mud Client - Supports MTTS as of version 2.00.7.
MUSHclient - Supports MTTS as of version 4.93.
MUD Portal - Supports MTTS as of 2014 including NEW-ENVIRON IP reporting.

Codebases

Lola 1.4 - Rudimentary MTTS detection and utilization
ZetaMUCK - MTTS detection and utilization of 16/256 colors and UTF-8.
Evennia - MTTS detection and utilization of 16/256 colors.

Discussion


Extensions


Servers

lolamud.net:6969

Snippets

Scandum's MUD Telopt Handler - Handles EOR, MCCP, MSDP, MSSP, MTTS, NAWS, NEW-ENVIRON, TTYPE, and xterm 256 colors.