www.irc.pl

T�umaczenie                                                 P. Kucharski
Network Working Group                                            C. Kalt
Request for Comments: 2811                                 kwiecie� 2000
Aktualizuje: 1459
Kategoria: Informacyjne


                            IRC: Zarz�dzanie kana�em

Status tego memo

  Memo to zawiera informacje dla spo�eczno�ci internetowej. Nie specyfikuje
  standardu internetowego �adnego rodzaju. Dystrybucja tego memo nie jest
  ograniczona.

Notatka o prawach w�asno�ci

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

   [...]

2. Definicja kana�u

   Kana� to nazwana grupa jednego lub wi�cej u�ytkownik�w, kt�rzy 
   otrzymuj� wiadomo�ci adresowane do tego kana�u. Kana� jest opisany 
   przez jego nazw�, w�a�ciwo�ci i aktualnych cz�onk�w.

2.1 Nazwy

   Nazwy kana��w to napisy (zaczynaj�ce si� od '&', '#', '+' lub '!')
   o d�ugo�ci nie wi�kszej ni� pi��dziesi�t (50) znak�w. Nazwy kana��w
   nie s� wra�liwe na wielko�� liter.

   Opr�cz wymagania, �eby pierwszy znak by� '&', '#', '+' lub '!' (od tej
   pory nazywanymi "prefiksem kana�u"), nazwa kana�u nie mo�e zawiera�
   �adnych spacji (' '), znaku CTRL-G (^G lub ASCII 7) ani przecinka (',').
   Dodatkowo dwukropek (':') jest u�ywany jako znak rozdzielaj�cy mask�
   kana�u.

   [...]

2.2 Zakres istnienia kana��w

   Kana� jest znany przez jeden lub wi�cej serwer�w sieci IRC. U�ytkownik
   mo�e zosta� cz�onkiem tylko tych kana��w, kt�re s� znane serwerowi, do
   kt�rego u�ytkownik jest pod��czony. Wszystkie serwery, kt�re znaj� dany
   kana�, musz� ze sob� s�siadowa� po to, �eby wiadomo�ci adresowane na ten
   kana� mog�y zosta� wys�ane do wszystkich cz�onk�w kana�u.

   Kana�y z prefiksem '&' s� lokalne dla serwera, na kt�rym zosta� utworzone.

   Inne kana�y s� znane jednemu lub wi�kszej ilo�ci serwer�w, kt�re s�
   po��czone w sie�, w zale�no�ci od maski kana�u:

      Je�li kana� nie posiada maski, kana� jest znany wszystkim serwerom.

      Je�li kana� ma mask�, to kana� ten mo�e by� znany tylko tym serwerom,
      kt�re pasuj� do maski kana�u. Poniewa� inne serwery nie maj� poj�cia
      o istnieniu takiego kanalu, obszar uformowany przez serwery maj�ce
      nazw� pasuj�c� do maski musi by� ci�g�y, �eby wszystkie te serwery
      zna�y ten kana�. U�ycie masek kana��w jest najlepsze w po��czeniu
      z maskowaniem serwer�w [IRC-SERVER].

2.3 W�a�ciwo�ci kana�u

   Ka�dy kana� ma swoje w�a�ciwo�ci, kt�re s� zdefiniowane w trybach 
   kana�owych. Tryby kana�owe mog� by� zmieniane przez cz�onk�w kana�u. 
   Tryby wp�ywaj� na spos�b, w jaki serwery zarz�dzaj� kana�ami.

   Kana�y z prefiksem '+' nie posiadaj� tryb�w kana�owych. Oznacza to, 
   �e wszystkie tryby s� zdj�te za wyj�tkiem trybu kana�u 't', kt�ry 
   jest ustawiony.

2.4 Uprzywilejowani cz�onkowie kana�u

   Aby umo�liwi� cz�onkom kana�u zachowanie porz�dku i jakiej� kontroli 
   nad kana�em, niekt�rzy cz�onkowie kana�u s� uprzywilejowani.
   Tylko ci cz�onkowie mog� przeprowadza� nast�puj�ce akcje na kanale:

        INVITE  - zaprasza klienta na kana� z ustawionym trybem +i
        KICK    - usuwa klienta z kana�u
        MODE    - zmienia tryby kana�u, a tak�e przywileje cz�onk�w
        PRIVMSG - wysy�a wiadomo�ci na kana� z ustawionym trybem +m
        TOPIC   - zmienia temat kana�u na kanale z ustawionym trybem +t

