summaryrefslogtreecommitdiff
path: root/vendor/github.com/fluffle/goirc/doc/rfc2811.txt
blob: 7c2c4ea3267c89fa0f4a525dcdaa08c6d4254b97 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067






Network Working Group                                            C. Kalt
Request for Comments: 2811                                    April 2000
Updates: 1459
Category: Informational


                Internet Relay Chat: Channel Management

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   One of the most notable characteristics of the IRC (Internet Relay
   Chat) protocol is to allow for users to be grouped in forums, called
   channels, providing a mean for multiple users to communicate
   together.

   There was originally a unique type of channels, but with the years,
   new types appeared either as a response to a need, or for
   experimental purposes.

   This document specifies how channels, their characteristics and
   properties are managed by IRC servers.

Table of Contents

   1.  Introduction ...............................................   2
   2.  Channel Characteristics ....................................   3
      2.1  Namespace ..............................................   3
      2.2  Channel Scope ..........................................   3
      2.3  Channel Properties .....................................   4
      2.4  Privileged Channel Members .............................   4
         2.4.1  Channel Operators .................................   5
         2.4.2  Channel Creator ...................................   5
   3.  Channel lifetime ...........................................   5
      3.1  Standard channels ......................................   5
      3.2  Safe Channels ..........................................   6
   4.  Channel Modes ..............................................   7
      4.1  Member Status ..........................................   7
         4.1.1  "Channel Creator" Status ..........................   7



Kalt                         Informational                      [Page 1]

RFC 2811        Internet Relay Chat: Channel Management       April 2000


         4.1.2  Channel Operator Status ...........................   8
         4.1.3  Voice Privilege ...................................   8
      4.2  Channel Flags ..........................................   8
         4.2.1  Anonymous Flag ....................................   8
         4.2.2  Invite Only Flag ..................................   8
         4.2.3  Moderated Channel Flag ............................   9
         4.2.4  No Messages To Channel From Clients On The Outside    9
         4.2.5  Quiet Channel .....................................   9
         4.2.6  Private and Secret Channels .......................   9
         4.2.7  Server Reop Flag ..................................  10
         4.2.8  Topic .............................................  10
         4.2.9  User Limit ........................................  10
         4.2.10  Channel Key ......................................  10
      4.3  Channel Access Control .................................  10
         4.3.1  Channel Ban and Exception .........................  11
         4.3.2  Channel Invitation ................................  11
   5.  Current Implementations ....................................  11
      5.1  Tracking Recently Used Channels ........................  11
      5.2  Safe Channels ..........................................  12
         5.2.1  Channel Identifier ................................  12
         5.2.2  Channel Delay .....................................  12
         5.2.3  Abuse Window ......................................  13
         5.2.4  Preserving Sanity In The Name Space ...............  13
         5.2.5  Server Reop Mechanism .............................  13
   6.  Current problems ...........................................  14
      6.1  Labels .................................................  14
         6.1.1  Channel Delay .....................................  14
         6.1.2  Safe Channels .....................................  15
      6.2  Mode Propagation Delays ................................  15
      6.3  Collisions And Channel Modes ...........................  15
      6.4  Resource Exhaustion ....................................  16
   7.  Security Considerations ....................................  16
      7.1  Access Control .........................................  16
      7.2  Channel Privacy ........................................  16
      7.3 Anonymity ...............................................  17
   8.  Current support and availability ...........................  17
   9.  Acknowledgements ...........................................  17
   10. References ................................................   18
   11. Author's Address ..........................................   18
   12. Full Copyright Statement ...................................  19

1. Introduction

   This document defines in detail on how channels are managed by the
   IRC servers and will be mostly useful to people working on
   implementing an IRC server.





Kalt                         Informational                      [Page 2]

