Make a new/updated base IRC RFC
Right now, there are a bunch of different specs IRC authors need to pull stuff from when implementing clients and servers. RFC1459 got outdated, RFC2812 and the related family of RFCs have always been contentious, with things defined within that never became standard practice, the best we got for ISUPPORT was an Internet Draft.
Basically put, it's become standard practice to implement most of some RFCs, some of others, and to rely on Internet Drafts as things have changed over the years. For people implementing new software, it's almost impossible to understand what to implement and what to ignore without having to look at what the few biggest servers do and copying from there, since you can't rely on the documents.
So we should make a new base IRC RFC. Something that actually reflects reality these days, and defines things that have become commonplace like ISUPPORT. A specification authors can actually use to implement servers and clients properly.
@M2Ys4U has done some work in this direction in this repo. We could start off from there and push it to the IRCv3 org, create something from scratch (likely based off RFC1459), whatever works best.
Updated base documentation would most likely come after the finalization of JSON transport and other big changes, since many current conventions could change drastically (e.g., CTCP ACTION or numerics).
Only the 3.2 core protocol should be RFCized, the extensions evolve too quickly to bother with RFC workflow. So this is basically, the relevant parts of RFC1459 plus the core of CAP and maybe MONITOR, and ISUPPORT.
I was thinking the same as @kaniini. Just something that describes what we have today, an update for RFC1459 with the 3.2 core protocol and other core things that have been created/changed (and actually widely implemented) since the original RFCs.
We don't wanna try to change things with this – that's what ircv3-specifications is for. I think we just wanna try to make a standard that's actually up-to-date and useful for people working on IRC today. Something to clean up the mess of half the implementers using RFC1459, half using RFC2812, along with a grab-bag of other documents.
Where we wind up then, is 3.1 with some of the corrections from 3.2, and the 3.2 wire format, as well as ISUPPORT and MONITOR.
Although CTCP/DCC is an informal thing, the RFC should not discuss it. We do not want to send people down the path of implementing those things since we plan to replace them anyway. The RFC should also provide a pointer to the ircv3 repositories for extensions.
The RFC should be submitted as an ISE queue submission to the RFC editor because we operate independently from IETF/IESG.
That's what I was thinking, a decent base we can build all the new IRCv3 stuff on top of. 3.2 wire format as in with message tags?
Right. But not the specific tags themselves.
Rather than writing a RFC I think we would be better off having a complete specification for all of Modern IRC™ on ircv3.org which people can refer to. Dealing with the IETF's bureaucracy seems like a waste of our time.
I can go either way about getting the IETF to sign it off. Just a nice, clean document to base things off rather than having to look back on a few different, outdated RFCs would make me happy.
The advantage to getting the IETF to sign off on a base spec is that they would deprecate 1459 and 2810-2813 in the process. However, one could argue that Richard Hartmann's RFC already somewhat did that.
It'd be good to get the IETF sign off, and the doc'd probably be very similar to RFC style anyway. The only thing that puts me off is seeing the various IRC IDs that have been abandoned over the years.
We could do something like this?
Keep our options open, make it simple to look at publishing to an RFC later on if we want, and just worry about putting it on the website for now? (since the Pandoc files are already basically Markdown, should be super simple to write a basic shell script that just makes the compiled doc with required yaml front-matter, once we have the website up and running)
edit: I'm working on with this now. Will post / put it online when I have something significant to show (likely after 3.2, I don't wanna stifle work on getting that out the door).
@kaniini has one here: http://github.com/kaniini/ircv3-harmony / html / text
And I have one here: https://github.com/DanielOaks/ircv3-rfc / html / text Very unfinished, probably some insane stuff in there right now. Take with a grain of salt.
edit: I have a related project available here: http://modern.ircdocs.horse/