2.4.1 Operatorzy kana�u

   Operatorzy kana�u (znani tak�e jako "chanopi") na danym kanale s� uwa�ani
   za "w�a�cicieli" tego kana�u. W�asno�� kana�u jest wsp�dzielona mi�dzy
   wszystkich operator�w kana�u.

   Operatorzy kana�u s� identyfikowani przez znak '@' przed ich nickiem
   przy wszystkich komendach ��cz�cych nicki i dany kana� (tj. odpowiedzi
   na komendy NAMES, WHO czy WHOIS).

   Jako �e kana�y zaczynaj�ce si� od prefiksu '+' nie posiadaj� tryb�w
   kana�owych, �aden z cz�onk�w tego kana�u nie mo�e mie� statusu operatora
   kana�u.

2.4.2 Tw�rca kana�u

   U�ytkownik, kt�ry tworzy kana� z prefiksem '!' jest identyfikowany
   jako "tw�rca kana�u". Po utworzeniu kana�u u�ytkownikowi jest tak�e
   nadawane uprawnienie operatora kana�u.

   Tw�rca kana�u ma mo�liwo�� ustawiania niekt�rych tryb�w kana�u, kt�rych
   nie mog� ustawia� operatorzy kana�u.

   Tw�rca kana�u jest odr�niany od operatora kana�u przez wydanie specjalnej
   komendy MODE. Przeczytaj dokument "Protok� klienta IRC" [IRC-CLIENT], �eby
   dowiedzie� si� wi�cej na ten temat.

   [...]

4. Tryby kana�u

   Kana�y maj� dost�pne nast�puj�ce tryby:

        O - status "tw�rcy kana�u" (tylko serwer)
        o - przyznaje/zabiera przywilej operatora kana�u
        v - przyznaje/zabiera przywilej g�osu

        a - w��cza anonimowo�� na kanale (bez mo�liwo�ci wy��czenia)
        i - kana� tylko na zaproszenie
        m - moderacja kana�u
        n - mo�liwo�� wysy�ania wiadomo�ci spoza kana�u
        q - tryb cichy (tylko serwer)
        p - tryb prywatny
        s - tryb sekretny
        r - w��cza reopowanie kana�u
        t - zastrzega ustawianie tematu tylko dla operator�w

        k - klucz kana�u (has�o);
        l - limit u�ytkownik�w na kanale

        b - maska u�ytkownik�w, kt�rzy nie mog� wej�� na kana� (tzw. ban)
        e - maska u�ytkownik�w, kt�rzy mog� wej�� na kana� mimo bana
        I - maska u�ytkownik�w, kt�rzy mog� wej�� bez zaproszenia na
            kana� z ustawionym trybem tylko na zaproszenie

   Je�li nie zastrze�ono inaczej, wszystkie te tryby mog� by� zmieniane
   przez operator�w kana��w przy u�yciu komendy MODE zdefiniowanej
   w dokumencie "Protok� klienta IRC" [IRC-CLIENT].

4.1 Status cz�onk�w kana�u

   Tryby w tej kategorii przyjmuj� nick jako argument i wp�ywaj� na
   przywileje przyznawane u�ytkownikowi.

4.1.1 Status tw�rcy kana�u

   Tryb 'O' jest u�ywany tylko w powi�zaniu z bezpiecznymi kana�ami
   (z prefiksem '!') i nie mo�e by� zmieniany przez u�ytkownik�w.
   Serwery u�ywaj� go do nadania u�ytkownikowi tworz�cemu kana� status
   "tw�rcy kana�u".

4.1.2 Status operatora kana�u

   Tryb 'o' jest u�ywany do prze��czania przywileju operatora kana�u.

4.1.3 Przywilej g�osu

   Tryb 'v' jest u�ywany do prze��czania przywileju g�osu. U�ytkownicy
   z nadanym przywilejem g�osu mog� rozmawia� na kana�ach moderowanych.
   (Zobacz sekcja 4.2.3 (Kana� moderowany)).

4.2 Tryby kana�u

   Tryby w tej kategorii s� u�ywane do zdefiniowania w�a�ciwo�ci,
   kt�re wp�ywaj� na spos�b dzia�ania kana�u.

