TS6 Proposal

Revision as of 17:31, 7 August 2007

$Id: ts6.txt (v7) 33 2005-10-02 20:50:00Z knight $
Written by Lee H <lee@leeh.co.uk>

Introduction

This document aims to fix some of the flaws that are still present in the current TS system.

Whilst only one person may use a nickname at any one time, they are not a reliable method of directing commands between servers. Clients can change their nicknames, which can create desyncs. A reliable method of directing messages between servers is required so that a message will always reach the intended destination, even if the client changes nicks in between.

UID solves this problem by ensuring that a client has a unique ID for the duration of his connection.

This document also aims to solve the lack of TS rules to channel 'bans' on a netburst. Bans from both sides of a TS war (losing/winning) are kept. Bursting the bans with a TS solves this problem.

There is also a race condition in the current TS system, where a user can issue a mode during a netburst and the mode will be set on the server we are bursting to.

Definitions

Throughout this document, the following terms are used:

• SID - A servers unique ID. This is three characters long and must be in the form [0-9][A-Z0-9][A-Z0-9]
• ID - A clients unique ID. This is six characters long and must be in the form [A-Z][A-Z0-9][A-Z0-9][A-Z0-9][A-Z0-9][A-Z0-9]. The numbers [0-9] at the beginning of an ID are legal characters, but reserved for future use.
• UID - An ID concateneted to a SID. This forms the clients UID.
• TS6 - The TS version 6.

Support

Support for this document is given by the TS version 6.

Wherever a destination parameter or source parameter is used, it must use the SID or UID if the server/client has one. A TS6 capable server must translate any SIDs/UIDs back into the server/clients name when communicating with a server that does not support TS6.

A TS6 server must also support the QS (quitstorm) system, and the encap specification found here: [1]

The TS6 protocol does not supports masked entities.

Nick TS rules

A server receiving a command that requires nick TS rules must check for a collision between an existing user, and the nick in the received message. (the "new user"). The collisions must obey the rules specified in Nick TS collisions.

If the TS received is lower than the TS of the existing user the server will collide the existing user if the clients user@host are different, if the clients user@hosts are identical it will collide the new user.

If the TS received is equal to the TS of the existing user both clients are collided.

If the TS received is higher than the TS of the existing user, the server will collide the existing user if the user@hosts are identical, if the clients user@host are different it will collide the new user and drop the message.

Nick TS collisions

If both users are to be collided, we must issue a KILL for the existing user to all servers. If the new user has a UID then we must also issue a KILL for that UID back to the server sending us data causing the collision.

If only the existing user is being collided, we must issue a KILL for the existing user to all servers except the server sending us data. If the existing user has a UID and the server sending us data supports TS6 then we must also issue a KILL for the existing users UID to the server sending us data.

If only the new user is being collided, we must issue a KILL for the new user back to the server sending us data if the new user has a UID.

Channel TS rules

A server receiving a command that requires normal channel TS rules must apply the following rules to the command.

If the TS received is lower than our TS of the channel a TS6 server must remove status modes (+ov etc) and channel modes (+nt etc). If the originating server is TS6 capable (ie, it has a SID), the server must also remove any ban modes (+b etc). The new modes and statuses are then accepted.

If any bans are removed, the server must send to non-TS6, directly connected servers mode changes removing the bans after the command is propagated. This prevents desync with banlists, and has to be sent after as clients are still able to send mode changes before the triggering command arrives.

If the TS received is equal to our TS of the channel the server should keep its current modes and accept the received modes and statuses.

If the TS received is higher than our TS of the channel the server should keep its current modes and ignore the received modes and statuses. Any statuses given in the received message will be removed. A server must mark clients losing their op (+o) status who do not have a UID as 'deopped'. A server must ignore any "MODE" commands from a user marked as 'deopped'.

Simple channel TS rules

A server receiving a command that requires simple channel TS rules must apply the following rules to the command.

If the TS received is lower, or equal to our TS of the channel the modes are accepted. If the TS received is higher than our TS of the channel the modes are ignored and dropped.

Simple channel TS rules do not affect current modes in the channel except for the modes we are accepting.

The following commands are defined here as the TS6 protocol

PASS:

PASS <PASSWORD> TS <TS_CURRENT> :<SID>

This command is used for password verification with the server we are connecting to.

