New RFCs for IRC!
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.


I'm trying to write an update to the outdated RFC 1459 and RFC 2812 specifications.

Newest builds are available here:

The 'drafts' in this repo are based off my Modern docs. This repo can pretty much be considered 'on hold' until the relevant Modern documents are stable and complete enough for me to be happy with. Recent updates in this repo are just an attempt to prove that the tech works, not to actually start work in this repo.

If you'd like to contribute, please take a look at the Modern docs and contribute in the relevant Github repo.


RFC 1459 and RFC 2812 are the first place that new IRC software authors look when they want to implement IRC. And why wouldn't they – those are the latest RFCs for it!

However, IRC has changed a lot since those specs were published. Today, there are many different documents that you need to look at to fully understand how the protocol works in practice. I've got a page here that tries to go through the useful ones, and this living specification which attempts to produce a workable spec to use day-to-day.

However, having an updated specification that's gone through the IETF process and is a proper RFC would:

  • Help us standardise the defacto solutions that have been in use for years, and prevent fragmentation from those by newer software.
  • Give people a better core standard which they can refer to, which is an RFC and describes the protocol as it really works.

These documents don't describe things that will be, or things that should happen after the spec is published. These documents describe how things work right now in specific detail.


I'm going to split this into a few separate documents, each describing a separate part of IRC as it stands today. Here, I'll go through what each one covers, what it explicitly doesn't, and the status of it.

Client Protocol

This is the big one, the replacement for RFC 1459 and RFC 2812 on the whole. It'll include:

  • Core client protocol.
  • Client Capability Negotiation.
  • SASL Authentication.
  • Message Tags.

This document is being actively worked on as the main Modern Client Protocol Doc. I'm not working on the client protocol spec here until that linked Modern document is at a point where I'm relatively happy removing the WIP tag from it.

HTML / Text

Client-to-Client Protocol (CTCP)

This describes how CTCP works today, ignoring a lot of the quoting that was specified in older documents but not actually implemented by any widely-used clients. It describes:

  • Core CTCP protocol.
  • Commonly-used or seen CTCP messages.

I'm working on this document currently, most of that work being copyediting and editing in general. I'm thinking about using this as a 'test bed' for seeing how I can go getting clients to look over and validate it, and for seeing how the IETF responds to IRC specifications.

HTML / Text

S2S Note

The server to server protocol is explicitly not being covered here.

RFC 2812 says the following: "At the time of writing, the only current implementation of this protocol is the IRC server, version 2.10". Today, that's not the case. You have lots and lots of different IRCds, and lots of different server protocols in use because of it. TS6, a bunch of custom TS6 flavours, TS5, P10, InspIRCd's protocol. We're primarily aiming to document and specify what is being used today, and there simply isn't a single server protocol in use today.

Especially given that there are servers (and competing IRC protocol efforts) experimenting with topologies other than the standard spanning-tree, and even their own newly-designed protocols between servers, I don't think it makes sense to try to specify a new version of the server protocol at this point. I think it's best to leave this to server authors themselves and relevant server spec documents sometime later as the technology grows and experiments, as what we specify would probably just be ignored or quickly become irrelevant.


To build this, install kramdown-rfc2629 and then use the script. That script will put the xml, txt and html files in the dist/ directory.

As noted below, when submitting changes, only include the source file changes. Don't include the newly-built dist/ changes. This helps when merging and resolving conflicts.


When putting in a pull request, ONLY submit a change for the source files. DO NOT include rebuilding the dist/ files in your pull request. This is to prevent a million conflicts if we have three PRs sitting in the waiting queue and try to merge all of them at once (particularly the .txt files). We can generate new dist/ files after we merge things into the repo.

NOTE: lib/addstyle.sed and lib/style.css have been taken from Martin Thompson's I-D Template repository.


Regardless of how this spec goes, the Modern docs are online, go through everything here and are updated more often than the material here.