4.2.1 Tryb anonimowy

   Tryb kana�u 'a' definiuje kana� jako anonimowy. Oznacza to, �e
   wiadomo�ci od u�ytkownik�w wysy�ane na ten kana� musz� by� zamaskowane
   przez serwer. W celu zamaskowania nadawca wiadomo�ci jest zmieniony
   na "anonymous!anonymous@anonymous." (czyli pseudou�ytkownik o nicku 
   "anonymous", nazwie u�ytkownika "anonymous" z komputera o nazwie 
   "anonymous.").

   [...]

   Na kana�ach z prefiksem '&' ta flaga mo�e zosta� w��czona przez operatora
   kana�u, a na kana�ach z prefiksem '!' tylko przez tw�rc� kana�u. Ten tryb
   nie mo�e by� dost�pny na innych typach kana��w.

   Odpowiedzi na komendy WHOIS, WHO i NAMES nie mog� odkry� obecno�ci innych
   u�ytkownik�w na kana�ach z ustawionym trybem anonimowo�ci.

4.2.2 Kana� na zaproszenie

   Kiedy kana� ma ustawiony tryb 'i', u�ytkownicy mog� wej�� na kana� tylko 
   wtedy, gdy ich maska pasuje do listy zaprosze� (patrz sekcja 4.3.2) lub
   gdy zostali zaproszeni przez operatora kana�u. Tryb ten ogranicza 
   mo�liwo�� u�ycia komendy INVITE (zobacz "IRC: Protok� klienta" 
   [IRC-CLIENT]) do operator�w kana�u.

4.2.3 Kana� moderowany

   Ustawienie trybu 'm' jest u�ywane do kontrolowania, kto mo�e m�wi�
   na kanale. Gdy jest ustawiony, tylko operatorzy kana�u i cz�onkowie 
   kana�u z przywilejem g�osu mog� wysy�a� wiadomo�ci na kana�.

   Tryb ten oddzia�uje tylko na u�ytkownik�w.

4.2.4 Zakaz wysy�ania wiadomo�ci spoza kana�u

   Gdy kana� ma ustawiony tryb 'n', tylko cz�onkowie kana�u mog� wysy�a�
   wiadomo�ci na ten kana�.

   Tryb ten oddzia�uje tylko na u�ytkownik�w.

4.2.5 Cichy kana�

   Tryb 'q' jest u�ywany tylko przez serwery. Gdy jest ustawiony, ogranicza
   rodzaj informacji wysy�anych do u�ytkownik�w o kanale; wej�cia i wyj�cia
   innych u�ytkownik�w oraz zmiany nick�w nie s� wysy�ane. Z punktu widzenia
   u�ytkownika kana� ma tylko jednego u�ytkownika.

   Tryb ten jest u�ywany przy tworzenia specjalnych lokalnych kana��w, na kt�re
   serwer wysy�a informacje o jego dzia�aniu. Spos�b ten jest bardziej wydajny
   i elastyczny ni� flaga u�ytkownika 's', zdefiniowana w RFC 1459 [IRC].

4.2.6 Kana�y prywatne i sekretne

   Tryb kana�u 'p' jest u�ywany do zaznaczenia kana�u jako prywatnego,
   a 's' -- sekretnego. Oba tryby s� podobne i ukrywaj� istnienie kana�u
   przed innymi u�ytkownikami.

   Oznacza to, �e nie ma mo�liwo�ci na poznanie nazwy kana�u, je�li si�
   nie jest jego cz�onkiem. Innymi s�owy, kana�y te musz� by� pomini�te
   w odpowiedzi na komendy takie jak WHOIS.

   Kiedy kana� jest sekretny, dodatkowo dla komend takich jak TOPIC, LIST 
   i NAMES serwer b�dzie dzia�a� tak, jakby kana� nie istnia�. Trzeba 
   zauwa�y�, �e jest jeden wyj�tek od tej
   zasady: serwery poprawnie odpowiedz� na komend� MODE.

   Tryby kana�u 'p' i 's' nie mog� by� ustawione r�wnocze�nie. Je�li
   tryb 'p' ustawia serwer, a tryb 's' jest ju� ustawiony na kanale,
   zmiana ta zostanie zignorowana. Zdarza si� tak tylko w trakcie leczenia
   splitu (wspomnianej w dokumencie "IRC: Protok� serwera" [IRC-SERVER]).

4.2.7 Tryb reopowania

   Tryb 'r' jest dost�pny tylko na kana�ach z prefiksem '!' i mo�e zosta�
   ustawiony tylko przez tw�rc� kana�u.

   Tryb ten jest u�ywany do zapobiegania bezopiu na kanale. 
   Gdy ten tryb jest ustawiony, kana�, kt�ry straci� wszystkich
   operator�w na czas d�u�szy ni� czas reopu, powoduje uruchomienie
   mechanizmu reopowania jednego lub wszystkich cz�onk�w kana�u. Procedura
   ta jest opisana dok�adniej w sekcji 5.2.5 (Mechanizm reopowania).

