Internet延遲交談：通道管理（RFC2811— Internet relay chat:client protocol）

Internet延遲交談：通道管理
（RFC2811— Internet relay chat:client protocol）
此備忘錄的狀態
該備忘錄為互連網團體提供資訊。它並不制定任何互連網標準，可以被無限制的發布。
Copyright Notice
Copyright (C) The Internet Society (2000).  All Rights Reserved.
摘要
IRC(Internet延遲交談)協議最令人信服的一個特徵就是允許使用者按論壇分組，稱作通道，
提供了一種多個使用者一起交流的方法。
這篇文檔詳細講述了通道、它們的特徵和屬性怎樣經由IRC伺服器管理。
1．介紹2
2．通道特徵2
2.1名字空間2
2.2通道範圍3
2.3通道屬性3
2.4特權通道使用者3
3．通道生存期4
3.1標準通道4
3.2安全通道4
4．通道模式5
4.1成員資格5
4.2通道標誌6
4.3通道存取控制7
5．目前的實現8
5.1追蹤最近使用過的通道8
5.2安全通道8
6．目前的問題10
6.1標誌10
6.2狀態傳播延遲10
6.3衝突和通道狀態11
6.4資源耗盡11
7．安全考慮11
7.1存取控制11
7.2通道秘密12
7.3匿名12
8．目前的支援和擷取渠道12
9. 感謝12
10. 參考文獻12
11. 作者地址13

