Notes on the I3 protocol

This document contains comments on the original specification at intermud.org in the hope to come to a new I4 spec that solves many of the problems and ambiguities of the I3 protocol.
Also see Tim@TimMUD's comments.

Channels

Implementing channel messages as broadcast packets is wrong.
Channel messages (t/e/m) are intercepted at the router and then sent to listening muds, this functions as a multicast echo service, not as a broadcast. Hence, channel messages should be directed at the router itself instead.

Forwarding of unknown packet types

One should consider to apply filtering to broadcasts so that muds only receive broadcasts for services they claim to implement (in the services mapping in a startup-req). The router itself doesn't need knowledge of any packet types other then those that can be sent to the router directly. The router does require a list that associates packets to known services to implement such a filter, and packets for non standard services can't be treated like this.

Error types

unk-channel

Muds can return this error upon receiving a channel-m, channel-e or channel-t packet for a channel they do not want to receive.

Routers can return this error when receiving a request for a channel they do not know about. (note that the I3 spec fails to mention this, but it is common practise)

bad-proto

Routers should return this in the following cases:

• channel-add/remove/admin requests and channel-e/m/t messages not directed at the router itself, channel-m/e/t messages not aimed at the network might be accepted for backward compatibility purposes.
• any packets other then a startup-request-* before the connecting mud is authenticated

Note that errors in the packet format should not result in a bad-proto error, they should result a bad-pkt error instead.

Packets that need special handling

ucache-update

Muds should always accept those, even when not supporting the ucache service. Returning errors on ucache-update packets will cause spammy behavior on some routers that don't implement filtering of unknown packets on behalf of the destination mud.

New packet types proposed for I4

startup-req-4

Sent by a mud, identical to startup-req-3 except for the service type.
Indicates that the connecting mud understands version 4 of the intermud protocol, and understands the packets described below.

mudlist-req

Can be used by a mud to request a fresh copy of the mudlist.

({"mudlist-req",
  5,
  string src_mud,      // originating mud
  string src_user,     // 0
  string dst_mud,      // the router
  string dst_user,     // 0
})

The router should reply by sending a complete mudlist.

mudlist-delta

Sent by the router to indicate a change to the mudlist.

({"mudlist-delta",
  5,
  string src_mud,      // the router
  string src_user,     // 0
  string dst_mud,      // the destination mud, can be 0
  string dst_user,     // 0
  int mudlistid,       // new mudlist id after applying this delta
  string mud_name,     // the name of the entry to be changed
  mixed * data,        // new data for this entry, or 0 to remove this entry
})

Note that removed entries are not sent as a mapping, there are drivers that don't like (["something":0]) because on those drivers assigning 0 as mapping value removes the index from the mapping. This means that such muds would receive (["removed mud":0]) as ([ ]) and won't know which entry to remove from their list, instead, the data part of the delta packet will be 0 to indicate removal.

TODO: add similar request and delta packets for the channel list.