RFC 2811        Internet Relay Chat: Channel Management       April 2000


   While the concepts defined here are an important part of IRC, they
   remain non essential for implementing clients.  While the trend seems
   to be towards more and more complex and "intelligent" clients which
   are able to take advantage of knowing the internal workings of
   channels to provide the users with a more friendly interface, simple
   clients can be implemented without reading this document.

   Many of the concepts defined here were designed with the IRC
   architecture [IRC-ARCH] in mind and mostly make sense in this
   context.  However, many others could be applied to other
   architectures in order to provide forums for a conferencing system.

   Finally, it is to be noted that IRC users may find some of the
   following sections of interest, in particular sections 2 (Channel
   Characteristics) and 4 (Channel Modes).

2. Channel Characteristics

   A channel is a named group of one or more users which will all
   receive messages addressed to that channel.  A channel is
   characterized by its name, properties and current members.

2.1 Namespace

   Channels names are strings (beginning with a '&', '#', '+' or '!'
   character) of length up to fifty (50) characters.  Channel names are
   case insensitive.

   Apart from the the requirement that the first character being either
   '&', '#', '+' or '!' (hereafter called "channel prefix"). The only
   restriction on a channel name is that it SHALL NOT contain any spaces
   (' '), a control G (^G or ASCII 7), a comma (',' which is used as a
   list item separator by the protocol).  Also, a colon (':') is used as
   a delimiter for the channel mask.  The exact syntax of a channel name
   is defined in "IRC Server Protocol" [IRC-SERVER].

   The use of different prefixes effectively creates four (4) distinct
   namespaces for channel names.  This is important because of the
   protocol limitations regarding namespaces (in general).  See section
   6.1 (Labels) for more details on these limitations.

2.2 Channel Scope

   A channel entity is known by one or more servers on the IRC network.
   A user can only become member of a channel known by the server to
   which the user is directly connected.  The list of servers which know





Kalt                         Informational                      [Page 3]

RFC 2811        Internet Relay Chat: Channel Management       April 2000


   of the existence of a particular channel MUST be a contiguous part of
   the IRC network, in order for the messages addressed to the channel
   to be sent to all the channel members.

   Channels with '&' as prefix are local to the server where they are
   created.

   Other channels are known to one (1) or more servers that are
   connected to the network, depending on the channel mask:

      If there is no channel mask, then the channel is known to all
      the servers.

      If there is a channel mask, then the channel MUST only be known
      to servers which has a local user on the channel, and to its
      neighbours if the mask matches both the local and neighbouring
      server names.  Since other servers have absolutely no knowledge of
      the existence of such a channel, the area formed by the servers
      having a name matching the mask has to be contiguous for the
      channel to be known by all these servers.  Channel masks are best
      used in conjunction with server hostmasking [IRC-SERVER].

2.3 Channel Properties

   Each channel has its own properties, which are defined by channel
   modes.  Channel modes can be manipulated by the channel members.  The
   modes affect the way servers manage the channels.

   Channels with '+' as prefix do not support channel modes.  This means
   that all the modes are unset, with the exception of the 't' channel
   flag which is set.

2.4 Privileged Channel Members

   In order for the channel members to keep some control over a channel,
   and some kind of sanity, some channel members are privileged.  Only
   these members are allowed to perform the following actions on the
   channel:

        INVITE  - Invite a client to an invite-only channel (mode +i)
        KICK    - Eject a client from the channel
        MODE    - Change the channel's mode, as well as
                  members' privileges
        PRIVMSG - Sending messages to the channel (mode +n, +m, +v)
        TOPIC   - Change the channel topic in a mode +t channel






Kalt                         Informational                      [Page 4]

RFC 2811        Internet Relay Chat: Channel Management       April 2000


2.4.1 Channel Operators

   The channel operators (also referred to as a "chop" or "chanop") on a
   given channel are considered to 'own' that channel.  Ownership of a
   channel is shared among channel operators.

   Channel operators are identified by the '@' symbol next to their
   nickname whenever it is associated with a channel (i.e., replies to
   the NAMES, WHO and WHOIS commands).

   Since channels starting with the character '+' as prefix do not
   support channel modes, no member can therefore have the status of
   channel operator.