Due to the burst being sent on verification of the "SERVER" command, and "SVINFO" being sent after "SERVER", we need to be aware of the TS version earlier to decide whether to send a TS6 burst or not.

The <PASSWORD> field is the password we have stored for this server, <TS_CURRENT> is our current TS version. If this field is not present then the server does not support TS6. <SID> is the SID of the server.

UID:

:<SID> UID <NICK> <HOPS> <TS> +<UMODE> <USERNAME> <HOSTNAME> <IP> <UID> :<GECOS>

This command is used for introducing clients to the network.

The <SID> field is the SID of the server the client is connected to. The <NICK> field is the nick of the client being introduced. The <HOPS> field is the amount of server hops between the server being burst to and the server the client is on. The <TS> field is the TS of the client, either the time they connected or the time they last changed nick. The <UMODE> field contains the clients usermodes that need to be transmitted between servers. The <USERNAME> field contains the clients username/ident. The<HOSTNAME> field contains the clients host.

The <IP> field contains the clients IP. If the IP is not to be sent (due to a spoof etc), the field must be sent as "0". The <UID> field is the clients UID. The <GECOS> field is the clients gecos.

A server receiving a UID command must apply nick TS rules to the nick.

SID:

:<SID> SID <SERVERNAME> <HOPS> <SID> :<GECOS>

This command is used for introducing servers to the network.

The first <SID> field is the SID of the new servers uplink. The <SERVERNAME> field is the new servers name. The <HOPS> field is the hops between the server being introduced nd the server being burst to.

The second <SID> field is the SID of the new server. The <GECOS> field i is the new servers gecos.

Upon receiving the SID command servers must check for a SID collision. Two servers must not be allowed to link to the network with the same SID. If a server detects a SID collision it must drop the link to the directly connected server through which the command was received.

Client and servers which do not have a UID/SID must be introduced by old methods.

SJOIN:

:<SID> SJOIN <TS> <CHANNAME> +<CHANMODES> :<UIDS>

This command is used for introducing users to channels.

The <SID> field is the SID of the server introducing users to the channel. The <TS> field is the channels current TS, <CHANNAME> is the channels current name, <CHANMODES> are the channels current modes. <UIDS> is a space delimited list of clients UIDs to join to the channel. Each clients UID is prefixed with their status on the channel, ie "@UID" for an opped user. Multiple prefixes are allowed, "peons" (clients without a status) are not prefixed.

A server receiving an SJOIN must apply normal channel TS rules to the SJOIN.

A TS6 server must not use the SJOIN command outside of a netburst to introduce a single user to an existing channel. It must instead use the "JOIN" command defined in this specification. A TS6 server must still use SJOIN for creating channels.

JOIN:

:<UID> JOIN <TS> <CHANNAME> +<CHANMODES>

This command is used for introducing one user unopped to an existing channel.

The <UID> field is the UID of the client joining the channel. The <TS> field is the channels current TS, <CHANNAME> is the channels current name, <CHANMODES> are the channels current modes.

A server receiving a JOIN must apply normal channel TS rules to the JOIN.

It should be noted that whilst JOIN would not normally create a channel, during specific race conditions it can. This can create a ban desync that this specification does not rectify.

BMASK:

:<SID> BMASK <TS> <CHANNAME> <TYPE> :<MASKS>

This command is used for bursting channel bans to a network.

The <SID> field is the SID of the server bursting the bans. The <TS> field is the channels current TS, <CHANNAME> is the channels name. <TYPE> is a single character identifying the mode type (ie, for a ban 'b'). <MASKS> is a space delimited list of masks of the given mode,limited only in length to the size of the buffer as defined by RFC1459.

A server receiving a BMASK must apply simple channel TS rules to the BMASK.

A TS6 server must translate BMASKs into raw modes for non-TS6 capable servers. This command must be used only after SJOIN has been sent for the given channel.

It should be noted however, that a BMASK with a lower TS should not be possible without a desync, due to it being sent after SJOIN.

TMODE:

:<UID> TMODE <TS> <CHANNAME> <MODESTRING>

This command is used for clients issuing modes on a channel.

<UID> is the UID of the client setting the mode. <TS> is the current TS of the channel, <CHANNAME> is the channels name. <MODESTRING> is the raw mode the client is setting.

A server receiving a TMODE must apply simple channel TS rules to the TMODE.

A TS6 server must translate MODEs issued by a local client into TMODE to send to other TS6 capable servers.