Confusion about the 005 IRC numeric and general RFC

Question

After rading through the most recent IRC RFC I've gotten a bit confused, the RFC states, under section 5.1 that response 005 is used for a bounce message, but whenever I connect to an IRC server, the 005 numeric response is used for ISUPPORT, as it's described here.

Am i wrong to assume that RFC2812 us the newest? Or is there some addendum I've missed on the change of 005 to RPL_ISUPPORT?

I also found this earlier SO question (it's from 2011, but that still newer than any documentation I can find) In which the 005 reply is referred to as "map", which is a complete third thing now.

To add to the confusion I found another 2011 SO question here, in which someone points out RFC2812 is not the one implemented and that RFC 1459 should be followed instead, however in Section 6: Replies the replies from 0-199 is missing, and I'm unable to find them anywhere in the document.

I hope that someone can help shed a bit of light on the IRC documentation nightmare for me.

Answer 1

RFC2812 and its companions only reflected usage on IRCNet at the time. They were actually more of a political statement following the "great split" between EFNet and IRCNet. Rather than reflect any sort of community consensus, they sought to codify IRCNet's practices as the "standard", even as numerous other networks had adopted competing implementations around the "TS" (timestamp) protocol.

The only known implementation of RPL_BOUNCE was in IRCNet's IRCD - and following the widespread adoption of 005 to mean RPL_ISUPPORT, and it's growing necessity to be able to convey differences in implementation to clients, RPL_BOUNCE was moved to the 010 numeric, and IRCNet itself has adopted 005 as RPL_ISUPPORT.

RPL_BOUNCE was itself a reflection or IRCNet philosophy. Servers on IRCNet have historically been tightly restricted along geographic and nationalistic lines - for example, a sever based in France might only accept connections from France and neighboring countries. In the past, this was very strictly enforced, with servers expected to only serve the limited user bases with which they had applied to serve, and only a small number of "open" servers permitted at any given time for the benefit of users without a server in their area. The overall effect of this was that any given user would have only a few servers to which they were authorized to connect, based on their internet provider and geographic location, and therefore the "bounce" numeric provided a way for the geographically restricted servers to advertise another server for the user to connect to.

RPL_ISUPPORT was submitted as an Internet Draft, but for reasons unknown, there was no follow through on moving it towards the RFC stage.

In many cases, the source code of the server (ircd) software itself, and occasionally, some text files included with it, are the only meaningful documentation of modern usage - especially for server-to-server protocols, which are now completely nonstandard and tied to specific implementations.

There are some groups attempting to harmonize the various client-server extensions, such as the IRCv3 working group, but really, RFC1459 is still the least common denominator.

Postel's admonition to be conservative in what you do, be liberal in what you accept from others is especially true with respect to IRC, as clients must contend with an ever growing and ever diverging array of implementations. Good luck.