diff --git a/doc/concepts/intermud b/doc/concepts/intermud
new file mode 100644
index 0000000..abe2b4f
--- /dev/null
+++ b/doc/concepts/intermud
@@ -0,0 +1,224 @@
+CONCEPT
+        intermud
+
+DESCRIPTION
+        There are several intermud protocols which define how (players on)
+        different muds can communicate with each other. The protocols are
+        in general not muddriver or mudlib dependant, though the number of
+        implementations is limited.
+
+        This text is about the rather old widely spread 'Zebedee Intermud',
+        which is also called 'Intermud 2' altough it differs quite a lot
+        from the real Intermud 2 protocol.
+
+        Full information on the newer Intermud 3 could be found on the
+        web at http://www.imaginary.com/protocols/intermud3.html so there
+        is no discussion here - the following is just about Zebedee Intermud
+        (aka Intermud 2).
+
+        Zebedee Intermud communication is handled by the /secure/inetd
+        object, originally written by Nostradamus for Zebedee with some
+        extensions that are discussed in inetd(C). How the data is
+        actually sent across the network is described in intermud.basic(C).
+
+SERVICES
+        Note that the fields "NAME" and "UDP_PORT" should be present in
+        every message. Very common are the fields "ID" (used whenever an
+        reply is expected) and "SND" (the sender: he should receive the
+        reply). These fields will not be mentioned in the list below.
+
+        Request types are listed on the leftmost row (e.g. "REQ=channel"),
+        associated header are listed indented.
+
+        "channel"
+            The channel-request is used for sending a message on any
+            channel. The "CMD" field is optional and may be omitted for
+            normal messages. Note that you should not send an history or
+            list request to _all_ known muds!
+
+            "CHANNEL"
+                The channel on which a message is send (the standard
+                channels are "intermud", "intercode", "interadm", "d-chat",
+                "d-code" and "d-adm"; on the d-channels German is spoken)
+
+            "DATA"
+                The message to be send (not used with history/list request)
+
+            "CMD"
+                The body of this header may be:
+                ""        for normal intermud messages,
+                "emote"   if the message is an emote/gemote,
+                "history" for an history request: the last 20 lines of
+                          this channel will be shown.
+                "list"    to list all remote users listening to this channel
+
+            "EMOTE"     (optional)
+                The body is 1 if the message is an emote.
+                The body is 2 if the message is a gemote.
+
+        "finger"
+            Retreive information about a player or creator on a remote mud.
+
+            "DATA"
+                The player of whom information is requested
+
+        "locate"
+            Check whether a certain player is logged on at a remote mud.
+            This request is usually send to all known muds at the same time.
+
+            "user"
+                Name of the person who requests the information.
+                This is used by the sending mud only and has to be included
+                in the reply.
+
+            "vbs"
+                The verbose option has only two pre-defined values:
+                1 Even report when the result was negative
+                2 Don't do timeouts, but keep waiting
+                This is used by the sending mud only and has to be included
+                in the reply.
+
+            "fnd"
+                The found option is only used in the reply and it's value
+                is either 1 (success) or 0 (failure). The absence of a
+                found parameter indicates failure as well.
+
+            "DATA"
+                The player to find.
+
+        "man"
+            Retreive a manual page from a remote mud. Many muds don't
+            support this feature...
+
+            "DATA"
+                The name of the requested manual page
+
+        "mail"
+            An extension to the standard protocol, by Alvin@Sushi. This is
+            used to send mails from one mud to another.
+
+            "udpm_status"
+                This field should only be used in the reply and indicates
+                how mail is handled. Currently there are four pre-defined
+                values for the status field:
+                0 time out
+                1 delivered ok
+                2 unknown player
+                3 in spool (will be delivered later)
+
+            "udpm_writer"
+                Name of the person who wrote this mail
+
+            "udpm_spool_name"
+                Should be returned as sent, this value is used to remove
+                the mail from the spool directory after it has been
+                delivered (or refused)
+
+            "udpm_subject"
+                Subject of the mail message
+
+            "DATA"
+                The body of the mail (the actual message)
+
+        "ping"
+            A ping request has only the standard fields, the reply is
+            usually a short string like " is alive."
+
+        "query"
+            Get standard information about another mud. This is the only
+            command of which the reply may not include a load of rubbish,
+            but should only hold the requested information, so that it can
+            be parsed by the server.
+
+            "DATA"
+                The following queries are pretty much standard:
+                "commands" List all commands that are supported by the inetd
+                "email"    The email-address of the mud administrator(s)
+                "hosts"    A listing of all hosts in a special format [t.b.d.]
+                "inetd"    The version number of the inetd used
+                "list"     The list of all items which can be queried
+                "info"     A short human-readable string with practically
+                           "query" information
+                "mud_port" The portnumber that players connect to on login
+                "time"     The local time for this mud
+                "users"    A list of the people that are active in this mud
+                "version"  The version of the mud-driver (and library)
+                "www"      The URL of the mud's web page (e.g.
+                           http://mud.stack.nl/)
+
+        "reply"
+            This request method is used for _all_ replies.
+
+            "DATA"
+                A human-readable string, containing the reply to a given query
+
+            "RCPNT"
+                The same name as in the "SND" field or the query; Usually
+                this is the name of the player who initiated the query
+
+            "QUERY"
+                This field is only used in a response to a "query" request
+                and should be equal to the "DATA" field of that request
+
+            "vbs"
+                This field is only used in a response to a "locate" request
+                and should be equal to the "vbs" field of that request
+
+            "user"
+                This field is only used in a response to a "locate" request
+                and should be equal to the "user" field of that request
+
+            "fnd"
+                This field is only used in a response to a "locate" request
+                and should be 1 if the player was located and 0 otherwise
+
+        "tell"
+            Say something to a player on another mud.
+
+            "RCPNT"
+                Name of the player to whom you are talking
+
+            "DATA"
+                Whatever you wish to say to this person
+
+            Optional emote-tos are handles are also handled as tells, so
+            muds without emote-to support display them as reasonable readable
+            tell message.
+
+            "RCPNT"
+                Name of the player to whom you are talking
+
+            "METHOD"
+                The body of this header may be:
+                "emote"   if the message is an emote
+                "gemote"  if the message is a genitiv emote
+
+            "DATA"
+                The text to be emoted prepended with "*" and appended
+                with "* ". If you display the emote you have to cut the
+                stars off. Muds that do not process emote-tos display the
+                emote as tell message with the stars as indication of
+                the message's emote meaning.
+
+        "who"
+            List the people that are active on a remote mud. The anwer
+            usually contains some active information about the players,
+            like titles, levels or age.
+
+            "DATA"
+                Not supported by many muds. Introduced August 1997.
+                Additional switch(es) (blanc separated) that change the
+                appearence of the resulting list. The switches normally
+                resemble the switches used inside of that mud for the 'who'
+                command.  Typical values include:
+                "short" "s" "-short" "-s" "kurz":
+                    Return a concise listing.
+                "alpha" "a" "alphabetisch" "-alpha" "-a"
+                    Sort the players alphabetically.
+
+AUTHOR
+        Information taken from Outerspaces documentation to be found
+        on http://mud.stack.nl/intermud/
+
+SEE ALSO
+        inetd(C), intermud.basic(C), imp(C)