MCP - MUD Client Protocol
  <a href="http://www.moo.mud.org/mcp/">http://www.moo.mud.org/mcp/</a>

MCP allows some fairly simple actions in addition to the standard
telnet stuff.  For instance, it can ask the client to display a URL or
to edit MUD content.  Probably useful eventually, for instance for
OLC and Help.

MCP is primarily a transport protocol, and requires additional
negotiation to decide what the actual capabilities of the MCP
connection are.  This could make it very broadly useful, or it could
make it totally useless :-) ZMUD implements some additional packages
which are nifty, but I don't know how common those specific packages
are.  ZMUD includes packages to send MSP and MXP messages encapsulated
in MCP protocol.

Beware: versions of MCP 2.0 are nonstandard and unsupported.  The
standard only allows negotiating on version ranges, so the only sane
current way to negotiate version is to require version 1.0 or version
2.1 exclusively.

This is used most frequently by MOOs, MUSHes and company.

===========================================================================

MCCP - MUD Client Compression Protocol
  <a href="http://mccp.afkmud.com/">Mirror of http://www.randomly.org/projects/MCCP/</a>

This uses ZLib to compress information going out to the client.
Conceivably useful, but probably not the real problem in most cases.
Can be useful for low-bandwidth MUDs.

Information coming *from* the client isn't compressed, but
traditionally there's very little of that by comparison.

This is implemented as a telnet option, so it would need to be
implemented using a binary port in one way or another.

DGD doesn't currently do zlib or any equivalent.  That'll have to
happen before this is a significant possibility.

===========================================================================

MXP - MUD eXtension Protocol
  <a href="http://www.zuggsoft.com/zmud/mxp.htm#MXP%20Specification">http://www.zuggsoft.com/zmud/mxp.htm#MXP%20Specification</a>

Vaguely similar to Pueblo or FireClient, MXP is a simplification of HTML
or XML for use in the MUD environment.  It allows more than markup,
though, and is more of a semantic language embedding meta-content.  In
this sense it resembles XML more than HTML.  Overall, there's less to
it than Pueblo or FireClient, but it's significantly more MUD-specific
than Pueblo and easier to implement than FireClient.

MXP doesn't have content-based autodetect the way Pueblo and
FireClient do.  You'll have to detect it as a telnet option, or set it
manually.

This is traditionally used by Diku-style MUDs, if at all.

===========================================================================

MSP - MUD Sound Protocol
  <a href="http://www.zuggsoft.com/zmud/msp.htm">http://www.zuggsoft.com/zmud/msp.htm</a>

This allows a MUD to trigger playing WAV and MID files.  Traditionally
the sound files are downloaded in advance manually by the user, though
there's now a way to use URLs.  You can't easily preload the sounds,
though.

MSP doesn't have content-based autodetect the way Pueblo and
FireClient do.  You'll have to detect it as a telnet option, or set it
manually.

This is traditionally used by Diku-style MUDs, if at all.

======================

xmlterm.org

===========================================================================

ZMUD

  MCP in ZMUD - <a href="http://www.zuggsoft.com/zmud/mcp-dev.htm">http://www.zuggsoft.com/zmud/mcp-dev.htm</a>
  MXP in ZMUD - <a href="http://www.zuggsoft.com/zmud/mxp.htm">http://www.zuggsoft.com/zmud/mxp.htm</a>

===========================================================================

We may eventually probably want to support Pueblo and Fireclient.
They're slightly different but they work very similarly to each other.
Each basically takes a cut-down HTML syntax to embed things like links
and pictures.  You can easily be compatible with both.

===========================================================================
From the FireClient site:

