通过最近的IRC RFC rading后，我已经得到了一个有点糊涂， 的RFC规定，根据第5.1该响应005被用于退回邮件， 但每当我连接到IRC服务器，005数字响应用于ISUPPORT，如here所述。混淆的005 IRC数字和通用RFC
我错了，假设RFC2812我们是最新的？或者是否有一些附录我错过了005到RPL_ISUPPORT的更改？
我之前也发现这个SO question（它是从2011年开始的，但比我能找到的任何文档还要新）其中005回复被称为“地图”，这是现在完成的第三件事。
要添加到我发现了另一个2011 SO质疑here的混乱，其中有人指出RFC2812未实现的一个和RFC 1459应当遵循替代，但是在Section 6: Replies从0-199的答复丢失，和我无法在文档的任何位置找到它们。
我希望有人能够帮助我了解IRC文档噩梦。
RFC2812及其同伴仅反映当时在IRCNet上的使用情况。在EFNet和IRCNet之间“大分裂”之后，它们实际上是更多的政治声明。尽管许多其他网络采用了围绕“TS”（时间戳）协议的竞争实施方式，但它们并没有反映任何类型的社区共识，而是试图将IRCNet的实践作为“标准”进行编码。
RPL_BOUNCE的唯一已知实现是在IRCNet的IRCD中 - 并且随着005被广泛采用以表示RPL_ISUPPORT，并且越来越需要能够将实现中的差异传达给客户端，RPL_BOUNCE已移至010数字，并且IRCNet本身已采用005作为RPL_ISUPPORT。
RPL_BOUNCE本身就是一种反思或IRCNet哲学。 IRCNet上的服务器历来受到地理和民族主义线路的严格限制 - 例如，位于法国的服务器可能只接受来自法国和邻国的连接。在过去，这是非常严格的执行，服务器预计只服务于他们申请服务的有限用户群，并且在任何给定时间只有少量的“开放”服务器允许没有服务器在他们的地区。这样做的总体效果是，任何给定的用户只有几个他们被授权连接的服务器，基于他们的 互联网提供商和地理位置，因此“反弹”数字为受地理限制的服务器提供了一种方式通知另一台服务器供用户连接。
RPL_ISUPPORT作为Internet Draft提交，但由于未知原因，没有将其移至RFC阶段。
在许多情况下，服务器（ircd）软件本身的源代码以及偶尔包含的一些文本文件是现代使用的唯一有意义的文档 - 尤其是服务器到服务器协议，它们是现在完全不标准并且与特定的实现相关联。
有一些组织试图协调各种客户端 - 服务器扩展，例如IRCv3 working group，但实际上，RFC1459仍然是最不常见的分母。
Postel对be conservative in what you do, be liberal in what you accept from others的告诫在IRC方面尤其如此，因为客户必须面对不断增长且日益分化的实施方式。祝你好运。
事实上，除了RFC 1459，没有全局文档。
最好的办法就是看看某个IRCd是如何使用它的，看看你是否可以在其他IRC上解释。
问题是，经过太多的分叉，分裂，重新实施之后，没有中央权威机构来定义以何种方式使用什么。
真的，使用这些实现作为参考。如果您选择实施符合RFC的行为，您通常会遇到一些问题，例如eggdrop具有RFC兼容的CTCP支持，允许用户规避“无CTCP”信道模式。
另外需要注意的是，服务器 - 服务器协议已经比客户机 - 服务器协议更分散了。为了网络政策和统一性，大多数网络都要求制定具体的IRCD，而且这些网络通常会根据其政策分发IRCD以实施其他功能。因此，不同IRCD代码库之间的协议级兼容性并不常见，而且IRCD所使用的协议通常故意与其他IRCD（包括相同代码库的旧版本）不兼容，以防止网络失步。 – Stephanie