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