On Fri, Apr 17, 2009 at 12:52 AM, James Hess <mysidia@gmail.com> wrote:
There are no IETF standards for IRC. There are really no common written standards for IRC accepted by the internet community, only de-facto standards. The only RFC documents available describe how one of the original implementations of IRC worked, and they are outdated in many ways.
This is pretty wrong, actually. RFC1459 is still used as a basis for client-side protocols. We can mess with a few things here and there, based on the flexibility that the RFC gives us, but by and large, we try not to actually break it. Lucky for us, the RFC doesn't place a lot of limitations on things.
It would be great if a full-fleshed standard could be developed, and have the technical community consensus required for accepted, but unfortunately, for IRC, that has not happened.
This has been tried, several times. The fact is that the community is sufficiently splintered between networks and software (both client and server, not to mention different approaches to services) that nobody could agree on anything. At one point we got as far as a draft for a protocol _negotiation_ extension, that would allow us to negotiate different protocols between clients and servers, but that draft died. The only thing we managed to get out of that 18 month collaboration was the use of the 005 numeric to advertise optional features. And even that was just a vaguely defined set of key/value pairs that could safely be completely ignored by the client. I've personally come to the conclusion that the client protocol battle simply isn't worth fighting, and am concentrating on making the network and network protocols more resilient. In the context of this conversation though, altering the LIST output can be done without breaking clients. We can't do nested 'categories', but we can decide what list we send the users. -epi