经过最近的IRC RFC后，我感到有些困惑， RFC规定，在5.1部分下，响应005用于退回邮件， 但每当我连接到IRC服务器时，005数字响应用于ISUPPORT，因为它描述了here。
我错误地认为RFC2812是最新的？或者我是否因为将005更改为RPL_ISUPPORT而错过了一些附录？
我之前也发现了这个SO question（它来自2011年，但仍然比我能找到的任何文档更新）其中005的回复被称为＆＃34; map＆＃34 ;，现在已经完成了第三件事。
为了增加混乱，我发现另一个2011年SO问题here，其中某人指出RFC2812不是已实施的问题而应该遵循RFC 1459，但在Section 6: Replies中缺少0-199的回复，我无法在文档的任何位置找到它们。
我希望有人可以为我提供一些关于IRC文档噩梦的消息。
答案 0 :(得分：6)
RFC2812及其随附版本仅反映了当时IRCNet的使用情况。他们实际上更像是一个政治声明之后的＆＃34;伟大的分裂＆＃34; EFNet和IRCNet之间。他们并没有反映任何形式的社区共识 我们试图将IRCNet的实践编纂为＆＃34;标准＆＃34;，尽管许多其他网络采用围绕＆＃34; TS＆＃34; （时间戳）协议。
唯一已知的RPL_BOUNCE实施是在IRCNet的IRCD中 - 随着005的广泛采用意味着RPL_ISUPPORT，并且越来越有必要能够向客户传达实施方面的差异，RPL_BOUNCE是移动到010数字，IRCNet本身已采用005作为RPL_ISUPPORT。
RPL_BOUNCE本身就是一种反思或IRCNet理念。历史上，IRCNet上的服务器在地理和民族主义方面受到严格限制 - 例如，位于法国的服务器可能只接受来自法国和邻国的连接。在过去，这是非常严格的执行，服务器预计只服务于他们申请服务的有限用户群，并且只有少数＆＃34; open＆＃34;在任何给定时间允许服务器，以便在没有服务器的用户的利益。这样做的总体效果是任何给定的用户只有几台服务器，根据他们的要求，他们有权连接这些服务器 互联网提供商和地理位置，因此＆＃34;反弹＆＃34; numeric为地理位置受限的服务器提供了一种方式，可以通告另一台服务器供用户连接。
RPL_ISUPPORT以Internet Draft的形式提交，但由于未知原因，没有将其移至RFC阶段。
在许多情况下，服务器（ircd）软件本身的源代码，以及偶尔包含的一些文本文件，是现代使用的唯一有意义的文档 - 特别是对于服务器到服务器协议，现在是完全不标准并与特定实现相关联。
有些小组试图协调各种客户端 - 服务器扩展，例如IRCv3 working group，但实际上，RFC1459仍然是最不常见的分母。
对于IRC来说，Postel对be conservative in what you do, be liberal in what you accept from others的忠告尤其如此，因为客户必须应对不断增长且不断变化的一系列实施。祝你好运。答案 1 :(得分：1)
实际上，除了RFC 1459之外，没有全球文档。
您最好的选择是查看某个IRCd如何使用它，看看您是否可以在其他IRCds上解释您的解释。
问题在于，在太多的分叉，分裂，重新实现之后，没有中心权限来定义以何种方式使用的内容。
真的，使用实现作为参考。如果您选择实施符合RFC的行为，通常会遇到一些问题，例如： eggdrop具有符合RFC标准的CTCP支持，允许用户规避＆＃34;没有CTCP＆＃34;频道模式。