1．介紹
這篇文檔詳細地定義了通道是如何由IRC伺服器定義的，它對從事IRC伺服器實現的人
特別有用。
儘管這裡定義的概念是IRC的一個重要部分，但它們對於用戶端的實現卻不是必需的。
儘管用戶端的趨勢是越來越複雜和“聰明”，能夠利用通道的內部工作為使用者提供一個更
友好的介面，但是簡單的用戶端不需要閱讀這篇文檔就能夠實現。
這裡定義的許多概念都是由頭腦裡的IRC體繫結構 [IRC-ARCH]所限定的，並且大多數
只有在這種環境下才有意義。但是其他的許多概念能夠運用到其他的體繫結構，以便為會
議系統提供論壇場所。
最後，要聲明的是IRC使用者可能發現以下幾部分有用，特別是第二部分(通道特徵)和第四
部分(通道狀態)。
2．通道特徵
通道就是由一個或更多使用者組成的命名組，組裡所有成員都接收寄到這個通道的訊息，通
道由它的名字，屬性，目前的成員來標誌。
2.1名字空間
     通道的名字(由一個‘&’，‘#’，‘+’或者‘！’開頭)可以長達五十個字元。通道的
名字對大小寫敏感。
除了第一個字元必須是‘&’，‘#’，‘+’或者‘！’（今後稱作“通道首碼”）的要
求外。對通道名字的唯一限制是它不能包含任何空格（‘ ’）、控制符G(^G或者ASCII 7)、
逗號（‘，’被協議用作清單項目的分隔字元）。還有，冒號（‘：’）用作通道掩碼的分隔字元。
精確的通道名字文法在“IRC Server Protocol“[IRC-Server]中定義。
不同首碼的使用有效地為通道名字創造了四個名字空間。這很重要，因為此協議的局限性
和名字空間有關（一般意義上）。參閱6.1部分（標誌）以獲得關於局限性的更多細節。
2.2通道範圍
     一個通道實體被IRC網路上一個或更多個伺服器所知曉。只有與使用者直連的伺服器
知道的通道，使用者才能加入。知道一個特定通道存在的一系列伺服器必須是IRC網路上
一個鄰近的部分，這樣發送給該通道的訊息才能被發送給所有通道成員。
以‘&’為首碼的通道對建立它們的的伺服器來說是本地的。
其它通道被連到網路上的一個或更多個伺服器知曉，依賴於通道掩碼：
如果沒有通道掩碼，該通道就被所有伺服器知曉。
如果有一個通道掩碼，此通道只被那些有本機使用者連到通道上的伺服器所知曉，如果
掩碼和本地的以及相鄰的伺服器名字相配，那麼也為他的鄰近伺服器知曉。因為其他服務
器完全沒有這樣一個通道的存在的任何資訊，如果這個通道要為所有伺服器知曉的話，這
些具有和掩碼相配的名字的伺服器組成的地區必須和該通道相鄰。通道掩碼最好與伺服器
主機掩碼[IRC-SERVER]配合使用。
2.3通道屬性
        每個通道都有它自己的有通道狀態定義的屬性。通道模式能夠被通道成員使用。模
式影響伺服器管理通道的方式。
       以‘+’作為首碼的通道不支援通道模式。這意味著所有的模式都是未設定的，只設
定了‘t’通道標誌。
2.4特權通道使用者
        為了使通道成員對通道保持一定的控制和一些秩序，一些通道成員被賦予特權。只
有這些成員才允許在通道上執行一下操作：
   INVITE — 邀請一個客戶到一個invite-only通道（模式+i）
   KICK — 將一個客戶從通道中逐出
   MODE — 改變通道的模式，也可以改變成員的特權
   PRIVMSG — 向通道發訊息（模式 +n,+m+v）
   TOPIC — 在模式為+t的通道中改變通道主題
2.4.1通道管理員
        一個給定通道上的通道管理員（也被稱為“chop”或“chanop”）被認為擁有此通道。
通道所有權由通道管理員共用。
        無論什麼時候和通道相關，通道管理員都由與其名字相鄰的‘@’符號來標誌（比
如說，回答NAMES,WHO,和WHOIS命令）。
   由於以字元‘+’為首碼的通道不支援通道模式，因此沒有成員具有通道管理員的地位。
2.4.2通道建立者
        建立一個通道的使用者稱為“通道建立者”，以‘！’首碼作為其標誌。一旦建立了通
道，此使用者也就被賦予了通道管理員的地位。
   為了識別此地位，通道建立者被賦予鎖定通道狀態的能力，這種能力是通道管理員所沒有
的。
  通過發送恰當的MODE命令能夠區分‘通道建立者’和通道管理員。參閱“IRC Client 
Protocol”[IRC—CLIENT]以擷取這方面的更多資訊。
3．通道生存期       
      和通道生存期相關的是，存在兩組典型的通道：標準通道，它的首碼不是‘&’‘#’
就是‘+’，以及安全通道，它的首碼是‘！’。
3.1標準通道
       這些通道當地一個使用者加入時暗中建立，最後一個使用者離開時停止生存。但通道生存
時，任何客戶都能夠通過通道的名字引用此通道。
      建立通道的使用者自動變成通道管理員，當然首碼是‘+’的通道除外，參見第四部分(通
道模式)。參閱2.4.1部分以擷取此主題的更多資訊。
      為了避免建立兩個一樣的通道（特別是當IRC網路由於兩個伺服器的斷連而脫節），通
道名字在通道管理員由於網路斷連離開時應該不允許再被使用者使用。如果這種情況發生了，
通道名字就是暫時不能使用了。通道持續不可用時間應該在每個IRC網路的基礎上做出調
整。需要重點聲明的是這樣可以防止用同一個名字再建立一個通道，但是不能防止遠端用
戶重新建立該通道。後者在IRC網路重新串連時特別容易發生。很明顯，這種機制知識和
與名字以字元‘#’開頭的通道，但也可能被名字以字元‘+’開頭的通道使用。這種機制
被普遍稱作‘通道延遲’。
3.2安全通道
       和其他通道不同，“安全通道”不是暗中建立的。希望建立這類通道的使用者必須向服
務器發送一個特別的JOIN命令以申請建立，伺服器中的通道標識符（接著就是未知的了）
被字元‘！’替代。此類通道的建立受到嚴格控制。使用者只選擇部分通道名字（稱為通道
‘短名’），伺服器自動將使用者提供的名字前面加上五個通道標識符。這兩種元素結合而
成的通道名字是唯一的，使通道不會因為網路斷連而被濫用。
      建立此類通道的使用者自動成為‘通道建立者’。參閱2.4.2部分(通道建立者)以獲得關
於此主題的更多資訊。
      如果新通道的短名和另一個業已存在的通道的短名相同，又如果另一個具有相同短名
的通道最近存在過而且它的成員由於網路斷連離開，那麼伺服器就禁止這樣的通道的建立。
這類通道在最後的成員離開並且最近沒有其他成員由於網路斷連離開後停止生存。
  和5.2.2部分(通道延遲)描述的機制不同的是，在這種情況下通道的名字並不變成停用：
這些通道在最後的成員離開後可能繼續生存。只有建立通道的使用者才變成“通道建立者”，
假如一個存在的空通道的使用者並不自動變成“通道建立者”也不變成“通道管理員”。 
  為了保證通道名字的唯一性，由伺服器建立的通道標識符必須遵循一定的規則。更多的細
節，參閱5.2.1部分（通道標識符）。
4．通道模式
      通道能夠擷取的各種模式如下所示：
         0 — 賦予“通道建立者”地位；
         o — 賦予/收回 “通道管理員”特權；
         v — 賦予/收回 發言特權；
         a — 轉換匿名通道標誌；
         i — 轉換invite-only通道標誌；
         m — 轉換是否調節通道
   n — 轉換是否允許外部客戶發送訊息到通道
   q — 轉換安靜通道標誌；
   p — 轉換私人通道標誌
   s — 轉換秘密通道標誌
   r — 轉換伺服器reop通道標誌
   t — 轉換是否只能由通道管理員設定主題
   k — 設定/刪除通道鑰匙（密碼）；
   l — 設定/刪除通道使用者限制
   b — 設定/刪除禁令掩碼使使用者不能進入
   e — 設定/刪除異常掩碼來覆蓋禁令掩碼；
   I — 設定/刪除邀請掩碼來覆蓋invite-only標誌；
   除非在下面特別聲明，所有這些狀態都能被“通道管理員”通過MODE命令使用，MODE
命令在“IRC Client Protocol”[IRC-CLIENT]中定義。
4.1成員資格
       此域中的模式將通道成員的暱稱作為參數並影響賦予成員的特權。
       4．1．1“通道建立者”身份
               模式‘0’只和“安全通道”結合使用而且不能被使用者使用。伺服器用它來
給予建立通道的使用者“通道建立者”的身份。  
       4．1．2通道管理員地位
               模式‘o’用來轉換通道成員的管理員身份。
       4．1．3發言特權
              模式‘v’用來給予通道成員發言特權和從成員處收回傳言特權。具有這種特
權的使用者能夠在調節過的通道上交談。（參閱4.2.3部分(Moderated Channel Flag)。
4.2通道標誌
       此域中的模式用來定義影響通道如何管理的屬性。
4.2.1匿名標誌
               通道標誌‘a’定義了一個匿名通道。這意味著當一條發送到通道的訊息被
伺服器發送給使用者時，並且它來自使用者，那麼它就要被屏蔽掉。為了屏蔽掉訊息，來源被改
成“anonymous!anonymous@anonymous.”（也就是說，一個別名是“anonymous”，使用者名稱是
“anonymous”的使用者，來自叫做“anonymous”的主機）。因為這樣，伺服器必須禁止別名
為“anonymous”的使用者。伺服器不能為使用者離開這類通道而發送QUIT笑給其他通道的成員，
而是產生一條PART訊息。
在以字元‘&’為首碼的通道上，這個標誌也許由通道管理員轉換，但是在以字元‘！’為前
綴的通道上，這個標誌只能由‘通道建立者’設定（但是不能夠不設定）。此標誌在其它類型
的通道上不能夠使用。
在匿名標誌已經設定的通道上，對whois,who,和names命令的回覆不能夠表明通道上其他用
戶的存在。
4.2.2 Invite Only標誌
        當通道標誌‘i’設定後，新成員只有當他們的掩碼和邀請列表相符（參見4.3.2部
分）或者他們已經被通道管理員邀請。這個標誌也對通道管理員限制了INVITE命令的使用
（參見“IRC Client Protocol”[IRC-CLIENT]。
4.2.3通道已調節標誌
        通道標誌‘m’用來控制誰可以再通道上說話。當它設定時，只有通道管理員，和
被賦予了發言特權的成員才可以向其他通道發送訊息。
這個標誌隻影響使用者。
4.2.4不允許通道外客戶向通道發送訊息
         當通道標誌‘n’設定時，只有通道成員才可以向通道發送訊息。
 這個標誌隻影響使用者。
4.2.5安靜通道
        通道標誌‘q’僅供伺服器使用。設定時，它限制發送給使用者的關於通道操作的資料
類型：其他使用者加入，離開和重要的變化都不發送。從使用者的觀點來看，通道只包含一個用
戶。
這經常用於建立特別的本地通道，這種通道裡伺服器發送和它的操作相關的通知。它作為一
種更加有效率特富有彈性的方法可以用來取代RFC 1459[IRC]裡定義的使用者狀態‘s’。
4.2.6私人和秘密的通道
        通道標誌‘p’用來標誌一個通道是私人的，通道標誌‘s’用來標誌一個通道是秘
密的。兩種性質很相似，他們都向其他使用者隱藏了通道的存在。 
這意味著如夠不加入就沒有辦法從伺服器得到通道的名字。換句話說，對whois命令這樣的
詢問的回覆必須將這些通道省略掉。
當一個通道是‘秘密的’的時候，除了上面的限制外，對topic,list,names命令這樣的詢問，
伺服器必須表現得象通道不存在一樣。上述規則只有一個例外：伺服器會正確地回覆mode
命令。最後，當<mask>參數指定時，秘密通道沒有責任回複lusers命令（參閱“Internet Relay 
Chat：Client Protocol”[IRC—CLIENT]）。
通道標誌‘p’和‘s’不能同時設定。如果伺服器的MODE訊息設定‘p’標誌而且通道已
經設定了‘s’，那麼這種變化就靜靜地被忽略掉。這隻有在斷連恢複期間才能發生。（在“IRC 
Server Protocol”文檔中提到）。
4.2.7伺服器Reop標誌
       通道標誌‘r’只有在名字以字元‘s’開頭的通道中才可用，並且也許只能由‘通道
建立者 ’來轉換。
這個標誌用來防止一個通道長期處於無通道管理員的狀態。當這個標誌設定時，任何失去它
的所有通道管理員超過‘reop延遲’時期的通道將觸發促發伺服器裡的一種機制，將通道內
的一些或所有使用者重設為管理員。這種機制在5.2.4部分中有更詳細的描述（通道reop機制）。
4.2.8主題
       通道標誌‘t’用來限制通道管理員topic命令的使用。
4.2.9使用者限制
       一個使用者限制可以用通道標誌‘l’在通道上設定。當達到限制人數時，伺服器必須
禁止本機使用者加入通道。
限制的值可以從伺服器對mode詢問的回覆中擷取。
4.3通道存取控制
     狀態的最後一個域是用來控制通道的訪問的，它們將一個掩碼作為參數。
為了減小為通道設定的控制訪問狀態的整體資料庫的尺寸，伺服器可能對這類狀態的設定加
上一個最大值限制。如果想加上這種限制，它必須只能影響使用者請求。這種限制對每個IRC
網路來說應該是類似的。
4.3.1通道禁令和異常
       當使用者請求加入一個通道，它的本機伺服器檢查使用者的地址是否和通道的任何禁令掩
碼相符，如果相符，使用者請求就被拒絕，除非該地址也和通道的一個異常掩碼相符。
伺服器不允許通道禁止的成員在通道上發言，除非次成員是通道管理員或者由發言特權。（參
見4.1.3部分（發言特權））。
 通道禁止的使用者，如果它帶有通道管理員發出的邀請，那麼就允許加入通道。
 4.3.2通道邀請
        對那些invite-only標誌設定了的通道，任何使用者，只要它的地址和通道的邀請掩碼
相符，就允許加入通道，即使沒有受到邀請。
5．目前的實現
   目前這些作為IRC協議一部分的規則的唯一實現是IRC伺服器，版本2.10。
   這部分的其他內容涉及對那些希望實現伺服器的人來說特別重要的事情，但是也有些部分
對客戶機程式作者很有用。
5.1追蹤最近使用過的通道
        這種機制一般叫做“通道延遲”，通常用於首碼是字元‘#’的通道（參見3.1部分
（“標準通道”）。
        當網路發生斷連，伺服器必須追蹤哪些通道由於斷連失去了一個‘通道管理員’。這
些通道接著就處於一種特殊的狀態，並持續一段時間。在這種特殊狀態下，通道不能停
止生存。如果所有通道成員都離開了，通道就變成不可擷取的：只要它是空的，本地客
戶就不能加入。
        一旦一個通道不可擷取，當遠端使用者加入通道（最可能因為網路正在恢複）或延遲
期滿（這種情況下通道停止生存，可能重新建立），它都會變成可擷取的。通道的死亡推
遲時間的設定需要考慮很多因素，有IRC網路的規模，和網路通常斷連的期間。對
一個給定的IRC網路來說，這個時間在所有伺服器上應該都是一樣的。
5.2安全通道
        這篇文檔介紹“安全通道”的概念。這些通道首碼為字元‘!’，並且盡最大努力避
免此名字空間內的衝突。衝突並不是不可能的，但是一般不會發生。
5.2.1通道標識符
              通道標識符是時間的一個函數。目前時間被轉換成五個字元的字串，以
“ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890”為基數（每個字元都有一個十
進位的值,‘A’對應0到‘0’對應35）。
    因此通道標識符的周期為36^5秒（大概700天）
5.2.2通道延遲
            這些通道必須服從5.1部分描述的“通道延遲”機制。但是，這種機制被稍微改
進以運行得更好。
    伺服器必須追蹤由於網路斷連而失去成員的通道，不管失去的使用者是不是‘通道管理員’。
    但是，這些通道從不變的不可擷取，即使當它們為空白時也可以加入。
5.2.3濫用視窗
            因為周期如此之長，對特定通道的攻擊要很長時間才發生一次。但是，如果有
運氣和耐心的話，使用者仍然可能引起通道衝突。為了避免此類事情的發生，伺服器必須
‘向長遠看’，維持一個通道名字的列表，這些名字的標識符將來要用（比如在未來的幾
天裡）。這樣的列表應該保持小的規模，不應成為伺服器要維持的負擔，這些列表用來在
比通道延遲更長的時期內避免相同通道的再建立。
    最後一個伺服器程式可能選擇擴充這種程式，禁止短名相同的通道的建立（接著忽略通
道標識符）。
5.2.4保持名字空間內的正常
            5.2.2和5.2.3部分描述的機制的結合使使用者很難令通道發生衝突。但是，存在
另外一種形式的濫用，就是建立許多有相同短名但是不同標識符的通道。為了防止其發
生，如果通道的短名和目前業已存在的通道相同，伺服器就必須禁止這個通道的建立。
5.2.5伺服器Reop 機制
            當一個通道開放時間長於‘reop延遲’時間，並且通道設定了‘r’標誌（參見
4.2.7(伺服器reop標誌)），IRC伺服器有責任隨機地將通道管理員地位賦給一些成員。 
    下面描述目前的實現中為這種機制使用的邏輯。伺服器可能使用不同的邏輯，但是強烈
建議所有在一個IRC網路上的伺服器使用相同的邏輯，以保證一致性和公正性。基於相
同的原因，對一個給定的IRC網路，“reop延遲”的值在所有主機上都應一致。同“通
道延遲”一樣，“reop延遲”值的設定也應該考慮很多因素，包括IRC網路的規模，網
絡斷連通常的期間。
a)reop機制在“reop延遲”期滿，一段隨機時間之後被觸發。這樣可以限制此機制在
兩台分離的伺服器上同時觸發的可能性。
b)如果通道規模很小（五個使用者或者更少），並且這個通道的“通道延遲”已生理期滿，
如果至少有一個成員對伺服器來說是本地的話，那麼就將所有使用者重設管理員。
c)如果通道規模很小（五個使用者或者更少），並且這個通道的“通道延遲”已生理期
        滿，“reop延遲”也已期滿。接著就將所有使用者重設管理員。