2.4.2 Channel Creator

   A user who creates a channel with the character '!' as prefix is
   identified as the "channel creator".  Upon creation of the channel,
   this user is also given channel operator status.

   In recognition of this status, the channel creators are endowed with
   the ability to toggle certain modes of the channel which channel
   operators may not manipulate.

   A "channel creator" can be distinguished from a channel operator by
   issuing the proper MODE command.  See the "IRC Client Protocol"
   [IRC-CLIENT] for more information on this topic.

3. Channel lifetime

   In regard to the lifetime of a channel, there are typically two
   groups of channels: standard channels which prefix is either '&', '#'
   or '+', and "safe channels" which prefix is '!'.

3.1 Standard channels

   These channels are created implicitly when the first user joins it,
   and cease to exist when the last user leaves it.  While the channel
   exists, any client can reference the channel using the name of the
   channel.

   The user creating a channel automatically becomes channel operator
   with the notable exception of channels which name is prefixed by the
   character '+', see section 4 (Channel modes).  See section 2.4.1
   (Channel Operators) for more details on this title.






Kalt                         Informational                      [Page 5]

RFC 2811        Internet Relay Chat: Channel Management       April 2000


   In order to avoid the creation of duplicate channels (typically when
   the IRC network becomes disjoint because of a split between two
   servers), channel names SHOULD NOT be allowed to be reused by a user
   if a channel operator (See Section 2.4.1 (Channel Operators)) has
   recently left the channel because of a network split.  If this
   happens, the channel name is temporarily unavailable.  The duration
   while a channel remains unavailable should be tuned on a per IRC
   network basis.  It is important to note that this prevents local
   users from creating a channel using the same name, but does not
   prevent the channel to be recreated by a remote user. The latter
   typically happens when the IRC network rejoins.  Obviously, this
   mechanism only makes sense for channels which name begins with the
   character '#', but MAY be used for channels which name begins with
   the character '+'.  This mechanism is commonly known as "Channel
   Delay".

3.2 Safe Channels

   Unlike other channels, "safe channels" are not implicitly created.  A
   user wishing to create such a channel MUST request the creation by
   sending a special JOIN command to the server in which the channel
   identifier (then unknown) is replaced by the character '!'.  The
   creation process for this type of channel is strictly controlled.
   The user only chooses part of the channel name (known as the channel
   "short name"), the server automatically prepends the user provided
   name with a channel identifier consisting of five (5) characters.
   The channel name resulting from the combination of these two elements
   is unique, making the channel safe from abuses based on network
   splits.

   The user who creates such a channel automatically becomes "channel
   creator".  See section 2.4.2 (Channel Creator) for more details on
   this title.

   A server MUST NOT allow the creation of a new channel if another
   channel with the same short name exists; or if another channel with
   the same short name existed recently AND any of its member(s) left
   because of a network split.  Such channel ceases to exist after last
   user leaves AND no other member recently left the channel because of
   a network split.

   Unlike the mechanism described in section 5.2.2 (Channel Delay), in
   this case, channel names do not become unavailable: these channels
   may continue to exist after the last user left.  Only the user
   creating the channel becomes "channel creator", users joining an
   existing empty channel do not automatically become "channel creator"
   nor "channel operator".




Kalt                         Informational                      [Page 6]

RFC 2811        Internet Relay Chat: Channel Management       April 2000


   To ensure the uniqueness of the channel names, the channel identifier
   created by the server MUST follow specific rules.  For more details
   on this, see section 5.2.1 (Channel Identifier).

