response - 关于 005 IRC 数字和一般 RFC 的混淆

标签 response irc rfc

在浏览了最新的 IRC RFC 之后我有点糊涂了
RFC 规定,在 5.1 部分下该响应 005 用于退回消息,
但是每当我连接到 IRC 服务器时,005 数字响应都会用于 ISUPPORT,正如它所描述的 here .
我错误地认为 RFC2812 我们是最新的吗?还是我错过了将 005 更改为 RPL_ISUPPORT 的一些附录?
我之前也发现了这个 SO question (它来自 2011 年,但比我能找到的任何文档都更新)其中 005 回复被称为“ map ”,现在这是完整的第三件事。
为了增加困惑,我发现了另一个 2011 SO 问题 here , 其中有人指出 RFC2812 不是实现的,RFC 1459应改为使用,但在 Section 6: Replies 中缺少 0-199 的回复,我无法在文档中的任何地方找到它们。
我希望有人可以帮助我了解 IRC 文档的噩梦。

最佳答案

RFC2812 及其同伴当时仅反射(reflect)了 IRCNet 上的使用情况。在 EFNet 和 IRCNet 之间“大 split ”之后,它们实际上更像是一种政治声明。他们没有反射(reflect)任何形式的社区共识,而是
试图将 IRCNet 的实践编纂为“标准”,尽管许多其他网络已经采用了围绕“TS”(时间戳)协议(protocol)的竞争实现。
RPL_BOUNCE 唯一已知的实现是在 IRCNet 的 IRCD 中——随着 005 被广泛采用来表示 RPL_ISUPPORT,并且越来越需要能够向客户端传达实现中的差异,RPL_BOUNCE 被移到了 010 数字,而 IRCNet 本身已经采用005 作为 RPL_ISUPPORT。
RPL_BOUNCE 本身就是一种反射(reflection)或 IRCNet 哲学。 IRCNet 上的服务器历来受到地理和民族主义的严格限制——例如,位于法国的服务器可能只接受来自法国和邻国的连接。过去,这是非常严格地执行的,服务器预计只为他们申请服务的有限用户群提供服务,并且在任何给定时间只允许少数“开放”服务器为没有他们所在地区的服务器。这样做的总体效果是,任何给定的用户将只有几台他们有权连接的服务器,这取决于他们的
互联网提供商和地理位置,因此“反弹”数字为受地理限制的服务器提供了一种方式来宣传另一台服务器以供用户连接。
RPL_ISUPPORT 作为 Internet Draft 提交,但由于未知的原因,没有将其移向 RFC 阶段。
在许多情况下,服务器 (ircd) 软件本身的源代码,以及偶尔包含的一些文本文件,是现代使用的唯一有意义的文档——尤其是对于现在完全非标准的服务器到服务器协议(protocol)和绑定(bind)到特定的实现。
有一些团体试图协调各种客户端-服务器扩展,例如 IRCv3 working group ,但实际上,RFC1459 仍然是最小公分母。
Postel 告诫 be conservative in what you do, be liberal in what you accept from others对于 IRC 来说尤其如此,因为客户必须应对不断增长和不断变化的实现阵列。祝你好运。

关于response - 关于 005 IRC 数字和一般 RFC 的混淆,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/23144371/

相关文章:

c# - Response.StatusCode 在 nunit 测试中为 null

c++ - MASM str 和 substr?

python - 是否可以在类中线程化子类?

ssh - diffie-hellman ssh key 交换

redirect - 如何使用 uri 将动态子域重定向到域

javascript - 为什么 XMLHttpRequest 响应的长度与请求文件的大小不同?

WCF 设计 - 一个请求和响应对象还是多个?

c# - IRC Bot 不识别服务器 - 连接挂起

http - 我的 URL 是否违反了 RFC 3986(或其他)

java - 在 java 中使用 URLDecoder 将 % 解码为空格?