d)對於其他情況，至多將通道上的一個成員重設管理員，以伺服器的內建方法為基礎。
如果你不將一個成員重設管理員，內建方法應該就是另一個伺服器極可能將某個用
戶設為管理員。這種方法在整個網路上應該都是一樣的。一個好的啟發學習法方法是隨
機重設管理員。
（目前的實現實際上是試著選一個伺服器的本地成員，這個成員要是沒有閑置太久
的，最終延遲行動，因此使其它伺服器有機會尋找一個沒有太閑置的成員。這太複
雜了，因為伺服器只知道本機使用者的閑置時間）
6．目前的問題
   IRC通道管理方式有一些問題已經被認識到了。有一些能直接歸因於這篇文檔裡定義的規
則，其它的是底層的“IRC Server Protocol”的結果。儘管來源於RFC 1459[IRC]，這篇文檔
試著提出了一些新鮮方法解決一些已知的問題。
6.1標誌
   這篇文檔定義了IRC協議使用的眾多標誌中的一個。儘管有許多不同的名字空間（給予通
道名字首碼），但是不允許在內部重用他們。目前，有可能不同伺服器上的使用者採用相同的可
能引起衝突的標誌，（只有一個伺服器知道的通道除外，這裡能夠防止衝突）。
6.1.1通道延遲
       5.1部分描述的，由首碼是字元‘#’的通道使用的通道延遲機制（追蹤最近使用過的