4. Channel Modes

   The various modes available for channels are as follows:

        O - give "channel creator" status;
        o - give/take channel operator privilege;
        v - give/take the voice privilege;

        a - toggle the anonymous channel flag;
        i - toggle the invite-only channel flag;
        m - toggle the moderated channel;
        n - toggle the no messages to channel from clients on the
            outside;
        q - toggle the quiet channel flag;
        p - toggle the private channel flag;
        s - toggle the secret channel flag;
        r - toggle the server reop channel flag;
        t - toggle the topic settable by channel operator only flag;

        k - set/remove the channel key (password);
        l - set/remove the user limit to channel;

        b - set/remove ban mask to keep users out;
        e - set/remove an exception mask to override a ban mask;
        I - set/remove an invitation mask to automatically override
            the invite-only flag;

   Unless mentioned otherwise below, all these modes can be manipulated
   by "channel operators" by using the MODE command defined in "IRC
   Client Protocol" [IRC-CLIENT].

4.1 Member Status

   The modes in this category take a channel member nickname as argument
   and affect the privileges given to this user.

4.1.1 "Channel Creator" Status

   The mode 'O' is only used in conjunction with "safe channels" and
   SHALL NOT be manipulated by users.  Servers use it to give the user
   creating the channel the status of "channel creator".






Kalt                         Informational                      [Page 7]

RFC 2811        Internet Relay Chat: Channel Management       April 2000


4.1.2 Channel Operator Status

   The mode 'o' is used to toggle the operator status of a channel
   member.

