Internet Relay Chat
specifications
Lots of behaviour in the IRC protocol as implemented in clients and servers today is not formally specified. If you are looking to implement IRC software, the best thing to do is look at specifications, information, and how other software behaves as a guide.
Useful Specifications
The Modern IRC documents describe the IRC client protocol, formatting, and other related tech. The primary document on this site is an updated replacement to RFCs 1459 and 2812.
These docs don't specify new stuff, just existing behaviour and what I consider best-practices for new software. I intend for them to help improve interoperability with the wider IRC ecosystem, and provide a good starting-point on the base protocol for new implementations.
Full disclosure: I'm an author and/or editor on most of the Modern specs.
The earlier and the later 'canonical' IRC specifications, respectively.
Some software holds RFC1459 in higher regard than RFC2812, and some hold the opposite in higher regard. Honestly, the truth tends to lie somewhere in the middle.
There are many parts of the newer RFC2812 that software authors (reasonably) consider insane. And there are many parts that have updated RFC1459 in useful ways and have been widely-implemented by clients and servers today.
In the same way, RFC1459 has many useful parts, and there are also many places where due to its age or simply deviating implementations, it also has information that's totally incorrect.
Honestly, use these as a rough reference, say for a basic implementation. And then compare everything with multiple real-world servers and clients to find out how broken and incompatible your to-the-spec implementation is with the actual ones out there today.
If you're looking at these, it's worth taking a look at the Modern IRC docs which I'm writing up. The main doc there acts essentially as a replacement to these two, but is still very, very much a work in progress.
Do not take RFC 1459 or 2812 of these original specifications as gospel. They are both very old, and have lots of places where either due to age or decision, modern software specifically does not follow them.
Welcome to IRC, where the base specs we work off are all old and broken and regarded more as suggestions than anything binding. Strap in and "Thanks for flying IRC!"
6697 is IRC's TLS port. It's now in an RFC. Hooray.
This also specifies some details about certificates that are useful to keep in mind, and some bits about certificates that isn't really true these days.
Every server implements this. This is mandatory for any client implementing any sort of intelligence. The RPL_ISUPPORT numeric is implemented by literally everything.
The original RPL_ISUPPORT specs are old and describe keys which are no longer used today. This one describes the widely-used parameters that clients and servers SHOULD implement. There is also the RPL_ISUPPORT Token list I maintain over on my irc-defs page
Full disclosure: I wrote on the spec I'm linking here. The original spec people tend to refer to is the RPL_ISUPPORT Hardy Internet-Draft.
This is a working group made up of a whole bunch of IRC software authors. IRCv3 specifications are written by various software authors, submitted, and accepted if the majority of the group agrees on them. These are recommended and tend to introduce new and useful features to the IRC protocol.
Regarding specific IRCv3 specifications, here are rough support matrixes for clients and servers.
CTCP is the Client-to-Client Protocol. Supported by a large amount of software, it allows for special messages to be exchanged between clients. Very useful, and clients need to implement certain parts of it.
The original CTCP specifications required insanely extensive quoting mechanisms which didn't end up getting supported and/or got explicitly rejected by the clients out there today. As such, I've linked a newer, lean CTCP specification which describes just the parts that are generally useful to clients today.
Full disclosure: I'm the editor of the spec I'm linking here.
Like the canonical RFCs, this is an old document. Like the RPL_ISUPPORT draft, not everything in here is parsed by clients.
However, it is the best document describing the irc and related URL schemes around today. Clients should largely implement this document when implementing parsing for the IRC URL schemes (within reason, for instance use 6697 as the default for ircs URLs these days).
The WEBIRC command is widely used in the implementation of web-based IRC clients in connecting to IRCds. Only privileged hosts can use this command, since WEBIRC lets the client sending it to set the hostname/IP address of the current connection.
This specification is one done up with the IRCv3 WG that basically describes how it works today. It's WiP but should be pretty accurate.
DCC/XDCC
DCC stands for Direct Client-to-Client. XDCC is an extension which stands for Xabi's DCC (widely referred to as Extended DCC these days). These protocols allow for traffic to be exchanged directly between clients (again, with a number of caveats). Proposed uses for this have also included 'whiteboards' and direct chatting. However, these days DCC/XDCC is primarily used for file exchange between clients. DCC file transfers don't use any sort of encryption, and as such… I'd recommend building something better these days.
I haven't linked any specs here because there are a bunch of differing, old specifications. It's difficult to point to one as authoritative without combing through all of them to see how closely they're followed these days. However, I've been writing up this very work-in-progress one that may be useful (but doesn't describe everything or all the extensions yet).