* Detection
  o Client detection is initiated by the server upon a new connection
  o The server immediately sends the following string:
    + "Autodetecting IMP...v1.xx" where xx stands for the IMP server
      version (i.e. "30" is the most recent)
  o The purpose of this string is to identify an IMP-enabled server to
    regular mudders and to tip off IMP clients while informing them of
    the IMP server version.
  o Anytime an IMP-enabled client initiates a connection, it has an
    IMP-check tag enabled until it sees that trigger or it recieves 2 of
    more lines of data that aren't that trigger. 
  o Once a client detects IMP, it responds immediately to the server with
    the following string:
    + "v1.xx" where xx stands for the IMP client version (i.e. "50" being
      the newest release)

  IMP is now offically enabled and detected for both sides of the connection.

  o A non-required third step is for the server to acknowledge the receipt
    of the IMP client's version by sending the IMP command <IMPDEMO> which
    triggers a demo on the client's computer.

* Recognized Commands
  o <IMPDEMO> - Triggers a display determined the completes at a minimum
    acknowledging enabled IMP capabilities
  o <A HREF="http:// to signal a URL or anything else for a command to
    get sent to the MUD">text to display</A> - Format for inline links in
    the client window
  o <IP> - Replaces text with your IP address
  o <D | DEFAULT FACE=fontname SIZE=fontsize COLOR=acolor BACK=acolor
    COMMAND=acolor> - Allows you to set defaults for the client to return
    to after a </F> command or before text is even altered.
  o <DEFSHOW> - Displays current defaults in client window
  o <HEIGHT SUPER|SUB=#> - Superscripts or subscripts text by # pixels
  o <S> | <STRIKETHRU> / </S> | </STRIKETHRU> - Enables/disables strikethru
  o <C> | <CENTER> / </C> | </CENTER> - Enables/disables text centering
    (usually better to append a line break to function properly)
  o <B> | <BOLD> / </B> | </BOLD> - Enables/disables bold text
  o <I> | <ITALIC> / </I> | </ITALIC> - Enables/disables italic text
  o <U> | <UNDERLINE> / </U> | </UNDERLINE> - Enables/disables underlined text
  o <FONT | F  SIZE="point size" COLOR=<red/orange/yellow/green/etc>
    FACE="font name"> / </FONT> | </F> - Enables/disables font effects
  o <CT> - Clears the active text window
  o <CS> - Clears the status window
  o <AUDIO FILE=filename or URL> - Plays an audio file
  o <STOPAUDIO> - Halts playback of audio
  o <WINDOW SIZE=[MIN/MAX] NEW=title TITLE=title - Maximizes, minimizes,
    creates a new window with a certain title, or changes the active
    window title
  o <CONNECT> / <DISCONNECT> / <RECONNECT> - Connects, disconnects, or
    reconnects with the active window's host and port
  o <CONNECTION HOST=host PORT=port> - Changes active host and port for
    active window if disconnected, and then creates a new window bound to
    new host and port
  o <ST | STATUS MSG=statusmsg BOX=msgbox INP=popupquestion
    INIT=init commands to do before answer to popup question> - Creates
    any or all of the following: a status message, a message box, or a
    popup input box that will send back to the server the INIT commands
    followed by the user's response to the INP question
  o <IMG SRC=file/URL ALT=description text> - Displays a file in the current
    active window location and sends an ALT message to the status window
  o <BACK COLOR=<red/orange/yellow/etc>> / </BACK> - Sets the background to
    a solid color or returns background to original color
  o <BR> - Inserts a line break into the text stream

* Notes: The following abbreviations are recognized... F for FONT, F again
  for FACE, S for SIZE, C for COLOR, O for OFFBIOS. All IMP commands are
  case insensitive. For sake of syntax, do not add spaces between a sub tag
  (i.e. href) and the = sign. That also goes for between the = and the
  value (i.e. "http://firebolt.com")

===========================================================================

From Pueblo:


 The Pueblo client watches for lines of this form:
     This world is Pueblo 2.50 enhanced.
 When it sees a line of that form, it sends the World this command:
     PUEBLOCLIENT 2.50 md5="checksum string" other_attribute1="value"
     other_attribute2="value" etc.

In this example, '2.50' is the version of the Pueblo client sending
the command, and the 'md5' parameter indicates a secure checksum
string. This secure string should be stored in a secure location by
the world. We'll allow you to perform some potentially abusable
operations using this checksum, and you may wish to limit the users
that may perform these operations.
  