4.1.3 Voice Privilege

   The mode 'v' is used to give and take voice privilege to/from a
   channel member.  Users with this privilege can talk on moderated
   channels.  (See section 4.2.3 (Moderated Channel Flag).

4.2 Channel Flags

   The modes in this category are used to define properties which
   affects how channels operate.

4.2.1 Anonymous Flag

   The channel flag 'a' defines an anonymous channel.  This means that
   when a message sent to the channel is sent by the server to users,
   and the origin is a user, then it MUST be masked.  To mask the
   message, the origin is changed to "anonymous!anonymous@anonymous."
   (e.g., a user with the nickname "anonymous", the username "anonymous"
   and from a host called "anonymous.").  Because of this, servers MUST
   forbid users from using the nickname "anonymous".  Servers MUST also
   NOT send QUIT messages for users leaving such channels to the other
   channel members but generate a PART message instead.

   On channels with the character '&' as prefix, this flag MAY be
   toggled by channel operators, but on channels with the character '!'
   as prefix, this flag can be set (but SHALL NOT be unset) by the
   "channel creator" only.  This flag MUST NOT be made available on
   other types of channels.

   Replies to the WHOIS, WHO and NAMES commands MUST NOT reveal the
   presence of other users on channels for which the anonymous flag is
   set.

4.2.2 Invite Only Flag

   When the channel flag 'i' is set, new members are only accepted if
   their mask matches Invite-list (See section 4.3.2) or they have been
   invited by a channel operator.  This flag also restricts the usage of
   the INVITE command (See "IRC Client Protocol" [IRC-CLIENT]) to
   channel operators.






Kalt                         Informational                      [Page 8]

RFC 2811        Internet Relay Chat: Channel Management       April 2000


4.2.3 Moderated Channel Flag

   The channel flag 'm' is used to control who may speak on a channel.
   When it is set, only channel operators, and members who have been
   given the voice privilege may send messages to the channel.

      This flag only affects users.

4.2.4 No Messages To Channel From Clients On The Outside

   When the channel flag 'n' is set, only channel members MAY send
   messages to the channel.

      This flag only affects users.

4.2.5 Quiet Channel

   The channel flag 'q' is for use by servers only.  When set, it
   restricts the type of data sent to users about the channel
   operations: other user joins, parts and nick changes are not sent.
   From a user's point of view, the channel contains only one user.

   This is typically used to create special local channels on which the
   server sends notices related to its operations.  This was used as a
   more efficient and flexible way to replace the user mode 's' defined
   in RFC 1459 [IRC].

4.2.6 Private and Secret Channels

   The channel flag 'p' is used to mark a channel "private" and the
   channel flag 's' to mark a channel "secret".  Both properties are
   similar and conceal the existence of the channel from other users.

   This means that there is no way of getting this channel's name from
   the server without being a member.  In other words, these channels
   MUST be omitted from replies to queries like the WHOIS command.

   When a channel is "secret", in addition to the restriction above, the
   server will act as if the channel does not exist for queries like the
   TOPIC, LIST, NAMES commands.  Note that there is one exception to
   this rule: servers will correctly reply to the MODE command.
   Finally, secret channels are not accounted for in the reply to the
   LUSERS command (See "Internet Relay Chat: Client Protocol" [IRC-
   CLIENT]) when the <mask> parameter is specified.







Kalt                         Informational                      [Page 9]

RFC 2811        Internet Relay Chat: Channel Management       April 2000


   The channel flags 'p' and 's' MUST NOT both be set at the same time.
   If a MODE message originating from a server sets the flag 'p' and the
   flag 's' is already set for the channel, the change is silently
   ignored.  This should only happen during a split healing phase
   (mentioned in the "IRC Server Protocol" document [IRC-SERVER]).

4.2.7 Server Reop Flag

   The channel flag 'r' is only available on channels which name begins
   with the character '!' and MAY only be toggled by the "channel
   creator".

   This flag is used to prevent a channel from having no channel
   operator for an extended period of time.  When this flag is set, any
   channel that has lost all its channel operators for longer than the
   "reop delay" period triggers a mechanism in servers to reop some or
   all of the channel inhabitants.  This mechanism is described more in
   detail in section 5.2.4 (Channel Reop Mechanism).

4.2.8 Topic

   The channel flag 't' is used to restrict the usage of the TOPIC
   command to channel operators.

4.2.9 User Limit

   A user limit may be set on channels by using the channel flag 'l'.
   When the limit is reached, servers MUST forbid their local users to
   join the channel.

   The value of the limit MUST only be made available to the channel
   members in the reply sent by the server to a MODE query.

4.2.10 Channel Key

   When a channel key is set (by using the mode 'k'), servers MUST
   reject their local users request to join the channel unless this key
   is given.

   The channel key MUST only be made visible to the channel members in
   the reply sent by the server to a MODE query.

4.3 Channel Access Control

   The last category of modes is used to control access to the channel,
   they take a mask as argument.





Kalt                         Informational                     [Page 10]

RFC 2811        Internet Relay Chat: Channel Management       April 2000


   In order to reduce the size of the global database for control access
   modes set for channels, servers MAY put a maximum limit on the number
   of such modes set for a particular channel.  If such restriction is
   imposed, it MUST only affect user requests.  The limit SHOULD be
   homogeneous on a per IRC network basis.

4.3.1 Channel Ban and Exception

   When a user requests to join a channel, his local server checks if
   the user's address matches any of the ban masks set for the channel.
   If a match is found, the user request is denied unless the address
   also matches an exception mask set for the channel.

   Servers MUST NOT allow a channel member who is banned from the
   channel to speak on the channel, unless this member is a channel
   operator or has voice privilege. (See Section 4.1.3 (Voice
   Privilege)).

   A user who is banned from a channel and who carries an invitation
   sent by a channel operator is allowed to join the channel.

4.3.2 Channel Invitation

   For channels which have the invite-only flag set (See Section 4.2.2
   (Invite Only Flag)), users whose address matches an invitation mask
   set for the channel are allowed to join the channel without any
   invitation.

5. Current Implementations

   The only current implementation of these rules as part of the IRC
   protocol is the IRC server, version 2.10.

   The rest of this section deals with issues that are mostly of
   importance to those who wish to implement a server but some parts may
   also be of interest for client writers.

5.1 Tracking Recently Used Channels

   This mechanism is commonly known as "Channel Delay" and generally
   only applies to channels which names is prefixed with the character
   '#' (See Section 3.1 "Standard channels").

   When a network split occurs, servers SHOULD keep track of which
   channels lost a "channel operator" as the result of the break.  These
   channels are then in a special state which lasts for a certain period
   of time.  In this particular state, the channels cannot cease to




Kalt                         Informational                     [Page 11]

RFC 2811        Internet Relay Chat: Channel Management       April 2000


   exist.  If all the channel members leave the channel, the channel
   becomes unavailable: the server local clients cannot join the channel
   as long as it is empty.

   Once a channel is unavailable, it will become available again either
   because a remote user has joined the channel (most likely because the
   network is healing), or because the delay period has expired (in
   which case the channel ceases to exist and may be re-created).

   The duration for which a channel death is delayed SHOULD be set
   considering many factors among which are the size (user wise) of the
   IRC network, and the usual duration of network splits.  It SHOULD be
   uniform on all servers for a given IRC network.

5.2 Safe Channels

   This document introduces the notion of "safe channels".  These
   channels have a name prefixed with the character '!' and great effort
   is made to avoid collisions in this name space.  Collisions are not
   impossible, however they are very unlikely.

5.2.1 Channel Identifier

   The channel identifier is a function of the time.  The current time
   (as defined under UNIX by the number of seconds elapsed since
   00:00:00 GMT, January 1, 1970) is converted in a string of five (5)
   characters using the following base:
   "ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890" (each character has a decimal
   value starting from 0 for 'A' to 35 for '0').

   The channel identifier therefore has a periodicity of 36^5 seconds
   (about 700 days).

5.2.2 Channel Delay

   These channels MUST be subject to the "channel delay" mechanism
   described in section 5.1 (Channel Delay).  However, the mechanism is
   slightly adapted to fit better.

   Servers MUST keep track of all such channels which lose members as
   the result of a network split, no matter whether the user is a
   "channel operator" or not.

   However, these channels do NOT ever become unavailable, it is always
   possible to join them even when they are empty.






Kalt                         Informational                     [Page 12]

RFC 2811        Internet Relay Chat: Channel Management       April 2000


5.2.3 Abuse Window

   Because the periodicity is so long, attacks on a particular channel
   (name) may only occur once in a very long while.  However, with luck
   and patience, it is still possible for a user to cause a channel
   collision.  In order to avoid this, servers MUST "look in the future"
   and keep a list of channel names which identifier is about to be used
   (in the coming few days for example). Such list should remain small,
   not be a burden for servers to maintain and be used to avoid channel
   collisions by preventing the re-creation of such channel for a longer
   period of time than channel delay does.

   Eventually a server MAY choose to extend this procedure to forbid
   creation of channels with the same shortname only (then ignoring the
   channel identifier).

5.2.4 Preserving Sanity In The Name Space

   The combination of the mechanisms described in sections 5.2.2 and
   5.2.3 makes it quite difficult for a user to create a channel
   collision. However, another type of abuse consists of creating many
   channels having the same shortname, but different identifiers.  To
   prevent this from happening, servers MUST forbid the creation of a
   new channel which has the same shortname of a channel currently
   existing.

5.2.5 Server Reop Mechanism

   When a channel has been opless for longer than the "reop delay"
   period and has the channel flag 'r' set (See Section 4.2.7 (Server
   Reop Flag)), IRC servers are responsible for giving the channel
   operator status randomly to some of the members.

   The exact logic used for this mechanism by the current implementation
   is described below.  Servers MAY use a different logic, but that it
   is strongly RECOMMENDED that all servers use the same logic on a
   particular IRC network to maintain coherence as well as fairness.
   For the same reason, the "reop delay" SHOULD be uniform on all
   servers for a given IRC network.  As for the "channel delay", the
   value of the "reop delay" SHOULD be set considering many factors
   among which are the size (user wise) of the IRC network, and the
   usual duration of network splits.

   a) the reop mechanism is triggered after a random time following the
      expiration of the "reop delay".  This should limit the eventuality
      of the mechanism being triggered at the same time (for the same
      channel) on two separate servers.




