TACS DRAFT Protocol Specification
Brian A. Lantz/KO4KS,
[email protected],
[email protected]
v0.01, 04 May 1997
This is the DRAFT Protocol Specification for the Tampa Advanced Con-
verse Server. This Specification is updated as the work on TACS pro-
gresses, so it is a dynamically changing document at this time.
______________________________________________________________________
Table of Contents:
1. Overview
1.1. Why two protocols?
1.2. TACS extends TPP
1.3. Determining Protocol Mode
2. Command Notation Syntax
3. HOST Command Field Sizes
4. TACS Server Commands
4.1. Commands valid in 'UNKNOWN' State
4.2. Commands valid in 'HOST' State
4.3. Commands valid in 'USER' State
4.4. Commands valid in 'OBSERVER' State
5. Concluding Thoughts
______________________________________________________________________
1. Overview
There have been several predecessors to TACS, most recently the Tampa
PingPong Server (TPP), also by the author of TACS. TPP attempted to
extend the PingPong (PP) Server's Protocol in order to overcome it's
deficiencies and still remain compatible. Once a separate protocol was
determined to be required, the TPP project was renamed to TACS, to
prevent confusion.
1.1. Why two protocols?
The PP server's protocol was an excellent protocol for a couple of
hosts to be connected, especially if the machines occasionally came
down. Once the Internet backbone of servers developed and the normal
server stayed up for months at a time rather than hours/days, many
deficiencies were discovered.
One of these problems was accidental server loops. This where one or
more hosts have multiple links into the same network, and where
some/all of their commands get into perpetual loops, bouncing commands
back and forth in the network. There is no way in the PP Protocol to
discover this or to correct it.
Another problem with the PP Protocol was that once a destination was
'heard' it was never removed, even if it's connection no longer
existed.
There were also many cases where user input could be implemented on a
server to be larger that the PP server could handle, and could crash
the PP server. Since the PP Protocol never defined the acceptable
lengths of any fields, nor checked those lengths, this caused MANY
problems. One 'experimental' server could continually bring down every
host on the network.
Several other assorted issues became troublesome as the network grew.
Security issues were NOT addressed in the PP Protocol. There was no
way to extend a network by servers adding custom commands. There was
no way to automatically determine the makeup of a network.
1.2. TACS extends TPP
While TPP was able to address SOME of these issues and remain a simple
superset of the PP Protocol, it became obvious that if the network was
to improve and be extended, a new protcol would be needed.
So, TACS took the enhancements of TPP and extended them. Most of the
changes are made by simply placing the Host of origin in each command,
and by adding to the destination data some information telling where
the site is linked to and whether or not the site is TACS-compatible.
While every attempt is being made to ensure that the TACS-mode
Protocol is bulletproof, any TACS server accepting non-TACS server
connections IS vunerable to some of the same problems as PP/TPP
servers, including the possibility of unexpected crashes. Much time
has been taken in the design of TACS to prevent this, but the author
is not stupid enough to believe that all problems have been identified
and solved.
1.3. Determining Protocol Mode
There are (possibly) two different protocols that can be used between
hosts. The original PingPong protocol is used if the 't' facility is
NOT given in the HOST command.
TACS servers can be compiled without PP Protocol support, and even
those with the PP support compiled in can be configured at runtime to
ignore HOST commands for non-TACS HOSTS. This is a choice of the
SYSOP, determined by their need.
Those servers in the central core of the Internet network will
probably decide NOT to support connections from non-TACS servers,
since these servers are depended on by many other servers.
2. Command Notation Syntax
All user commands contain only printable ASCII characters. HOST-to-
HOST commands start with "/\377\200" (for PingPong protocol commands)
or "/\377\201" (for TACS protocol commands).
PingPong HOST Protocol sequences are notated in this document as
beginning with "/.." and TACS HOST Protocol sequences beginning with
"/++".
Explicit strings in Protocol sequences are notated surrounded by
single quotes.
3. HOST Command Field Sizes
All fields in HOST Commands are sent and received in ASCII, even for
numeric values. The following is a list of the fields (as used in the
rest of this specification) and their valid maximum length.
o channel - 5 characters maximum
Valid values are 0 - 32767
o cmdname - Any number of characters
o connhost - 64 characters maximum
o dest - 64 characters maximum
o facilities - 8 characters maximum
Subject to change in the future, if new features are added.
o fromchannel - 5 characters maximum
Valid values are 0 - 32767
o host - 64 characters maximum
o mode - 1 character maximum
o nickname - 64 characters maximum
o options - 12 characters maximum
o parameters - Any number characters
o password - 64 characters maximum
o software - 8 characters maximum
o topicname - 512 characters maximum
o text - Any number of characters
o time - 10 character maximum
o tochannel - 5 characters maximum
Valid values are 0 - 32767
o touser - 64 characters maximum
o ttl - 12 characters maximum
o user - 64 characters maximum
4. TACS Server Commands
A TACS connection may have four states: UNKNOWN, USER, OBSERVER or
HOST. When a connection is established, it starts in the UNKNOWN
state.
Note that no attempt is made in this Specification to describe non-
TACS HOST State commands. For such information, consult the
documentation for the desired server.
4.1. Commands valid in 'UNKNOWN' State
o /CSTAT
This is the same as the normal "links" command in the USER state
except you don't need to login in order to get the display.
o /..HOST host [[software] [facilities]]
o /++HOST host software facilities [password]
This command is sent by a connecting host, in order to 'link' to
the connected host, and to be placed into the HOST state. It is
like the 'NAME' command, in that the server can have security in
place that could prohibit this server from linking.
The 'host' name must be given. The 'software' string and 'facility'
string are only optional for the PP-mode version of this command.
No server can be connected in TACS-mode without the 'software' and
'facilities' being specified.
The 'software' string may be up to eight characters long. The
'facility' string consists of single letters, indicating features
supported by the 'host'. Those feature attributes already assigned
are:
o A - "away feature" support
o d - "destination forwarding" support
o m - "channel modes" support
o n - "TNOS-style nickname" support
o p - "ping pong link measurement" support
o t - "TACS-compatible" server - either running TACS or some other
server implementing the TACS spec. If only 't' is given then
'Admnp' is also implied.
Those servers who indicate TACS-compatibility should ONLY send
TACS-mode HOST commands and will only be sent TACS-mode commands.
Those that do not have TACS-compatiblity MAY have their connection
dropped after sending this command, if the host being connected to
only permits TACS servers to connect.
TACS-mode connects allow an optional 'password' field for
additional security. This is not implemented at the moment.
If you like to assign new attribute characters, please drop me a
note with a brief description of the feature. I will consider
including it in further release of the specification.
o /NAME user [channel]
This command handles a user login. If the login is successful, the
state will be changed to eith USER or UNKNOWN, depending on the
security of the server, and the settings for the user logging in.
If the 'user' is accepted, the sign-on message will be displayed,
the user's name will be set to 'user', and the 'channel' specified
will be entered (or the default channel if no 'channel' was given).
The channel number must be in the range of 0..32767 for
compatibility with OLD Converse servers. This restriction will
probably change in the near future.
o /OBSERVER user [channel]
This command is the same as the 'NAME' command, except that the
user will be treated as an 'observer'.
o /ONLINE <'a'|'l'|'q'>
This is the same as the normal "who" command in the USER state
except you don't need to login in order to get the display.
o /RESTRICTED user [channel]
This command is the same as the 'NAME' command, except that the
user will be treated as a 'restricted' user.
o /UPTIME
This command displays information on how long the server has been
'up'. Other information may also be displayed.
4.2. Commands valid in 'HOST' State
o /++ACTV
This is a request to place this idle link as an active link. This
is a point-to-point command, and is NOT propagated to the network.
o /++AWAY host user time [text]
!! changed order of host and user fields
This marks 'user'@'host' as being away. If 'text' is not present,
then he is back again. The given text should be stored in your
server to give a hint to the users doing a private message to an
person who is away. Time indicates, when the command was issued.
o /++CMSG host user channel text
!! added the host field
This is a channel message. The 'user'@'host' wrote it to all on the
'channel'. The 'text' should be delivered to all users on this
channel, and to all hosts who are a downstream for a user in this
channel.
If the 'user' is "conversd", then this a broadcast message, and no
formatting should be done to the message. Otherwise, the server can
render the 'text' in whatever manner it desires.
o /++DEST host mode connhost time [software]
!! added the mode and connhost fields
The 'host' is reachable via the host sending the command, and can
be reached in 'time' seconds. The 'connhost' is the server which is
the connection point for 'host' into the network.
The 'mode' field indicates whether the destination is TACS-
compatible ('Y') or not ('N').
The destination 'host' is running the named 'software'.
o /++ECMD host user cmdname [parameters]
!! added the host field
If 'user' is "conversd", then this 'host' is broadcasting that it
is the server of an extended command named 'cmdname'. In this case,
the 'parameters' is ignored.
Otherwise, this is a request from 'user'@'host' to execute the
command 'cmdname', with 'parameters' passed to the command. Any/All
hosts supporting this command can respond, assuming that each one
passes the command on down the line, or can act on the command and
finish the command. Any responses to 'user' are sent via the
network as 'UMSG' commands.
o /++HELP host user cmdname
!! added the host field
This is a request from 'user'@'host' to retrieve the help
information for command 'cmdname', which is an extended command
(ECMD) somewhere on the network on connected servers. Any/All hosts
supporting this command can respond, assuming that each one passes
the command on down the line, or can act on the command and finish
the command. Any responses to 'user' are sent via the network as
'UMSG' commands.
o /++IDLE
This is a request to place this active link as an idle link. This
is a point-to-point command, and is NOT propagated to the network.
o /++INVI host user touser channel
!! added the host field
An invitation from 'user'@'host' is sent to 'touser' via the whole
network. If the user is found on the local system, he should be
informed about the invitation and an answer string should be sent
to 'user' using the UMSG command.
o /++LINK host user dest
!! added host field
This is a request from 'user'@'host' for a link listing from the
server 'dest'. This command does get propagated via the network
until it gets to host 'dest'. The response is sent via the network
using 'UMSG' commands.
o /++LOOP host
!! remove? This indicates that a routing loop has been discovered.
This connection should be dropped upon receipt of this message.
o /++MODE host user channel options
!! added host and user fields
This indicates that 'user'@'host' has set the channel mode options
for channel 'channel'. An option is enabled if it is preceeded with
a '+', and disabled if it is preceeded with a '-'. The possible
options currently supported are:
o i - invisible channel, its existence is not displayed
o l - local channel, no text forwarding is performed
o m - moderated channel, only channel operators may write
o o - channel operator, name of operator immediately follows
o p - private channel, invitation needed to join into
o s - secret channel, no channel number is displayed
o t - topics may be set only by channel operators.
None of these options have any parameters, except the 'o' option.
For this option, the name of the channel operator immediately
follows the 'o' (with optional spaces in between). If further
options are given on the line, then there should be a space
terminating the operator name.
o /++NICK host user nickname
!! new - replacing the UADD command
The 'user'@'host' sets his 'nickname'. While some hosts may have
the ability for the user to set a nickname disabled, all servers
should pass this command through the network.
o /++OBSV host user time fromchannel tochannel ['@'|text]
!! reversed order of user and host
This indicated that 'user'@'host' has left 'fromchannel' and has
joined 'tochannel' at 'time' and that 'user' is an OBSERVER ONLY.
The local server should place 'user' in OBSERVER state. The 'text'
is his personal name (like in the UDAT command). A '@' in the text
field indicates an empty personal note. If 'tochannel' == -1
('user' is leaving the channel) the additional 'text' indicates the
reason for the signoff.
o /++OPER host user channel
!! reversed order of channel and user
This indicated that 'user'@'host' has either become the channel-
operator or a system operator (if 'channel' == -1). The status of
'user' should be retained locally, if needed.
o /++PING
This is used to do a 'PingPong' to determine the roundtrip time
between two servers. These values help determine the roundtrip
times for all destinations. A pong answer is requested. This is a
point-to-point command, and is NOT propageted to the network.
o /++PONG time
This is the response to a PING command. The 'time' is the sender's
own measured time (i.e. ping sent to pong received). Special
values:
o -1: you don't do measurements.
o 0: I did not make measurements yet, but it's implemented.
This is a point-to-point command, and is NOT propageted to the
network.
o /++REFR
This instructs the remote system to send a refresh of the listing
of destinations. This command is a point-to-point command, and does
NOT get propagated to the network.
o /++ROUT host user dest ttl
!! changed order of fields user and dest and added host
The 'user'@'host' queried his local server for the route to a given
remote host ('dest') in the network. Upon receipt of such a request
for your local server, the server should send back a personal
conversd response (using 'UMSG') to 'user', containing this string:
"*** route: <myname> -> <downstreamname> -> <dest>"
While collecting all these messages, the user will learn the
individual route to his desired destination, hop by hop. A 'ttl'
greater than 0 indicates that this query should be forwared to the
next hop.
o /++SYSI host user dest|'all'
!! added host field
The 'user'@'host' requests system information for server 'dest' or
all systems on the network At the MINIMUM, the email address of the
Converse sysop should be available via this command.
o /++TOPI host user time channel [topicname]
!! reversed order of host and user
The 'user'@'host' has set up a new topic (or modified an existing
one) at 'time' (seconds passed since Jan, 1 1970) on channel
'channel'. The topic is given in the 'text'. If 'text' is empty,
the topic for 'channel' is removed. If your host holds a newer
topic, it should not be changed and this command should not be
forwarded.
o /++UMSG host user touser <text>
!! added host field
The 'user'@'host' sends a private message to 'touser'. The
contents of 'text' should not be formatted, if 'user' is
"conversd". Otherwise, the local server can render it in any manner
that is wishes.
o /++USER host user time fromchan tochan ['@'|text]
!! reversed order of host and user
!! removed the UDAT command
This indicated that 'user'@'host' has left 'fromchannel' and has
joined 'tochannel' at 'time'. The 'text' is his personal name or
description. A '@' in the text field indicates an empty personal
note. If the 'tochannel' == -1 (the user is leaving the channel),
the additional 'text' indicates the reason for the signoff.
The following HOST Mode commands are REQUIRED and MUST be implemented
in a server for it to consider itself as 'TACS-compatible':
o ACTV
o CMSG
o DEST
o ECMD
o HELP
o IDLE
o INVI
o LINK
o MODE
o OBSV
o PING
o PONG
o RERF
o SYSI
o UDAT
o UMSG
o USER
All TACS-mode HOST state commands that are NOT supported or recognized
must be passed on unmodified to all TACS connected hosts.
4.3. Commands valid in 'USER' State
The commands recognized in the USER state do not (by themselves) get
sent to other Hosts via the TACS Protocol, hence they are not covered
in this Specification. Any server can make any commands available to
its users that makes sense to the author of the server software.
Note, though, that many commands implemented by Converse servers are
translated into HOST Commands, and are sent via the TACS Protocol.
4.4. Commands valid in 'OBSERVER' State
The OBSERVER state is a subset of the USER state, and only allows
commands that produce NO output to others.
Converse server authors should take extreme care to ensure that NO
commands which can produce output to other processes can be executed
by those in OBSERVER state. This includes changing topic names, etc.
Observer mode is meant as a way to allow read-only access to the
Converse network, and to shield against possible illegal transmissions
by non-Amateurs.
5. Concluding Thoughts
The whole intent of the author (both with TPP and now TACS) is to
extend the Converse Software, making is usable in the large scale
global network that has developed.
I hope that this level of information will help others who wish to
experiment and implement their own playgrounds to easily do so.
