idnits 2.17.1 draft-kalt-irc-chan-00.txt: -(781): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Experimental RFC: RFC 1459 (ref. 'IRC') -- No information found for draft-kalt-irc-arch-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IRC-ARCH' -- No information found for draft-kalt-irc-client-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IRC-CLIENT' -- No information found for draft-kalt-irc-server-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IRC-SERVER' Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft C. Kalt 2 Internet Relay Chat: Channel Management 3 draft-kalt-irc-chan-00.txt 5 Status of this Memo 7 This document is an Internet-Draft and is in full conformance with 8 all provisions of Section 10 of RFC2026. Internet-Drafts are working 9 documents of the Internet Engineering Task Force (IETF), its areas, 10 and its working groups. Note that other groups may also distribute 11 working documents as Internet Drafts. 13 Internet-Drafts are draft documents valid for a maximum of six 14 months and may be updated, replaced, or obsoleted by other documents 15 at any time. It is inappropriate to use Internet-Drafts as reference 16 material or to cite them other than as "work in progress." 18 The list of current Internet-Drafts can be accessed at 19 http://www.ietf.org/ietf/1id-abstracts.txt 21 The list of Internet-Draft Shadow Directories can be accessed at 22 http://www.ietf.org/shadow.html. 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 25 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 26 this document are to be interpreted as described in RFC 2119 27 [KEYWORDS]. 29 Abstract 31 One of the most notable characteristics of the IRC (Internet Relay 32 Chat) protocol is to allow for users to be grouped in forums, called 33 channels, providing a mean for multiple users to communicate 34 together. 36 There was originally a unique type of channels, but with the 37 years, new types appeared either as a response to a need, or for 38 experimental purposes. 40 This document specifies how channels, their characteristics and 41 properties are managed by IRC servers. 43 Table of Contents 45 1. Introduction ............................................... 3 47 2. Channel Characteristics .................................... 3 48 2.1 Namespace .............................................. 3 49 2.2 Channel Scope .......................................... 3 50 2.3 Channel Properties ..................................... 4 51 2.4 Privileged Channel Members ............................. 4 52 2.4.1 Channel Operators ................................. 5 53 2.4.2 Channel Creator ................................... 5 55 3. Channel lifetime ........................................... 5 56 3.1 Standard channels ...................................... 5 57 3.2 Safe Channels .......................................... 6 59 4. Channel Modes .............................................. 8 60 4.1 Member Status .......................................... 8 61 4.1.1 "Channel Creator" Status .......................... 8 62 4.1.2 Channel Operator Status ........................... 8 63 4.1.3 Voice Privilege ................................... 8 64 4.2 Channel Flags .......................................... 9 65 4.2.1 Anonymous Flag .................................... 9 66 4.2.2 Invite Only Flag .................................. 9 67 4.2.3 Moderated Channel Flag ............................ 9 68 4.2.4 No Messages To Channel From Clients On The Outside 9 69 4.2.5 Quiet Channel ..................................... 10 70 4.2.6 Private and Secret Channels ....................... 10 71 4.2.7 Server Reop Flag .................................. 10 72 4.2.8 Topic ............................................. 11 73 4.2.9 User Limit ........................................ 11 74 4.2.10 Channel Key ...................................... 11 75 4.3 Channel Access Control ................................. 11 76 4.3.1 Channel Ban and Exception ......................... 11 77 4.3.2 Channel Invitation ................................ 12 79 5. Current Implementations .................................... 13 80 5.1 Tracking Recently Used Channels ........................ 13 81 5.2 Safe Channels .......................................... 13 82 5.2.1 Channel Identifier ................................ 13 83 5.2.2 Channel Delay ..................................... 14 84 5.2.3 Abuse Window ...................................... 14 85 5.2.4 Preserving Sanity In The Name Space ............... 14 86 5.2.5 Server Reop Mechanism ............................. 14 88 6. Current problems ........................................... 15 89 6.1 Labels ................................................. 16 90 6.1.1 Channel Delay ..................................... 16 91 6.1.2 Safe Channels ..................................... 16 92 6.2 Mode Propagation Delays ................................ 16 93 6.3 Collisions And Channel Modes ........................... 16 94 6.4 Resource Exhaustion .................................... 17 96 7. Security Considerations .................................... 17 97 7.1 Access Control ......................................... 17 98 7.2 Channel Privacy ........................................ 18 100 8. Current support and availability ........................... 18 102 9. Acknowledgements ........................................... 18 104 10. References ................................................ 18 106 11. Author's Address .......................................... 19 108 1. Introduction 110 This document defines in detail on how channels are managed by the 111 IRC servers and will be mostly useful to people working on 112 implementing an IRC server. 114 While the concepts defined here are an important part of IRC, they 115 remain non essential for implementing clients. While the trend seems 116 to be towards more and more complex and "intelligent" clients which 117 are able to take advantage of knowing the internal workings of 118 channels to provide the users with a more friendly interface, simple 119 clients can be implemented without reading this document. 121 Many of the concepts defined here were designed with the IRC 122 architecture [IRC-ARCH] in mind and mostly make sense in this 123 context. However, many others could be applied to other 124 architectures in order to provide forums for a conferencing system. 126 Finally, it is to be noted that IRC users may find some of the 127 following sections of interest, in particular sections 2 (Channel 128 Characteristics) and 4 (Channel Modes). 130 2. Channel Characteristics 132 A channel is a named group of one or more users which will all 133 receive messages addressed to that channel. A channel is 134 characterized by its name, properties and current members. 136 2.1 Namespace 138 Channels names are strings (beginning with a '&', '#', '+' or '!' 139 character) of length up to fifty (50) characters. Channel names are 140 case insensitive. 142 Apart from the the requirement that the first character being 143 either '&', '#', '+' or '!' (hereafter called "channel prefix"). The 144 only restriction on a channel name is that it SHALL NOT contain any 145 spaces (' '), a control G (^G or ASCII 7), a comma (',' which is used 146 as a list item separator by the protocol). Also, a column (':') is 147 used as a delimiter for the channel mask. The exact syntax of a 148 channel name is defined in "IRC Server Protocol" [IRC-SERVER]. 150 The use of different prefixes effectively creates four (4) 151 distinct namespaces for channel names. This is important because of 152 the protocol limitations regarding namespaces (in general). See 153 section 6.1 (Labels) for more details on these limitations. 155 2.2 Channel Scope 156 A channel entity is known by one or more servers on the IRC 157 network. A user can only become member of a channel known by the 158 server to which the user is directly connected. The list of servers 159 which know of the existence of a particular channel MUST be a 160 contiguous part of the IRC network, in order for the messages 161 addressed to the channel to be sent to all the channel members. 163 Channels with '&' as prefix are local to the server where they are 164 created. 166 Other channels are known to one (1) or more servers that are 167 connected to the network, depending on the channel mask: 169 If there is no channel mask, then the channel is known to all 170 the servers. 172 If there is a channel mask, then the channel MUST only be known 173 to servers which has a local user on the channel, and to its 174 neighbours if the mask matches both the local and neighbouring 175 server names. Since other servers have absolutely no knowledge of 176 the existence of such a channel, the area formed by the servers 177 having a name matching the mask has to be contiguous for the 178 channel to be known by all these servers. Channel masks are best 179 used in conjunction with server hostmasking [IRC-SERVER]. 181 2.3 Channel Properties 183 Each channel has its own properties, which are defined by channel 184 modes. Channel modes can be manipulated by the channel members. The 185 modes affect the way servers manage the channels. 187 Channels with '+' as prefix do not support channel modes. This 188 means that all the modes are unset, with the exception of the 't' 189 channel flag which is set. 191 2.4 Privileged Channel Members 193 In order for the channel members to keep some control over a 194 channel, and some kind of sanity, some channel members are 195 privileged. Only these members are allowed to perform the following 196 actions on the channel: 198 INVITE - Invite a client to an invite-only channel (mode +i) 199 KICK - Eject a client from the channel 200 MODE - Change the channel's mode, as well as 201 members' privileges 202 PRIVMSG - Sending messages to the channel (mode +n, +m, +v) 203 TOPIC - Change the channel topic in a mode +t channel 205 2.4.1 Channel Operators 207 The channel operators (also referred to as a "chop" or "chanop") 208 on a given channel are considered to 'own' that channel. Ownership 209 of a channel is shared among channel operators. 211 Channel operators are identified by the '@' symbol next to their 212 nickname whenever it is associated with a channel (i.e. replies to 213 the NAMES, WHO and WHOIS commands). 215 Since channels starting with the character '+' as prefix do not 216 support channel modes, no member can therefore have the status of 217 channel operator. 219 2.4.2 Channel Creator 221 A user who creates a channel with the character '!' as prefix is 222 identified as the "channel creator". Upon creation of the channel, 223 this user is also given channel operator status. 225 In recognition of this status, the channel creators are endowed 226 with the ability to toggle certain modes of the channel which channel 227 operators may not manipulate. 229 A "channel creator" can be distinguished from a channel operator 230 by issuing the proper MODE command. See the "IRC Client Protocol" 231 [IRC-CLIENT] for more information on this topic. 233 3. Channel lifetime 235 In regard to the lifetime of a channel, there are typically two 236 groups of channels: standard channels which prefix is either '&', '#' 237 or '+', and "safe channels" which prefix is '!'. 239 3.1 Standard channels 241 These channels are created implicitly when the first user joins 242 it, and cease to exist when the last user leaves it. While the 243 channel exists, any client can reference the channel using the name 244 of the channel. 246 The user creating a channel automatically becomes channel operator 247 with the notable exception of channels which name is prefixed by the 248 character '+', see section 4 (Channel modes). See section 2.4.1 249 (Channel Operators) for more details on this title. 251 In order to avoid the creation of duplicate channels (typically 252 when the IRC network becomes disjoint because of a split between two 253 servers), channel names SHOULD NOT be allowed to be reused by a user 254 if a channel operator (See Section 2.4.1 (Channel Operators)) has 255 recently left the channel because of a network split. If this 256 happens, the channel name is temporarely unavailable. The duration 257 while a channel remains unavailable should be tuned on a per IRC 258 network basis. It is important to note that this prevents local 259 users from creating a channel using the same name, but does not 260 prevent the channel to be recreated by a remote user. The latter 261 typically happens when the IRC network rejoins. Obviously, this 262 mechanism only makes sense for channels which name begins with the 263 character '#', but MAY be used for channels which name begins with 264 the character '+'. This mechanism is commonly known as "Channel 265 Delay". 267 3.2 Safe Channels 269 Unlike other channels, "safe channels" are not implicitly created. 270 A user wishing to create such a channel MUST request the creation by 271 sending a special JOIN command to the server in which the channel 272 identifier (then unknown) is replaced by the character '!'. The 273 creation process for this type of channel is strictly controlled. 274 The user only chooses part of the channel name (known as the channel 275 "short name"), the server automatically prepends the user provided 276 name with a channel identifier consisting of five (5) characters. 277 The channel name resulting from the combination of these two elements 278 is unique, making the channel safe from abuses based on network 279 splits. 281 The user who creates such a channel automatically becomes "channel 282 creator". See section 2.4.2 (Channel Creator) for more details on 283 this title. 285 A server MUST NOT allow the creation of a new channel if another 286 channel with the same short name exists; or if another channel with 287 the same short name existed recently AND any of its member(s) left 288 because of a network split. Such channel ceases to exits after last 289 user leaves AND no other member recently left the channel because of 290 a network split. 292 Unlike the mechanism described in section 5.2.2 (Channel Delay), 293 in this case, channel names do not become unavailable: these channels 294 may continue to exist after the last user left. Only the user 295 creating the channel becomes "channel creator", users joining an 296 existing empty channel do not automatically become "channel creator" 297 nor "channel operator". 299 To ensure the uniqueness of the channel names, the channel 300 identifier created by the server MUST follow specific rules. For 301 more details on this, see section 5.2.1 (Channel Identifier). 303 4. Channel Modes 305 The various modes available for channels are as follows: 307 O - give "channel creator" status; 308 o - give/take channel operator privilege; 309 v - give/take the voice privilege; 311 a - toggle the anonymous channel flag; 312 i - toggle the invite-only channel flag; 313 m - toggle the moderated channel; 314 n - toggle the no messages to channel from clients on the 315 outside; 316 q - toggle the quiet channel flag; 317 p - toggle the private channel flag; 318 s - toggle the secret channel flag; 319 r - toggle the server reop channel flag; 320 t - toggle the topic settable by channel operator only flag; 322 k - set/remove the channel key (password); 323 l - set/remove the user limit to channel; 325 b - set/remove ban mask to keep users out; 326 e - set/remove an exception mask to override a ban mask; 327 I - set/remove an invitation mask to automatically override 328 the invite-only flag; 330 Unless mentionned otherwise below, all these modes can be 331 manipulated by "channel operators" by using the MODE command defined 332 in "IRC Client Protocol" [IRC-CLIENT]. 334 4.1 Member Status 336 The modes in this category take a channel member nickname as 337 argument and affect the privileges given to this user. 339 4.1.1 "Channel Creator" Status 341 The mode 'O' is only used in conjunction with "safe channels" and 342 SHALL NOT be manipulated by users. Servers use it to give the user 343 creating the channel the status of "channel creator". 345 4.1.2 Channel Operator Status 347 The mode 'o' is used to toggle the operator status of a channel 348 member. 350 4.1.3 Voice Privilege 351 The mode 'v' is used to give and take voice privilege to/from a 352 channel member. Users with this privilege can talk on moderated 353 channels. (See section 4.2.3 (Moderated Channel Flag)). 355 4.2 Channel Flags 357 The modes in this category are used to define properties which 358 affects how channels operate. 360 4.2.1 Anonymous Flag 362 The channel flag 'a' defines an anonymous channel. This means 363 that when a message sent to the channel is sent by the server to 364 users, and the origin is a user, then it MUST be masked. To mask the 365 message, the origin is changed to "anonymous!anonymous@anonymous." 366 (e.g. a user with the nickname "anonymous", the username "anonymous" 367 and from a host called "anonymous."). Because of this, servers MUST 368 forbid users from using the nickname "anonymous". 370 On channels with the character '&' as prefix, this flag MAY be 371 toggled by channel operators, but on channels with the character '!' 372 as prefix, this flag can be set (but SHALL NOT be unset) by the 373 "channel creator" only. This flag is MUST NOT be made available on 374 other types of channels. 376 Replies to the WHOIS, WHO and NAMES commands MUST NOT reveal the 377 presence of other users on channels for which the anonymous flag is 378 set. 380 4.2.2 Invite Only Flag 382 When the channel flag 'i' is set, new members are only accepted if 383 they have been invited by a channel operator. This flags also 384 restricts the usage of the INVITE command (See "IRC Client Protocol" 385 [IRC-CLIENT]) to channel operators. 387 4.2.3 Moderated Channel Flag 389 The channel flag 'm' is used to control who may speak on a 390 channel. When it is set, only channel operators, and members who 391 have been given the voice privilege may send messages to the channel. 393 This flag only affects users. 395 4.2.4 No Messages To Channel From Clients On The Outside 397 When the channel flag 'n' is set, only channel members MAY send 398 messages to the channel. 400 This flag only affects users. 402 4.2.5 Quiet Channel 404 The channel flag 'q' is for use by servers only. When set, it 405 restricts the type of data sent to users about the channel 406 operations: other user joins, parts and nick changes are not sent. 407 From a user's point of view, the channel only contain one user. 409 This is typically used to create special local channels on which 410 the server sends notices related to its operations. This was used as 411 a more efficient and flexible way to replace the user mode 's' 412 defined in RFC 1459 [IRC]. 414 4.2.6 Private and Secret Channels 416 The channel flag 'p' is used to mark a channel "private" and the 417 channel flag 's' to mark a channel "secret". Both properties are 418 similar and conceal the existance of the channel from other users. 420 This means that there is no way of getting this channel's name 421 from the server without being a member. In other words, these 422 channels MUST be omitted from replies to queries like the WHOIS 423 command. 425 When a channel is "secret", in addition to the restriction above, 426 the server will act as if the channel does not exist for queries like 427 the TOPIC, LIST, NAMES commands. Note that there is one exception to 428 this rule: servers will correctly reply to the MODE command. 429 Finally, secret channels are not accounted for in the reply to the 430 LUSERS command (See "Internet Relay Chat: Client Protocol" [IRC- 431 CLIENT]) when the parameter is specified. 433 The channel flags 'p' and 's' MUST NOT both be set at the same 434 time. If a MODE message originating from a server sets the flag 'p' 435 and the flag 's' is already set for the channel, the change is 436 silently ignored. This should only happen during a split healing 437 phase (mentionned in the "IRC Server Protocol" document [IRC- 438 SERVER]). 440 4.2.7 Server Reop Flag 442 The channel flag 'r' is only available on channels which name 443 begins with the character '!' and MAY only be toggled by the "channel 444 creator". 446 This flag is used to prevent a channel from having no channel 447 operator for an extended period of time. When this flag is set, any 448 channel that has lost all its channel operators for longer than the 449 "reop delay" period triggers a mechanism in servers to reop some or 450 all of the channel inhabitants. This mechanism is described more in 451 detail in section 5.2.4 (Channel Reop Mechanism). 453 4.2.8 Topic 455 The channel flag 't' is used to restrict the usage of the TOPIC 456 command to channel operators. 458 4.2.9 User Limit 460 A user limit may be set on channels by using the channel flag 'l'. 461 When the limit is reached, servers MUST forbid their local users to 462 join the channel. 464 It is to be noted that the value of the limit MUST only be made 465 available to the channel members in the reply sent by the server to a 466 MODE query. 468 4.2.10 Channel Key 470 When a channel key is set (by using the mode 'k'), servers MUST 471 reject their local users request to join the channel unless the key 472 is given. 474 It is to be noted that the value of the limit MUST only be made 475 available to the channel members in the reply sent by the server to a 476 MODE query. 478 4.3 Channel Access Control 480 The last category of modes is used to control access to the 481 channel, they take a mask as argument. 483 In order to reduce the size of the global database for control 484 access modes set for channels, servers MAY put a maximum limit on the 485 number of such modes set for a particular channel. If such 486 restriction is imposed, it MUST only affect user requests. The limit 487 SHOULD be homogenous on a per IRC network basis. 489 4.3.1 Channel Ban and Exception 491 When a user requests to join a channel, his local server checks if 492 the user's address matches any of the ban masks set for the channel. 493 If a match is found, the user request is denied unless the address 494 also matches an exception mask set for the channel. 496 Servers MUST NOT allow a channel member who is banned from the 497 channel to speak on the channel, unless this member is a channel 498 operator or has voice privilege. (See Section 4.1.3 (Voice 499 Privilege)). 501 A user who is banned from a channel and who carries an invitation 502 sent by a channel operator is allowed to join the channel. 504 4.3.2 Channel Invitation 506 For channels which have the invite-only flag set (See Section 507 4.2.2 (Invite Only Flag)), users whose address matches an invitation 508 mask set for the channel are allowed to join the channel without any 509 invitation. 511 5. Current Implementations 513 The only current implementation of these rules as part of the IRC 514 protocol is the IRC server, version 2.10. 516 The rest of this section deals with issues that are mostly of 517 importance to those who wish to implement a server but some parts may 518 also be of interest for client writers. 520 5.1 Tracking Recently Used Channels 522 This mechanism is commonly known as "Channel Delay" and generally 523 only applies to channels which names is prefixed with the character 524 '#' (See Section 3.1 "Standard channels"). 526 When a network split occurs, servers SHOULD keep track of which 527 channels lost a "channel operator" as the result of the break. These 528 channels are then in a special state which lasts for a certain period 529 of time. In this particular state, the channels cannot cease to 530 exist. If all the channel members leave the channel, the channel 531 becomes unavailable: the server local clients cannot join the channel 532 as long as it is empty. 534 Once a channel is unavailable, it will become available again 535 either because a remote user has joined the channel (most likely 536 because the network is healing), or because the delay period has 537 expired (in which case the channel ceases to exist and may be re- 538 created). 540 The duration for which a channel death is delayed SHOULD be set 541 considering many factors among which are the size (user wise) of the 542 IRC network, and the usual duration of network splits. It SHOULD be 543 uniform on all servers for a given IRC network. 545 5.2 Safe Channels 547 This document introduces the notion of "safe channels". These 548 channels have a name prefixed with the character '!' and great effort 549 is made to avoid collisions in this name space. Collisions are not 550 impossible, however they are very unlikely. 552 5.2.1 Channel Identifier 554 The channel identifier is a function of the time. The current 555 time (as defined under UNIX by the number of seconds elapsed since 556 00:00:00 GMT, January 1, 1970) is converted in a string of five (5) 557 characters using the following base: 558 ``ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890'' (each character has a 559 decimal value starting from 0 for 'A' to 35 for '0'). 561 The channel identifier therefore has a periodicity of 36^5 seconds 562 (about 700 days). 564 5.2.2 Channel Delay 566 These channels MUST be subject to the "channel delay" mechanism 567 described in section 5.1 (Channel Delay). However, the mechanism is 568 slightly adapted to fit better. 570 Servers MUST keep track of all such channels which lose members as 571 the result of a network split, no matter whether the user is a 572 "channel operator" or not. 574 However, these channels do NOT ever become unavailable, it is 575 always possible to join them even when they are empty. 577 5.2.3 Abuse Window 579 Because the periodicity is so long, attacks on a particular 580 channel (name) may only occur once in a very long while. However, 581 with luck and patience, it is still possible for a user to cause a 582 channel collision. In order to avoid this, servers MUST "look in the 583 future" and keep a list of channel names which identifier is about to 584 be used (in the coming few days for example). Such list should remain 585 small, not be a burden for servers to maintain and be used to avoid 586 channel collisions by preventing the re-creation of such channel for 587 a longer period of time than channel delay does. 589 Eventually a server MAY choose to extend this procedure to forbid 590 creation of channels with the same shortname only (then ignoring the 591 channel identifier). 593 5.2.4 Preserving Sanity In The Name Space 595 The combination of the mechanisms described in sections 5.2.2 and 596 5.2.3 makes it quite difficult for a user to create a channel 597 collision. However, another type of abuse consists of creating many 598 channels having the same shortname, but different identifiers. To 599 prevent this from happenning, servers MUST forbid the creation of a 600 new channel which has the same shortname of a channel currently 601 existing. 603 5.2.5 Server Reop Mechanism 605 When a channel has been opless for longer than the "reop delay" 606 period and has the channel flag 'r' set (See Section 4.2.7 (Server 607 Reop Flag)), IRC servers are responsible for giving the channel 608 operator status randomly to some of the members. 610 The exact logic used for this mechanism by the current 611 implementation is described below. It is to be noted that servers 612 MAY use a different logic, but that it is strongly RECOMMENDED that 613 all servers use the same logic on a particular IRC network to 614 maintain coherence as well as fairness. For the same reason, the 615 "reop delay" SHOULD be uniform on all servers for a given IRC 616 network. As for the "channel delay", the value of the "reop delay" 617 SHOULD be set considering many factors among which are the size (user 618 wise) of the IRC network, and the usual duration of network splits. 620 a) the reop mechanism is triggered after a random time following 621 the expiration of the "reop delay". This should limit the 622 eventuality of the mechanism being triggered at the same time 623 (for the same channel) on two separate servers. 625 b) If the channel is small (five (5) users or less), and the 626 "channel delay" for this channel has expired, 627 Then reop all channel members if at least one member is 628 local to the server. 630 c) If the channel is small (five (5) users or less), and the 631 "channel delay" for this channel has expired, and the "reop 632 delay" has expired for longer than its value, 633 Then reop all channel members. 635 d) For other cases, reop at most one member on the channel, based 636 on some method build into the server. If you don't reop a 637 member, the method should be such that another server will 638 probably op someone. The method SHOULD be the same over the 639 whole network. A good heuristic could be just random reop. 640 (The current implementation actually tries to choose a member 641 local to the server who has not been idle for too long, 642 eventually postponing action, therefore letting other servers 643 have a chance to find a "not too idle" member. This is over 644 complicated due to the fact that servers only know the "idle" 645 time of their local users) 647 6. Current problems 649 There are a number of recognized problems with the way IRC 650 channels are managed. Some of these can be directly attributed to 651 the rules defined in this document, while others are the result of 652 the underlying "IRC Server Protocol" [IRC-SERVER]. Although derived 653 from RFC 1459 [IRC], this document introduces several novelties in an 654 attempt to solve some of the known problems. 656 6.1 Labels 658 This document defines one of the many labels used by the IRC 659 protocol. Although there are several distinct namespaces (based on 660 the channel name prefix), duplicates inside each of these are not 661 allowed. Currently, it is possible for users on different servers to 662 pick the label which may result in collisions (with the exception of 663 channels known to only one server where they can be averted). 665 6.1.1 Channel Delay 667 The channel delay mechanism described in section 5.1 (Tracking 668 Recently Used Channels) and used for channels prefixed with the 669 character '#' is a simple attempt at preventing collisions from 670 happenning. Experience has shown that, under normal circumstances, 671 it is very efficient; however, it obviously has severe limitations 672 keeping it from being an adequate solution to the problem discussed 673 here. 675 6.1.2 Safe Channels 677 "Safe channels" described in section 3.2 (Safe Channels) are a 678 better way to prevent collisions from happenning as it prevents users 679 from having total control over the label they choose. The obvious 680 drawback for such labels is that they are not user friendly. 681 However, it is fairly trivial for a client program to improve on 682 this. 684 6.2 Mode Propagation Delays 686 Because of network delays induced by the network, and because each 687 server on the path is REQUIRED to check the validity of mode changes 688 (e.g. user exists and has the right privileges), it is not unusual 689 for a MODE message to only affect part of the network, often creating 690 a discrepancy between servers on the current state of a channel. 692 While this may seem easy to fix (by having only the original 693 server check the validity of mode changes), it was decided not to do 694 so for various reasons. One concern is that servers cannot trust 695 each other, and that a misbehaving servers can easily be detected. 696 This way of doing so also stops wave effects on channels which are 697 out of synch when mode changes are issued from different directions. 699 6.3 Collisions And Channel Modes 701 The "Internet Relay Chat: Server Protocol" document [IRC-SERVER] 702 describes how channel data is exchanged when two servers connect to 703 each other. Channel collisions (either legitimate or not) are 704 treated as inclusive events, meaning that the resulting channel has 705 for members all the users who are members of the channel on either 706 server prior to the connection. 708 Similarly, each server sends the channel modes to the other one. 709 Therefore, each server also receives these channel modes. There are 710 three types of modes for a given channel: flags, masks, and data. 711 The first two types are easy to deal with as they are either set or 712 unset. If such a mode is set on one server, it MUST be set on the 713 other server as a result of the connection. 715 As topics are not sent as part of this exchange, they are not a 716 problem. However, channel modes 'l' and 'k' are exchanged, and if 717 they are set on both servers prior to the connection, there is no 718 mechanism to decide which of the two values takes precedence. It is 719 left up to the users to fix the resulting discrepancy. 721 6.4 Resource Exhaustion 723 The mode based on masks defined in section 4.3 make the IRC 724 servers (and network) vulnerable to a simple abuse of the system: a 725 single channel operator can set as many different masks as possible 726 on a particular channel. This can easily cause the server to waste 727 memory, as well as network bandwidth (since the info is propagated to 728 other servers). For this reason it is RECOMMENDED that a limit be 729 put on the number of such masks per channels as mentionned in section 730 4.3. 732 Moreover, more complex mechanisms MAY be used to avoid having 733 redundant masks set for the same channel. 735 7. Security Considerations 737 7.1 Access Control 739 One of the main ways to control access to a channel is to use 740 masks which are based on the username and hostname of the user 741 connections. This mechanism can only be efficient and safe if the 742 IRC servers have an accurate way of authenticating user connections, 743 and if users cannot easily get around it. While it is in theory 744 possible to implement such a strict authentication mechanism, most 745 IRC networks (especially public networks) do not have anything like 746 this in place and provide little guaranty about the accuracy of the 747 username and hostname for a particular client connection. 749 Another way to control access is to use a channel key, but since 750 this key is sent in plaintext, it is vulnerable to traditional man in 751 the middle attacks. 753 7.2 Channel Privacy 755 Because channel collisions are treated as inclusive events (See 756 Section 6.3), it is possible for users to join a channel overriding 757 its access control settings. This method has long been used by 758 individuals to "take over" channels by "illegitimately" gaining 759 channel operator status on the channel. It is to be noted that the 760 same method can be used to find out the exact list of members of a 761 channel, as well as to eventually receive some of the messages sent 762 to the channel. 764 8. Current support and availability 766 Mailing lists for IRC related discussion: 767 General discussion: ircd-users@irc.org 768 Protocol development: ircd-dev@irc.org 770 Software implementations: 771 ftp://ftp.irc.org/irc/server 772 ftp://ftp.funet.fi/pub/unix/irc 773 ftp://coombs.anu.edu.au/pub/irc 775 Newsgroup: alt.irc 777 9. Acknowledgements 779 Parts of this document were copied from the RFC 1459 [IRC] which 780 first formally documented the IRC Protocol. It has also benefited 781 from many rounds of review and comments. In particular, the follow� 782 ing people have made significant contributions to this document: 784 Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa 785 Ruokonen, Magnus Tjernstrom, Stefan Zehl. 787 10. References 789 [KEYWORDS] "Key words for use in RFCs to Indicate Requirement Levels", 790 Network Working Group RFC 2119, S. Bradner, March 1997. 792 [IRC] "Internet Relay Chat Protocol", Network Working Group RFC 1459, 793 J. Oikarinen & D. Reed, May 1993 795 [IRC-ARCH] "Internet Relay Chat: Architecture", 796 Work In Progress: draft-kalt-irc-arch-xx.txt 798 [IRC-CLIENT] "Internet Relay Chat: Client Protocol", 799 Work In Progress: draft-kalt-irc-client-xx.txt 801 [IRC-SERVER] "Internet Relay Chat: Server Protocol", 802 Work In Progress: draft-kalt-irc-server-xx.txt 804 11. Author's Address 806 Christophe Kalt 807 99 Teaneck Rd, Apt #117 808 Ridgefield Park, NJ 07660 809 USA 811 Email: kalt@stealth.net