Zenith MUD Protocol
Introduction
ZMP is a text-based MUD protocol that runs over the telnet layer. ZMP is similar in spirit to technologies such as MXP and MCP. ZMP hopes to overcome the shortcomings in those, and other, MUD technologies.
What Does It Do?
ZMP is merely a protocol that allows a server and client to communicate. The communications take place in the form of commands. In essence, ZMP is a simple but quite usable RPC (Remote Procedure Call) framework for telnet connections.
Using ZMP a MUD can offer a richer experience to its players. Client software can be given information to present to the user in the client's user interface, such as allowing navigation compasses, status bars, paper dolls representing character state, or even advanced elements such as a complete graphical game editing environment or character creation GUI.
Why ZMP?
When playing a MUD the player will type commands that are sent to the server and interpreted, and the server will send text back to the client to be displayed on the screen. All of this communication is part of the player's user interface.
Protocols such as MCP and MXP embed "magic" commands in the text sent back and forth between the server and client. When reading the output text a client is required to look for special values and, when they are found, parse them out to interpret them. When data is sent from the client to the server a similar process must occur. This then also requires that all data the server handles from text files and other sources be sanitized to ensure that the special command codes are not accidentally (or maliciously) included and the client must do the same for all player input.
MCP and MXP are also rather complicated protocols. Parsing them correctly can be very difficult, and as a result very few implementations are actually correct. Furthermore, these protocols are redundant in the context of a MUD.
MUDs almost universally use a protocol called telnet. For the most part, telnet is just pure text. Every byte sent from the client is considered input and every byte sent from the server is considered output. However, telnet does include a mechanism for negotiating feature sets, and for communicating chunks of data. These telnet protocol features are used for disabling the display of your password when you type it in and for allowing the client to tell the server how many rows and columns your display has. The MCCP (MUD Client Compression Protocol) also uses these core telnet features.
A MUD that implements MXP or MCP is actually implementing a second protocol on top of an existing protocol. To add insult to injury, the MXP and MCP protocols completely reinvent the infrastructure already provided by telnet. This results in code that is far more complex and bug-prone than it needs to be.
ZMP makes full use of the telnet protocol. Enabling ZMP uses the built-in telnet feature negotiation framework. ZMP commands are sent using the built-in telnet sub-request framework. Any software that uses telnet can implement ZMP with very little effort and complete safety.
Why Not ZMP?
ZMP is a very new protocol, and as a result, is not implemented in the vast majority of MUD servers or clients. Adding core ZMP support is a trivial task. However, until developers receive enough requests from their users, they are unlikely to implement ZMP.
The telnet requirement of ZMP is also unfortunately a problem. Many amateur developers are not capable of implementing correct telnet layers. These same developers are also not capable of implementing correct MXP or MCP layers either, but they often settle for a "works well enough" scenario. While ZMP can indeed function on a less than complete telnet layer, it will potentially suffer from security problems and other behavior unless the software's telnet implementation is corrected.
See our page on Implementing Telnet.
Specification
ZMP is currently a draft specification. Various notes (including implementation and usage notes) are also available in the ZMP Notes document. These notes were originally a part of the draft specification.
Future
First, the draft must be finished. There are three parts to ZMP - the core protocol, the core package, and the standard packages. Before the draft may be finalized, all three of these parts must be completed.
The core protocol is entirely complete and will not change in future revisions.
The core package may need some additional modifications once more testing has been done. We have already made several revisions, and we feel that more may be necessary.
The standard packages still need to be defined. We have almost no standard packages available yet. At least a small handful need to be available before we start heavily pushing ZMP. Without standard packages, ZMP has very little use outside of highly specialized server and client combinations.
