+=head1 Applications
+
+In the past messaging applications such as DX Cluster software have maintained
+a fairly strict division between L</Node>s and L</User>s. This protocol attempts
+to get away from that by deliberately blurring (or, in some cases, removing)
+any distinction between the two.
+
+Applications that use this protocol are essentially all peers and therefore the
+only real difference between L</Node>s and L</User>s is that a node has one or more
+listeners running that will,
+potentially, allow incoming connections from other L</Node>s, L</Endpoint>s or L</User>s. These
+routable entities are called L</Terminal>s.
+
+Any application that is a sink and/or source of data; is capable of obeying
+the protocol message construction rules and understands how to deduplicate incoming messages
+correctly can operate as a routeable entity or L</Terminal> in this protocol. It is called an L</Endpoint>.
+
+An L</Endpoint> is called a L</Node> if it accepts connections from L</Endpoint>s and is
+prepared to route messages on their behalf to other L</Node>s or L</Endpoint>s. In addition it
+may provide some other, usually simpler, interface (eg simple telnet access) for direct user access. Acting
+in the protocol, on their behalf.
+
+The concept of an L</Endpoint> has been invented because modern clients are
+capable of being more intelligent than simple
+character based connections such as telnet or ax25. They also wish to be able to
+distinguish between the various classes of message, such as: DX spots,
+announces, talk, logging info etc. It is a pain to have to do it, as now,
+by trying to make sense of the (slightly different for each piece of node
+software) human readable "user" version of the output. Far better to pass on
+regular, specified, easily computer decodable versions of the message,
+(i.e. in this protocol) and leave
+the human presentation to the application.
+
+It also helps to modularise the various interfaces that may be implemented such
+as the legacy, character based connections of existing PC protocol based nodes.
+They should be treated
+as local clients, in fact as L</User>s, B<not> as peers in this protocol. It is likely that, in order
+to do this, some extra L</Tag>s will need to be defined at application level.
+
+=head1 Definitions
+
+In this document we use a number of terms that need to be defined.
+
+=head2 Terminal
+
+A L</Terminal> is a routable entity, in other words: a callsign or service that can be routed
+to, that lives at one or a few L</Node>s.
+
+=head2 User
+
+A L</User> is a connection to a L</Node> (that allows such connections)
+that does not occur in protocol. All L</User>s shall be identified with a name
+of up to 12 characters in the set [-0-9A-Z_]. All messages have to be routed via the
+L</Node> to which this L</User> is connected.
+
+=head2 Endpoint
+
+An L</Endpoint> is a connection to a L</Node> that uses the protocol. From a routing point of
+view, it is indistiguishable from a L</Node>. The L</Endpoint> is responsible for creating and decoding
+well formed protocol messages. An L</Endpoint> does not route beyond the immediate L</Node>(s) to
+which it is connected. It may also be a L</Service> connected to a L</Node> which provides some
+addressable service (such as a database) that can be queried.
+
+=head2 Node
+
+A L</Node> is connected to other L</Node>s. It is responsible for routing messages in protocol
+from other L</Node>s or L</Endpoint>s, whether directly connected or not. Optionally, a L</Node>
+may provide other interfaces, such as direct L</User> connections or legacy PC protocol speaking
+DX Clusters.
+
+=head2 Channel
+
+A L</Channel> is a L</Group> address that is not a L</Terminal>. It is (unless qualified by a L</Terminal>)
+broadcast on all a L</Node>s interfaces unless preventing by some filtering or other local policy on
+that L</Node>.
+
+=head2 Service
+
+A L</Service> is application that either plugs into or connects as an L</Endpoint> to a L</Node>. It is an
+application that, in effect, is a database. In other words: queries are sent to the L</Service> and it sends
+back a reply.
+
+=head1 Routing Section