4.2.8 Temat

   Tryb 't' jest u�ywany do ograniczenia u�ycia komendy TOPIC tylko dla
   operator�w kana�u.

4.2.9 Limit u�ytkownik�w

   Limit u�ytkownik�w mo�e zosta� ustawiony na kanale trybem 'l'.
   Kiedy liczba u�ytkownik�w na kanale osi�gnie warto�� limitu, serwer
   nie mo�e pozwoli� na wej�cie na kana� lokalnym u�ytkownikom, chyba �e
   zostali zaproszeni przez operatora kana�u.

   Warto�� limitu jest podawana w odpowiedzi na komend� MODE tylko cz�onkom
   kana�u.

4.2.10 Klucz

   Kiedy kana� ma ustawiony klucz (przez u�ycie trybu 'k'), serwery
   musz� odrzuca� pr�by wej�cia na kana� bez poprawnego klucza.

   Klucz jest podawany w odpowiedzi na komend� MODE tylko cz�onkom kana�u.

4.3 Kontrola dost�pu do kana�u

   Ostatnia kategoria tryb�w jest u�ywana do kontrolowania dost�pu
   do kana�u. Tryby te jako argumenty przyjmuj� mask�.

   W celu ograniczenia wielko�ci bazy z trybami kontroli dost�pu,
   serwery mog� ograniczy� ilo�� takich tryb�w dla ka�dego kana�u.
   Je�li takie ograniczenie jest za�o�one, musi dotyczy� tylko klient�w.
   Limit taki powinien by� jednorodny w ca�ej sieci.

4.3.1 Bany i wyj�tki

   Kiedy u�ytkownik pr�buje wej�� na kana�, jego serwer sprawdza, czy
   adres u�ytkownika pasuje do kt�rej� z masek ban�w ('b') dla tego kana�u.
   Je�li tak, u�ytkownik nie mo�e wj�� na kana�, chyba �e jego adres
   pasuje tak�e do jednej z masek wyj�tk�w ('e') tego kana�u.

   Serwery nie mog� pozwoli� zabanowanym cz�onkom kana�u na m�wienie
   na tym kanale, chyba �e cz�onek taki jest r�wnocze�nie operatorem
   kana�u lub ma przywilej g�osu. (Zobacz sekcja 4.1.3 (Przywilej g�osu)).

   Zabanowany u�ytkownik mo�e wej�� na kana� pod warunkiem, �e zosta�
   zaproszony przez operatora kana�u.

4.3.2 Lista zaprosze�

   Na kana�y tylko na zaproszenie (patrz sekcja 4.2.2 (Kana� na zaproszenie))
   mog� wej�� bez zaproszenia u�ytkownicy, kt�rych adres pasuje do listy
   zaprosze� ('I') na tym kanale.

5.1 �ledzenie ostatnio u�ywanych kana��w

   Mechanizm ten jest znany popularnie jako "Channel Delay" i zwykle
   dotyczy kana��w z prefiksem '#' (patrz sekcja 3.1 "Kana�y standardowe").

   Kiedy zdarza si� split sieci, serwery powinny pami�ta�, kt�re kana�y
   straci�y operator�w kana�u w wyniku takiego roz��czenia. Kana�y te
   s� w specjalnym stanie, kt�ry trwa przez pewien czas. W tym stanie
   kana�y nie znikaj�. Je�li wszyscy cz�onkowie kana�u opuszcz� ten kana�,
   staje si� on niedost�pny - klienci lokalnego serwera nie mog� wej�� 
   na ten kana� dop�ki jest pusty.

   Kana� niedost�pny staje si� dost�pny ponownie albo gdy u�ytkownik
   innego serwera wejdzie na ten kana� (jako wynik leczenia splitu), albo
   gdy up�ynie okres ochrony (w tym wypadku kana� przestaje istnie�
   i mo�e zosta� utworzony ponownie).

   [...]