Kalt                         Informational                     [Page 13]

RFC 2811        Internet Relay Chat: Channel Management       April 2000


   b) If the channel is small (five (5) users or less), and the "channel
      delay" for this channel has expired,
        Then reop all channel members if at least one member is local to
        the server.

   c) If the channel is small (five (5) users or less), and the "channel
      delay" for this channel has expired, and the "reop delay" has
      expired for longer than its value,
        Then reop all channel members.

   d) For other cases, reop at most one member on the channel, based on
      some method build into the server. If you don't reop a member, the
      method should be such that another server will probably op
      someone. The method SHOULD be the same over the whole network. A
      good heuristic could be just random reop.
      (The current implementation actually tries to choose a member
      local to the server who has not been idle for too long, eventually
      postponing action, therefore letting other servers have a chance
      to find a "not too idle" member.  This is over complicated due to
      the fact that servers only know the "idle" time of their local
      users)

6. Current problems

   There are a number of recognized problems with the way IRC channels
   are managed.  Some of these can be directly attributed to the rules
   defined in this document, while others are the result of the
   underlying "IRC Server Protocol" [IRC-SERVER].  Although derived from
   RFC 1459 [IRC], this document introduces several novelties in an
   attempt to solve some of the known problems.

6.1 Labels

   This document defines one of the many labels used by the IRC
   protocol.  Although there are several distinct namespaces (based on
   the channel name prefix), duplicates inside each of these are not
   allowed.  Currently, it is possible for users on different servers to
   pick the label which may result in collisions (with the exception of
   channels known to only one server where they can be averted).