Note that the PUEBLOCLIENT command may have any number of attributes
specifying information on the client. Your implementation should be
able to recognise those attributes that you are expecting and ignore
all others. Also note that the command may be sent either once or
twice; the most recent one is always the correct one. We're not
exactly sure at the moment why this happens.
  
Upon receiving this PUEBLOCLIENT command, the World may send the
following sequence, to tell the Pueblo client to begin interpreting
the World's output as HTML:
     </xch_mudtext><img xch_mode=html>
You may want to send the "This world is Pueblo 2.50 enhanced" line and
accept the PUEBLOCLIENT command before the user logs in, so that you
can send HTML from the outset.  You may also want to provide special
commands for sending HTML-formatted text and convert other text to
escaped HTML (converting < to <, etc.).

At present, the version number you supply in the "This world is Pueblo
2.50 enhanced" line is not used by the Pueblo client; it sends its own
version regardless. The only difference, in fact, is that the MD5 and
other attributes are not sent if the version is too low. However, your
world should pay attention to (or at least record) the version sent
back by the client, as some features available in one version of
Pueblo may not be available in earlier versions. Or later versions,
for that matter; some features may be discontinued (such as VRML
support).

This is the sequence of changes we typically make when we're Pueblo
Enhancing a MUD:

1. Create a new "flag" which indicates that a user is using a Pueblo
compatible client.  This flag should be removed from the player when
they log out, since they may log in with both Pueblo and a text
client.

    [...]
    On LP-MUD, this was a static int in player.c, so it got reset
    when they logged out automatically. We also added a new function
    to player.c: query_is_html(), which allows rooms and objects to
    query a player's object about whether it supports HTML.

2. Display the string "This world is Pueblo 2.50 enhanced" and watch
for the PUEBLOCLIENT command coming back from the client. When you get
PUEBLOCLIENT, set the flag created in step 1 above.

    [...]
    For LP-MUD, we added this in player.c's logon2(). We also did an
    'add_action("puebloclient", "PUEBLOCLIENT");' and the
    corresponding puebloclient function so that people could do a
    PUEBLOCLIENT after they log in, but this was optional.  You may
    also want to add support for 'PUEBLOCLIENT off', which turns off
    the HTML output for testing. Pueblo itself will never send this
    command.

3. Add HTML escaping. HTML has a few special characters that require
escaping. You should convert these characters to the corresponding
HTML sequence, as described in the following table. (Note: those
trailing semicolons inside the strings are important.)

        Character:
                            HTML sequence:
             <
                                 &lt;
             >
                                 &gt;
             &
                                &amp;
             "
                                &quot;

    In LP-MUD, we did this in dgd/lib/player.c's catch_tell().

4. Now you won't be able to output any HTML anchors, since all your
output will be escaped, so you need a second output path that gets
around the HTML escaping you did in step 3.

    [...]
    In LP-MUD, we added write_html(), which was just like write() but
    skipped the HTML escaping. This was in dgd/lib/interactive.c. We
    also had to do tell_object_html(), catch_tell_html(), etc.  You
    basically have to duplicate the output path from the normal input
    points (write(), catch_tell(), etc.) down to the function where
    you do the escaping, either calling different functions or passing
    some flag that indicates that escaping should be skipped.

5. Add HTML anchors for exits. When you list the obvious exits in a
room, you might want to have each exit be an anchor, like this:

    <a xch_cmd="east" xch_hint="Go east">east</a>
    In LP-MUD, this was in room/room.c and looked like:
        while (i < sizeof(dest_dir)) {
          if (this_player()->query_is_html()) {
            /* Write the exit as an anchor */
            write_html(" " + "<a xch_cmd=");
            write(dest_dir[i]);
            write_html(" xch_hint=\"Go ");
            write(dest_dir[i]);
            write_html("\">");
            write(dest_dir[i]);
            write_html("</a>");
          } else {
            write(" " + dest_dir[i]);
          }
        }

    Note that we mix the use of write() and write_html(). If the exit
    name has one of <>&" in it, you'll need those characters to be
    escaped, but you don't want the "<a", ">", or "</a>" to be
    escaped.