5.2.5 Mechanizm reopowania

   Gdy na kanale jest bezopie przez czas d�u�szy ni� "czas reopu"
   i ma ustawiony tryb 'r' (patrz sekcja 4.2.7 (Tryb reopowania)),
   serwery IRC maj� za zadanie przywr�cenie na kanale statusu
   operatora kana�u niekt�rym jego cz�onkom.

   Dok�adna logika u�ywana przez obecn� implementacj� jest opisana poni�ej.
   Serwery mog� u�ywa� innego mechanizmu, ale jest zalecane, �eby
   wszystkie serwery w sieci u�ywa�y tego samego mechanizmu, aby zachowa�
   sp�jno�� i sprawiedliwo��. Z tych samych powod�w "czas reopu" powinien
   by� taki sam na wszystkich serwerach ca�ej sieci. [...]

   a) mechanizm reopowania jest w��czony po losowym czasie po up�yni�ciu
      "czasu reopu". To powinno ograniczy� mo�liwo�� wyzwolenia mechanizmu
      w tym samym czasie (dla tego samego kana�u) na r�nych serwerach.

   b) je�li kana� jest ma�y (pi�ciu (5) u�ytkownik�w lub mniej) i up�yn��
      czas ochrony kana�u ("channel delay"), serwer ma reopowa� wszystkich
      cz�onk�w kana�u, je�eli przynajmniej jeden z jego cz�onk�w korzysta
      z tego serwera.

   c) je�li kana� jest ma�y (pi�ciu (5) u�ytkownik�w lub mniej) i up�yn��
      "czas reopu", serwer ma reopowa� wszystkich cz�onk�w kana�u.

   d) w pozosta�ych przypadkach nale�y reopowa� przynajmniej jednego
      cz�onka kana�u, w spos�b wbudowany w serwer. Je�li serwer tego
      nie zrobi, metoda musi by� taka, �e zrobi to inny serwer. Metoda
      powinna by� taka sama na wszystkich serwerach sieci. Dobrym sposobem
      jest zwyk�a losowo��.
      (Aktualna implementacja pr�buje wybra� lokalnego cz�onka kana�u,
      kt�ry nie by� zbyt d�ugo bezczynny, a je�li takiego nie ma, to
      odk�ada akcj� na p�niej w nadziei, �e inny serwer znajdzie takiego
      niezbyt bezczynnego klienta. Jest to troch� zbyt skomplikowane, gdy�
      tylko serwer klienta zna jego czas bezczynno�ci.)

6.3 Kolizje i tryby kana�u

   Dokument "IRC: Protok� serwera" [IRC-SERVER] opisuje, w jaki spos�b
   dane s� wymieniane, gdy dwa serwery po��cz� si� ze sob�. Efektem kolizji 
   kana��w jest ich z��czenie, tj. wynikowy kana� za u�ytkownik�w ma 
   wszystkich u�ytkownik�w tych kana��w na obu serwerach przed po��czeniem.

   Podobnie ka�dy serwer wysy�a tryby kana�owe do drugiego serwera.

   [...]

   Je�li jaki� tryb jest ustawiony na jednym serwerze, po po��czeniu musi 
   by� tak�e ustawiony na drugim serwerze (za wyj�tkiem opisanym w sekcji 
   4.2.6).

   Tematy nie s� przesy�ane w trakcie po��czenia. 
   Jednak�e tryby 'l' i 'k' zostaj� zamienione, je�li by�y r�ne na obu
   serwerach przed po��czeniem, i nie ma �adnego mechanizmu, kt�ry by 
   pozwoli� ustali�, kt�ry tryb powinien zosta�. Naprawianie takich 
   rozbie�no�ci zosta�o pozostawione operatorom kana�u.

6.4 Wyczerpanie zasob�w

   Tryby z maskami jako parametrami zdefiniowane w sekcji 4.3 powoduj�,
   �e serwery IRC (i sie�) s� nara�one na proste nadu�ycia: pojedynczy
   operator kana�u mo�e ustawi� tak du�o r�nych masek na kanale, �e 
   spowoduje to wyczerpanie si� pami�ci serwera, a tak�e przepustowo�ci 
   sieci (informacje te s� bowiem propagowane do innych serwer�w). Z tego 
   powodu zalecane jest, �eby na ilo�� tryb�w z maskami na jednym kanale 
   by� zak�adany limit, tak jak o tym wspomniano w sekcji 4.3.

   Dodatkowo mog� zosta� u�yte bardziej skomplikowane mechanizmy, aby 
   unikn�� ustawiania na jednym kanale redundantnych masek.

   [...]

10. Odno�niki

   [...]

   [IRC]        Oikarinen, J. and D. Reed, "Protok� IRC", RFC 1459, maj 1993.

   [IRC-ARCH]   Kalt, C., "IRC: Architektura", RFC 2810, kwiecie� 2000.

   [IRC-CLIENT] Kalt, C., "IRC: Protok� klienta", RFC 2812, kwiecie� 2000.

   [IRC-SERVER] Kalt, C., "IRC: Protok� serwera", RFC 2813, kwiecie� 2000.