6.1.1 Channel Delay

   The channel delay mechanism described in section 5.1 (Tracking
   Recently Used Channels) and used for channels prefixed with the
   character '#' is a simple attempt at preventing collisions from
   happening.  Experience has shown that, under normal circumstances, it





Kalt                         Informational                     [Page 14]

RFC 2811        Internet Relay Chat: Channel Management       April 2000


   is very efficient; however, it obviously has severe limitations
   keeping it from being an adequate solution to the problem discussed
   here.

6.1.2 Safe Channels

   "Safe channels" described in section 3.2 (Safe Channels) are a better
   way to prevent collisions from happening as it prevents users from
   having total control over the label they choose.  The obvious
   drawback for such labels is that they are not user friendly.
   However, it is fairly trivial for a client program to improve on
   this.

6.2 Mode Propagation Delays

   Because of network delays induced by the network, and because each
   server on the path is REQUIRED to check the validity of mode changes
   (e.g., user exists and has the right privileges), it is not unusual
   for a MODE message to only affect part of the network, often creating
   a discrepancy between servers on the current state of a channel.

   While this may seem easy to fix (by having only the original server
   check the validity of mode changes), it was decided not to do so for
   various reasons.  One concern is that servers cannot trust each
   other, and that a misbehaving servers can easily be detected.  This
   way of doing so also stops wave effects on channels which are out of
   synch when mode changes are issued from different directions.

6.3 Collisions And Channel Modes

   The "Internet Relay Chat: Server Protocol" document [IRC-SERVER]
   describes how channel data is exchanged when two servers connect to
   each other.  Channel collisions (either legitimate or not) are
   treated as inclusive events, meaning that the resulting channel has
   for members all the users who are members of the channel on either
   server prior to the connection.

   Similarly, each server sends the channel modes to the other one.
   Therefore, each server also receives these channel modes.  There are
   three types of modes for a given channel: flags, masks, and data.
   The first two types are easy to deal with as they are either set or
   unset.  If such a mode is set on one server, it MUST be set on the
   other server as a result of the connection.








Kalt                         Informational                     [Page 15]