通道）是一個防止衝突發生的簡單嘗試。經驗表明，在通常情況下，它非常有效；但是，很
明顯它有很多局限使它不能夠解決這裡討論的問題。
6.1.2安全通道
        3.2部分（安全通道）描述的“安全通道”是一個較好的防止衝突發生的方法，因為
它避免使用者對他們選擇的標誌擁有完全控制。這種標誌明顯的缺點是他們對使用者不友好。但
是，用戶端要改進這一點是相當繁瑣的。
6.2狀態傳播延遲
     因為網路引起的延遲，以及每個伺服器都要求檢查狀態變化的正確性（比如，使用者存在
且有合適的特權），有時一條狀態資訊隻影響部分網路，經常使伺服器上關於通道狀態的資訊
出現差異。
儘管這個毛病看起來容易改正（通過讓原始伺服器檢查狀態變化正確性的方法），但卻有各種理
由決定不這樣做。一種擔心是伺服器彼此不能信任，這樣發生錯誤的伺服器就容易檢測出來。
這樣作業防止了來自各個方向狀態資訊的不同步對通道造成的巨大影響。
6.3衝突和通道狀態
     “Internet Relay Chat:Server Protocol”文檔[IRC-SERVER]描述了當兩台伺服器串連時通
道資料是如何交換的。通道衝突（不管是合理的或是不合理的）被認為是內部的事情，意味
著參與的通道都使通道成員優先串連。
類似的，每個伺服器發送通道狀態給其它伺服器。因此，每個伺服器也接收這些通道狀
態。對一個給定的通道有三種模式：標誌，掩碼，和資料。前兩種容易處理，因為他們要麼
設定要麼不設定。如果這樣的一種模式在伺服器上設定了，由於相連，它必須在另一個服務
器上也進行設定。
由於主題不作為交換的一部分進行發送，他們不成問題。但是，通道模式‘l’和‘k’
參與交換，如果在串連之前它們在雙方伺服器上都設定了，就沒有一種機制來決定這兩個值
那個優先。留給使用者去調整由此導致的差異。
6.4資源耗盡
     4.3部分定義的以掩碼為基礎的模式使IRC伺服器（和網路）容易草率地濫用系統：一