6. Add VRML URL support to rooms. When a user walks into a room, if
that room has the URL of a VRML file associated with it, you want to
send them a <img xch_graph=load href="<the URL>">. Note: don't do this
for new implementations, as VRML is not supported by Pueblo/UE.

    [...]
    For LP-MUD, this was in room/room.c. We added a static string
    vrml_url;. In init(), we send the load if appropriate.

7. Do the same, for MIDI background sounds. This is just like the VRML
URL support in #6, only for a sound URL.

8. If no VRML_URL is set on the room, send <img xch_graph=hide>
9. Build away!

If you're building VRML files, and want to put them on your own Web
server, you'll need to tell your Web server what MIME type a VRML file
is. If you're using NCSA or Apache HTTPD, add this line to
config/mime.types:
     x-world/x-vrml   wrl vrml
  
If you Pueblo Enhance a MUD, send us your patches, so others can
follow in your footsteps! Send them to uecasm@users.sf.net. If you run
into problems enhancing your mud, send us mail to the same address.

You might want to join the pueblo-worlds mailing list. Instructions
for doing so can be found on the Pueblo/UE website.

The Pueblo/UE website is <a href="http://pueblo.sf.net/">http://pueblo.sf.net/</a>. It has the Pueblo FAQ,
instructions on downloading the latest version, etc.

===========================================================================

Pueblo supports a much larger subset of HTML, so it's less clear what
to send and how it behaves, at least on the face of it.  They also
support some nonstandard HTML extensions.

Their help document is java-based (bastards!) and seems not to be
included in the CVS source (bastards!) so I'll excerpt bits of it.
It'll be messy because they don't have a single linear version of it,
just a choppy version with a lot of small HTML pages (bastards!).



 Document Structure Elements

  <!-- Comments -->  <body>  <head>  <html>  <title>


 Anchor Element

  <a>


 Embed Element

  <embed> 


 Image Element

  <img>


 Block Formatting Elements

  <address>  <basefont>  <blockquote>  <br>  <center>  <h1>  <h2>  <h3>
  <h4>  <h5>  <h6>  <hr>  <listing>  <p>  <plaintext>  <pre>  <samp>
  <xmp>


 Character Formatting Elements

  <b>  <cite>  <code>  <em>  <font>  <i>  <strike>  <strong>
  <tt>  <u> 


 List Elements

  <dl>  <dir>  <li>  <menu>  <ol>  <ul> 


 Form Elements

  <form>  <input>  <option>  <select>  <textarea> 


 Unsupported HTML elements

  <isindex>  <kbd>  <link>  <meta>  <nextid>  <table>  <var>


======================

There's a *lot* of documentation on this stuff, and not all parts of
the supported tags are also supported -- attributes, for instance, are
frequently trimmed to a manageable set.  That's fair, but it's also
very poorly documented.  Since Pueblo is designed to be able to view
real web pages rather than just be a vaguely HTML-y terminal program,
that means it's got a pretty sprawling spec.  At least, it would if it
were all documented in one place :-)

The helpfiles are on SourceForge.  Luckily, the MUD doesn't have to
know the whole thing and how to handle it, it just needs to know the
challenge sequence and then send whatever subset of tags it feels
like.  So we'll burn that bridge when we get to it.

-----------------------------------------------------------

XMLterm

Ho-Sheng Hsiao says:

I've heard of an Xterm implemented to use streaming HTML/XML tags instead of
VT* codes. Think, Pueblo. This was a modification to the current Mozilla
browser. Or more precisely, it uses the XUL toolset in Mozilla and some
other stuff to create the Xterm.

You can check out the site at <a
href="http://www.xmlterm.com">http://www.xmlterm.com</a>.

Considering that Mozilla has a built in IRC client written mostly in
Javascript et. al., adapting that serve this. 

-----------------------------------------------------------

ZMP - Zenith MUD Protocol

http://www.awemud.net/zmp/

Kinda like MCP or MXP.  It seems to have gone away.