doc/technical/ts6.txt

$Id$

TS6 Proposal (v7)
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:
http://www.leeh.co.uk/ircd/encap.txt

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.
Revision:	31
Committed:	Sun Oct 2 20:34:05 2005 UTC (20 years, 9 months ago) by knight
Content type:	text/plain
Original Path:	*ircd-hybrid/doc/technical/ts6.txt*
File size:	10537 byte(s)
Log Message:	- Fix svn:keywords
#	User	Rev	Content
1	knight	31	$Id$
2	adx	30
3			TS6 Proposal (v7)
4			Written by Lee H <lee@leeh.co.uk>
5
6			Introduction
7			------------
8
9			This document aims to fix some of the flaws that are still present in the
10			current TS system.
11
12			Whilst only one person may use a nickname at any one time, they are not
13			a reliable method of directing commands between servers. Clients can change
14			their nicknames, which can create desyncs. A reliable method of directing
15			messages between servers is required so that a message will always reach the
16			intended destination, even if the client changes nicks in between.
17
18			UID solves this problem by ensuring that a client has a unique ID for the
19			duration of his connection.
20
21			This document also aims to solve the lack of TS rules to channel 'bans' on
22			a netburst. Bans from both sides of a TS war (losing/winning) are kept.
23			Bursting the bans with a TS solves this problem.
24
25			There is also a race condition in the current TS system, where a user can
26			issue a mode during a netburst and the mode will be set on the server
27			we are bursting to.
28
29
30			Definitions
31			-----------
32
33			Throughout this document, the following terms are used:
34
35			SID - A servers unique ID. This is three characters long and must be in
36			the form [0-9][A-Z0-9][A-Z0-9]
37			ID - A clients unique ID. This is six characters long and must be in
38			the form [A-Z][A-Z0-9][A-Z0-9][A-Z0-9][A-Z0-9][A-Z0-9]. The
39			numbers [0-9] at the beginning of an ID are legal characters, but
40			reserved for future use.
41			UID - An ID concateneted to a SID. This forms the clients UID.
42			TS6 - The TS version 6.
43
44
45			Support
46			-------
47
48			Support for this document is given by the TS version 6.
49
50			Wherever a destination parameter or source parameter is used, it must use
51			the SID or UID if the server/client has one. A TS6 capable server must
52			translate any SIDs/UIDs back into the server/clients name when communicating
53			with a server that does not support TS6.
54
55			A TS6 server must also support the QS (quitstorm) system, and the encap
56			specification found here:
57			http://www.leeh.co.uk/ircd/encap.txt
58
59			The TS6 protocol does not supports masked entities.
60
61
62			Nick TS rules
63			-------------
64
65			A server receiving a command that requires nick TS rules must check for a
66			collision between an existing user, and the nick in the received message.
67			(the "new user"). The collisions must obey the rules specified in Nick TS
68			collisions.
69
70			If the TS received is lower than the TS of the existing user the server will
71			collide the existing user if the clients user@host are different, if the
72			clients user@hosts are identical it will collide the new user.
73
74			If the TS received is equal to the TS of the existing user both clients are
75			collided.
76
77			If the TS received is higher than the TS of the existing user, the server
78			will collide the existing user if the user@hosts are identical, if the
79			clients user@host are different it will collide the new user and drop the
80			message.
81
82
83			Nick TS collisions
84			------------------
85
86			If both users are to be collided, we must issue a KILL for the existing
87			user to all servers. If the new user has a UID then we must also issue a
88			KILL for that UID back to the server sending us data causing the collision.
89
90			If only the existing user is being collided, we must issue a KILL for the
91			existing user to all servers except the server sending us data. If the
92			existing user has a UID and the server sending us data supports TS6 then
93			we must also issue a KILL for the existing users UID to the server sending
94			us data.
95
96			If only the new user is being collided, we must issue a KILL for the new user
97			back to the server sending us data if the new user has a UID.
98
99
100			Channel TS rules
101			----------------
102
103			A server receiving a command that requires normal channel TS rules must
104			apply the following rules to the command.
105
106			If the TS received is lower than our TS of the channel a TS6 server must
107			remove status modes (+ov etc) and channel modes (+nt etc). If the
108			originating server is TS6 capable (ie, it has a SID), the server must
109			also remove any ban modes (+b etc). The new modes and statuses are then
110			accepted.
111
112			If any bans are removed, the server must send to non-TS6, directly connected
113			servers mode changes removing the bans after the command is propagated.
114			This prevents desync with banlists, and has to be sent after as clients are
115			still able to send mode changes before the triggering command arrives.
116
117			If the TS received is equal to our TS of the channel the server should keep
118			its current modes and accept the received modes and statuses.
119
120			If the TS received is higher than our TS of the channel the server should keep
121			its current modes and ignore the received modes and statuses. Any statuses
122			given in the received message will be removed. A server must mark clients
123			losing their op (+o) status who do not have a UID as 'deopped'. A server must
124			ignore any "MODE" commands from a user marked as 'deopped'.
125
126
127			Simple channel TS rules
128			-----------------------
129
130			A server receiving a command that requires simple channel TS rules must
131			apply the following rules to the command.
132
133			If the TS received is lower, or equal to our TS of the channel the modes are
134			accepted. If the TS received is higher than our TS of the channel the modes
135			are ignored and dropped.
136
137			Simple channel TS rules do not affect current modes in the channel except
138			for the modes we are accepting.
139
140
141			The following commands are defined here as the TS6 protocol
142			-----------------------------------------------------------
143
144			PASS:
145			PASS <PASSWORD> TS <TS_CURRENT> :<SID>
146
147			This command is used for password verification with the server we are
148			connecting to.
149
150			Due to the burst being sent on verification of the "SERVER" command, and
151			"SVINFO" being sent after "SERVER", we need to be aware of the TS version
152			earlier to decide whether to send a TS6 burst or not.
153
154			The <PASSWORD> field is the password we have stored for this server,
155			<TS_CURRENT> is our current TS version. If this field is not present then
156			the server does not support TS6. <SID> is the SID of the server.
157
158			UID:
159			:<SID> UID <NICK> <HOPS> <TS> +<UMODE> <USERNAME> <HOSTNAME> <IP> <UID> :<GECOS>
160
161			This command is used for introducing clients to the network.
162
163			The <SID> field is the SID of the server the client is connected to.
164			The <NICK> field is the nick of the client being introduced. The <HOPS>
165			field is the amount of server hops between the server being burst to and
166			the server the client is on. The <TS> field is the TS of the client, either
167			the time they connected or the time they last changed nick. The <UMODE>
168			field contains the clients usermodes that need to be transmitted between
169			servers. The <USERNAME> field contains the clients username/ident. The
170			<HOSTNAME> field contains the clients host.
171
172			The <IP> field contains the clients IP. If the IP is not to be sent
173			(due to a spoof etc), the field must be sent as "0". The <UID> field is the
174			clients UID. The <GECOS> field is the clients gecos.
175
176			A server receiving a UID command must apply nick TS rules to the nick.
177
178			SID:
179			:<SID> SID <SERVERNAME> <HOPS> <SID> :<GECOS>
180
181			This command is used for introducing servers to the network.
182
183			The first <SID> field is the SID of the new servers uplink. The
184			<SERVERNAME> field is the new servers name. The <HOPS> field is the hops
185			between the server being introduced nd the server being burst to.
186
187			The second <SID> field is the SID of the new server. The <GECOS> field i
188			is the new servers gecos.
189
190			Upon receiving the SID command servers must check for a SID collision.
191			Two servers must not be allowed to link to the network with the same SID.
192			If a server detects a SID collision it must drop the link to the directly
193			connected server through which the command was received.
194
195			Client and servers which do not have a UID/SID must be introduced by old
196			methods.
197
198			SJOIN:
199			:<SID> SJOIN <TS> <CHANNAME> +<CHANMODES> :<UIDS>
200
201			This command is used for introducing users to channels.
202
203			The <SID> field is the SID of the server introducing users to the channel.
204			The <TS> field is the channels current TS, <CHANNAME> is the channels
205			current name, <CHANMODES> are the channels current modes. <UIDS> is a
206			space delimited list of clients UIDs to join to the channel. Each clients
207			UID is prefixed with their status on the channel, ie "@UID" for an opped
208			user. Multiple prefixes are allowed, "peons" (clients without a status) are
209			not prefixed.
210
211			A server receiving an SJOIN must apply normal channel TS rules to the SJOIN.
212
213			A TS6 server must not use the SJOIN command outside of a netburst
214			to introduce a single user to an existing channel. It must instead
215			use the "JOIN" command defined in this specification. A TS6 server must
216			still use SJOIN for creating channels.
217
218			JOIN:
219			:<UID> JOIN <TS> <CHANNAME> +<CHANMODES>
220
221			This command is used for introducing one user unopped to an existing channel.
222
223			The <UID> field is the UID of the client joining the channel. The
224			<TS> field is the channels current TS, <CHANNAME> is the channels
225			current name, <CHANMODES> are the channels current modes.
226
227			A server receiving a JOIN must apply normal channel TS rules to the JOIN.
228
229			It should be noted that whilst JOIN would not normally create a
230			channel, during specific race conditions it can. This can create
231			a ban desync that this specification does not rectify.
232
233			BMASK:
234			:<SID> BMASK <TS> <CHANNAME> <TYPE> :<MASKS>
235
236			This command is used for bursting channel bans to a network.
237
238			The <SID> field is the SID of the server bursting the bans. The
239			<TS> field is the channels current TS, <CHANNAME> is the channels
240			name. <TYPE> is a single character identifying the mode type (ie,
241			for a ban 'b'). <MASKS> is a space delimited list of masks of the
242			given mode,limited only in length to the size of the buffer as defined
243			by RFC1459.
244
245			A server receiving a BMASK must apply simple channel TS rules to the BMASK.
246
247			A TS6 server must translate BMASKs into raw modes for non-TS6
248			capable servers. This command must be used only after SJOIN has
249			been sent for the given channel.
250
251			It should be noted however, that a BMASK with a lower TS should
252			not be possible without a desync, due to it being sent after
253			SJOIN.
254
255			TMODE:
256			:<UID> TMODE <TS> <CHANNAME> <MODESTRING>
257
258			This command is used for clients issuing modes on a channel.
259
260			<UID> is the UID of the client setting the mode. <TS> is the
261			current TS of the channel, <CHANNAME> is the channels name.
262			<MODESTRING> is the raw mode the client is setting.
263
264			A server receiving a TMODE must apply simple channel TS rules to the TMODE.
265
266			A TS6 server must translate MODEs issued by a local client into TMODE
267			to send to other TS6 capable servers.