個通道管理員能夠在一個通道上儘可能多地設定不同的掩碼。這很容易導致伺服器浪費記憶體
和網路頻寬（因為資訊被傳播到其它伺服器上）。由於此原因，建議象4.3部分提到的那樣對
每個通道能設定的掩碼數量進行限制。
而且，可能還有更複雜的機制用來避免為相同的通道設定多餘的掩碼。
7．安全考慮
7.1存取控制
        控制對通道的訪問的最主要的方法之一就是使用掩碼，掩碼基於使用者串連的使用者名稱
和主機名稱。只有在IRC伺服器有一種精確的鑒別使用者串連的方法，並且使用者不能夠輕易地逃
避這種鑒別的情況下，這種機制才有效率和安全。儘管在理論上可能實現如此嚴格的鑒別機
制，但是大多數IRC網路（特別是公用網路）並沒有象這樣的機制，而且對一個客戶串連的
使用者名稱和主機名稱的準確性只提供了很少的保證。
控制訪問的另一種方法是使用通道鑰匙，但因為這種鑰匙是以純文字形式發送的，因此中途
很容易受到攻擊。
7.2通道秘密
因為通道衝突被視為內部事件（參見6.3部分）， 所以有可能使用者超越存取控制設定而
加入通道。這種方法很長時間都被個人用來通過非法擷取通道管理員地位來“控制”通道。
同樣的方法能用來找出通道的精確成員列表，以及接收許多發送給通道的訊息。
7.3匿名
匿名通道標誌（參見4.2.1部分）能用來向這類通道上所有使用者呈遞“anonymous”，方
法是使所有發送到這個通道的訊息好像都來自一個暱稱為“anonymous”的假使用者。這是在客
戶—伺服器層級上實現的，在伺服器—伺服器層級上不提供匿名。
對讀者來說應該很明顯，匿名提供的層級是很低的而且不安全，客戶程式應向加入此類
通道的使用者出示嚴重警告
8．目前的支援和擷取渠道
   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. 感謝
   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.
10. 參考文獻
  [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. 作者地址
   Christophe Kalt
   99 Teaneck Rd, Apt #117
   Ridgefield Park, NJ 07660
   USA

   EMail: kalt@stealth.net

RFC2811—Internet relay chat:client protocol                 Internet延遲交談：通道管理