Internet延遲交談：通道管理

此備忘錄的狀態
該備忘錄為互聯網團體提供信息。它并不制定任何互聯網標準，可以被無限制的發布。
CopyrightNotice
Copyright(C)TheInternetSociety(2000).AllRightsReserved.
摘要
IRC(Internet延遲交談)協議最引人注目的一個特征就是允許用戶按論壇分組，稱作通道，
提供了一種多個用戶一起交流的方法。
這篇文檔詳細講述了通道、它們的特征和屬性怎樣經由IRC服務器管理。
1．介紹
這篇文檔詳細地定義了通道是如何由IRC服務器定義的，它對從事IRC服務器實現的人
特別有用。
盡管這里定義的概念是IRC的一個重要部分，但它們對于客戶端的實現卻不是必需的。
盡管客戶端的趨勢是越來越復雜和“聰明”，能夠利用通道的內部工作為用戶提供一個更
友好的界面，但是簡單的客戶端不需要閱讀這篇文檔就能夠實現。
這里定義的許多概念都是由頭腦里的IRC體系結構[IRC-ARCH]所限定的，并且大多數
只有在這種環境下才有意義。但是其他的許多概念能夠運用到其他的體系結構，以便為會
議系統提供論壇場所。
最后，要聲明的是IRC用戶可能發現以下幾部分有用，特別是第二部分(通道特征)和第四
部分(通道狀態)。
2．通道特征
通道就是由一個或更多用戶組成的命名組，組里所有成員都接收寄到這個通道的消息，通
道由它的名字，屬性，目前的成員來標志。
2.1名字空間
通道的名字(由一個‘&’，‘#’，‘+’或者‘！’開頭)可以長達五十個字符。通道的
名字對大小寫敏感。
除了第一個字符必須是‘&’，‘#’，‘+’或者‘！’（今后稱作“通道前綴”）的要
求外。對通道名字的唯一限制是它不能包含任何空格（‘’）、控制符G(^G或者ASCII7)、
逗號（‘，’被協議用作列表項的分隔符）。還有，冒號（‘：’）用作通道掩碼的分隔符。
精確的通道名字語法在“IRCServerProtocol“[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命令能夠區分‘通道創建者’和通道管理員。參閱“IRCClient
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
命令在“IRCClientProtocol”[IRC-CLIENT]中定義。
4.1成員身份
此域中的模式將通道成員的昵稱作為參數并影響賦予成員的特權。
4．1．1“通道創建者”身份
模式‘0’只和“安全通道”結合使用而且不能被用戶使用。服務器用它來
給予創建通道的用戶“通道創建者”的身份。
4．1．2通道管理員地位
模式‘o’用來轉換通道成員的管理員身份。
4．1．3發言特權
模式‘v’用來給予通道成員發言特權和從成員處收回發言特權。具有這種特
權的用戶能夠在調節過的通道上交談。（參閱4.2.3部分(ModeratedChannelFlag)。
4.2通道標志
此域中的模式用來定義影響通道如何管理的屬性。
4.2.1匿名標志
通道標志‘a’定義了一個匿名通道。這意味著當一條發送到通道的消息被
服務器發送給用戶時，并且它來自用戶，那么它就要被屏蔽掉。為了屏蔽掉消息，來源被改
成“anonymous!anonymous@anonymous.”（也就是說，一個別名是“anonymous”，用戶名是
“anonymous”的用戶，來自叫做“anonymous”的主機）。因為這樣，服務器必須禁止別名
為“anonymous”的用戶。服務器不能為用戶離開這類通道而發送QUIT笑給其他通道的成員，
而是產生一條PART消息。
在以字符‘&’為前綴的通道上，這個標志也許由通道管理員轉換，但是在以字符‘！’為前
綴的通道上，這個標志只能由‘通道創建者’設定（但是不能夠不設定）。此標志在其它類型
的通道上不能夠使用。
在匿名標志已經設定的通道上，對whois,who,和names命令的答復不能夠表明通道上其他用
戶的存在。
4.2.2InviteOnly標志
當通道標志‘i’設定后，新成員只有當他們的掩碼和邀請列表相符（參見4.3.2部
分）或者他們已經被通道管理員邀請。這個標志也對通道管理員限制了INVITE命令的使用
（參見“IRCClientProtocol”[IRC-CLIENT]。
4.2.3通道已調節標志
通道標志‘m’用來控制誰可以再通道上說話。當它設定時，只有通道管理員，和
被賦予了發言特權的成員才可以向其他通道發送消息。
這個標志只影響用戶。
4.2.4不允許通道外客戶向通道發送消息
當通道標志‘n’設定時，只有通道成員才可以向通道發送消息。
這個標志只影響用戶。
4.2.5安靜通道
通道標志‘q’僅供服務器使用。設定時，它限制發送給用戶的關于通道操作的數據
類型：其他用戶加入，離開和重要的變化都不發送。從用戶的觀點來看，通道只包含一個用
戶。
這經常用于創建特別的本地通道，這種通道里服務器發送和它的操作相關的通知。它作為一
種更加有效率特富有彈性的方法可以用來取代RFC1459[IRC]里定義的用戶狀態‘s’。
4.2.6私人和秘密的通道
通道標志‘p’用來標志一個通道是私人的，通道標志‘s’用來標志一個通道是秘
密的。兩種性質很相似，他們都向其他用戶隱藏了通道的存在。
這意味著如夠不加入就沒有辦法從服務器得到通道的名字。換句話說，對whois命令這樣的
詢問的答復必須將這些通道省略掉。
當一個通道是‘秘密的’的時候，除了上面的限制外，對topic,list,names命令這樣的詢問，
服務器必須表現得象通道不存在一樣。上述規則只有一個例外：服務器會正確地答復mode
命令。最后，當<mask>參數指定時，秘密通道沒有責任回復lusers命令（參閱“InternetRelay
Chat：ClientProtocol”[IRC—CLIENT]）。
通道標志‘p’和‘s’不能同時設定。如果服務器的MODE消息設定‘p’標志而且通道已
經設定了‘s’，那么這種變化就靜靜地被忽略掉。這只有在斷連恢復期間才能發生。（在“IRC
ServerProtocol”文檔中提到）。
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網絡上的服務器使用相同的邏輯，以保證一致性和公正性?；谙?BR>同的原因，對一個給定的IRC網絡，“reop延遲”的值在所有主機上都應一致。同“通
道延遲”一樣，“reop延遲”值的設置也應該考慮很多因素，包括IRC網絡的規模，網
絡斷連通常的持續時間。
a) reop機制在“reop延遲”期滿，一段隨機時間之后被觸發。這樣可以限制此機制在
兩臺分離的服務器上同時觸發的可能性。
b) 如果通道規模很?。ㄎ鍌€用戶或者更少），并且這個通道的“通道延遲”已經期滿，
如果至少有一個成員對服務器來說是本地的話，那么就將所有用戶重設管理員。
c) 如果通道規模很?。ㄎ鍌€用戶或者更少），并且這個通道的“通道延遲”已經期
滿，“reop延遲”也已期滿。接著就將所有用戶重設管理員。
d) 對于其他情況，至多將通道上的一個成員重設管理員，以服務器的內建方法為基礎。
如果你不將一個成員重設管理員，內建方法應該就是另一個服務器極可能將某個用
戶設為管理員。這種方法在整個網絡上應該都是一樣的。一個好的啟發式方法是隨
機重設管理員。
（目前的實現實際上是試著選一個服務器的本地成員，這個成員要是沒有閑置太久
的，最終推遲行動，因此使其它服務器有機會尋找一個沒有太閑置的成員。這太復
雜了，因為服務器只知道本地用戶的閑置時間）
6．目前的問題
IRC通道管理方式有一些問題已經被認識到了。有一些能直接歸因于這篇文檔里定義的規
則，其它的是底層的“IRCServerProtocol”的結果。盡管來源于RFC1459[IRC]，這篇文檔
試著提出了一些新鮮方法解決一些已知的問題。
6.1標志
這篇文檔定義了IRC協議使用的眾多標志中的一個。盡管有許多不同的名字空間（給予通
道名字前綴），但是不允許在內部重用他們。目前，有可能不同服務器上的用戶采用相同的可
能引起沖突的標志，（只有一個服務器知道的通道除外，這里能夠防止沖突）。
6.1.1通道延遲
5.1部分描述的，由前綴是字符‘#’的通道使用的通道延遲機制（追蹤最近使用過的
通道）是一個防止沖突發生的簡單嘗試。經驗表明，在通常情況下，它非常有效；但是，很
明顯它有很多局限使它不能夠解決這里討論的問題。
6.1.2安全通道
3.2部分（安全通道）描述的“安全通道”是一個較好的防止沖突發生的方法，因為
它避免用戶對他們選擇的標志擁有完全控制。這種標志明顯的缺點是他們對用戶不友好。但
是，客戶端要改進這一點是相當繁瑣的。
6.2狀態傳播延遲
因為網絡引起的延遲，以及每個服務器都要求檢查狀態變化的正確性（比如，用戶存在
且有合適的特權），有時一條狀態信息只影響部分網絡，經常使服務器上關于通道狀態的信息
出現差異。
盡管這個毛病看起來容易改正（通過讓源服務器檢查狀態變化正確性的方法），但卻有各種理
由決定不這樣做。一種擔心是服務器彼此不能信任，這樣發生錯誤的服務器就容易檢測出來。
這樣作業防止了來自各個方向狀態信息的不同步對通道造成的巨大影響。
6.3沖突和通道狀態
“InternetRelayChat:ServerProtocol”文檔[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．目前的支持和獲取渠道
MailinglistsforIRCrelateddiscussion:
Generaldiscussion:ircd-users@irc.org
Protocoldevelopment:ircd-dev@irc.org
Softwareimplementations:
ftp://ftp.irc.org/irc/server
ftp://ftp.funet.fi/pub/unix/irc
ftp://coombs.anu.edu.au/pub/irc
Newsgroup:alt.irc
9.感謝
PartsofthisdocumentwerecopiedfromtheRFC1459[IRC]which
firstformallydocumentedtheIRCProtocol.Ithasalsobenefited
frommanyroundsofreviewandcomments.Inparticular,the
followingpeoplehavemadesignificantcontributionstothis
document:

MatthewGreen,MichaelNeumayer,VolkerPaulsen,KurtRoeckx,Vesa
Ruokonen,MagnusTjernstrom,StefanZehl.
10.參考文獻
[KEYWORDS]Bradner,S.,"KeywordsforuseinRFCstoIndicate
RequirementLevels",BCP14,RFC2119,March1997.
[IRC]Oikarinen,J.andD.Reed,"InternetRelayChat
Protocol",RFC1459,May1993.
[IRC-ARCH]Kalt,C.,"InternetRelayChat:Architecture",RFC2810,
April2000.
[IRC-CLIENT]Kalt,C.,"InternetRelayChat:ClientProtocol",RFC
2812,April2000.
[IRC-SERVER]Kalt,C.,"InternetRelayChat:ServerProtocol",RFC
2813,April2000.
11.作者地址
ChristopheKalt
99TeaneckRd,Apt#117
RidgefieldPark,NJ07660
USA

EMail:kalt@stealth.net