rfc2811.txt

很多RFC的中文文档

户。
这经常用于创建特别的本地通道，这种通道里服务器发送和它的操作相关的通知。它作为一
种更加有效率特富有弹性的方法可以用来取代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: [e-mail]
       Protocol development: [e-mail]
     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: [e-mail]

RFC2811—Internet relay chat:client protocol                 Internet延迟交谈：通道管理


1
RFC文档中文翻译计划