RFC 2811        Internet Relay Chat: Channel Management       April 2000


   As topics are not sent as part of this exchange, they are not a
   problem.  However, channel modes 'l' and 'k' are exchanged, and if
   they are set on both servers prior to the connection, there is no
   mechanism to decide which of the two values takes precedence.  It is
   left up to the users to fix the resulting discrepancy.

6.4 Resource Exhaustion

   The mode based on masks defined in section 4.3 make the IRC servers
   (and network) vulnerable to a simple abuse of the system: a single
   channel operator can set as many different masks as possible on a
   particular channel.  This can easily cause the server to waste
   memory, as well as network bandwidth (since the info is propagated to
   other servers).  For this reason it is RECOMMENDED that a limit be
   put on the number of such masks per channels as mentioned in section
   4.3.

   Moreover, more complex mechanisms MAY be used to avoid having
   redundant masks set for the same channel.

7. Security Considerations

7.1 Access Control

   One of the main ways to control access to a channel is to use masks
   which are based on the username and hostname of the user connections.
   This mechanism can only be efficient and safe if the IRC servers have
   an accurate way of authenticating user connections, and if users
   cannot easily get around it.  While it is in theory possible to
   implement such a strict authentication mechanism, most IRC networks
   (especially public networks) do not have anything like this in place
   and provide little guaranty about the accuracy of the username and
   hostname for a particular client connection.

   Another way to control access is to use a channel key, but since this
   key is sent in plaintext, it is vulnerable to traditional man in the
   middle attacks.

7.2 Channel Privacy

   Because channel collisions are treated as inclusive events (See
   Section 6.3), it is possible for users to join a channel overriding
   its access control settings.  This method has long been used by
   individuals to "take over" channels by "illegitimately" gaining
   channel operator status on the channel.  The same method can be used
   to find out the exact list of members of a channel, as well as to
   eventually receive some of the messages sent to the channel.




Kalt                         Informational                     [Page 16]

RFC 2811        Internet Relay Chat: Channel Management       April 2000


7.3 Anonymity

   The anonymous channel flag (See Section 4.2.1) can be used to render
   all users on such channel "anonymous" by presenting all messages to
   the channel as originating from a pseudo user which nickname is
   "anonymous".  This is done at the client-server level, and no
   anonymity is provided at the server-server level.

   It should be obvious to readers, that the level of anonymity offered
   is quite poor and insecure, and that clients SHOULD display strong
   warnings for users joining such channels.

8. Current support and availability

     Mailing lists for IRC related discussion:
       General discussion: ircd-users@irc.org
       Protocol development: ircd-dev@irc.org

     Software implementations:
       ftp://ftp.irc.org/irc/server
       ftp://ftp.funet.fi/pub/unix/irc
       ftp://coombs.anu.edu.au/pub/irc

     Newsgroup: alt.irc

9. Acknowledgements

   Parts of this document were copied from the RFC 1459 [IRC] which
   first formally documented the IRC Protocol.  It has also benefited
   from many rounds of review and comments.  In particular, the
   following people have made significant contributions to this
   document:

   Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa
   Ruokonen, Magnus Tjernstrom, Stefan Zehl.
















Kalt                         Informational                     [Page 17]

RFC 2811        Internet Relay Chat: Channel Management       April 2000


10. References

   [KEYWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

   [IRC]        Oikarinen, J. and D. Reed, "Internet Relay Chat
                Protocol", RFC 1459, May 1993.

   [IRC-ARCH]   Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
                April 2000.

   [IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
                2812, April 2000.

   [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
                2813, April 2000.

11. Author's Address

   Christophe Kalt
   99 Teaneck Rd, Apt #117
   Ridgefield Park, NJ 07660
   USA

   EMail: kalt@stealth.net


























Kalt                         Informational                     [Page 18]

RFC 2811        Internet Relay Chat: Channel Management       April 2000


12.  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Kalt                         Informational                     [Page 19]