There is any number of mutually incompatible servers out there, and I don't know of any of them that sticks to just the RFC's. The RFC specifies the wire format and basic messages relatively ok, but most IRC networks also rely on a variety of additional services that are largely unspecified.

The RFC you refer to is (one of several - it also includes at least 2810, 2811, 2813) retroactive attempt at untangling the gigantic mess of hack upon hack added by a variety of servers over the years since the original IRC RFC, because nobody relied on just the original RFC any more.

See sections 6 and 7 in particular - they did not even try to address the variety of extensions or compatibility beyond the reference implementation, which pretty much nobody used any more by the late 90's.

E.g. consider where in the RFC it says something about colour support in messages. It doesn't - that was a proprietary extension added by mIRC [1] that everyone then just adopted. As a result clients that implement the RFC and assumes they'll just get readable text will end up displaying control characters to users, like many clients id for years.

These RFC's also don't specify CTCP at all [2] (used for DCC and the like), which leaves you with a woefully incomplete client.

Here is another example of servers (EFNet in this case) deviating, by providing it's own timestamping mechanism [3].

The reality is that if you implement the RFCs you're only halfway there for a client, and may not even be able to talk to the network you want if you're writing a server (most networks won't let you use the server of your choice anyway). Client-to-server compatibility is better than server to server compatibility, but still requires a lot more than the RFCs to provide the functionality users expects.

It's true that you can mostly deal with this "manually". E.g mIRC colour codes does not require server side changes, and some clients could handle them just with macros, but that's less forethought and clean design and more a matter of the fact that IRC mostly just spews out to users what you pass in, and a whole lot of the reason server-to-server compatibility is so poor is that each major network has done a lot of independent work to work around the various abusive mechanisms people have come up with to take advantage of the woefully underspecified semantics.

The result is that, yes, you can handle a lot of services client side because IRC users are used to tolerating clients that show them control codes and the like if another client has added additional functionality that theirs doesn't support. Like mIRC color codes, which means messages includes ASCII 0x03 (^C) followed by colour codes, which will be visible noise on clients that doesn't support it, with no mechanisms for negotiating features.

To me that is a massive mess, that still has not been cleaned up, and likely never will be, because all current clients have papered over all the ugly cracks over the years.

Source: Written code to interface to IRC on and off since 1994.

[1] http://www.mirc.com/colors.html

[2] Here is EFNets document on CTCP: http://www.efnet.org/?module=docs&doc=8

[3] http://www.efnet.org/?module=docs&doc=19