As others may have said, it makes no sense why you cannot make out the default features of a network from the network name. Like we use PHP to find $_GET variables, we should really use $network to find the NETWORK= from VERSION replies. It makes no sense to try and extend the protocol further using an extra variable here and there when there are so many revisions of the IRC protocol around now. I could list a whole heap of them now, and I doubt if the developers of any of them will want to bother coding in a SERVICES argument. I can give an appropriate example where SERVICES is inappropriate (nicely said Deme!):
In terms of services that use ChanServ-genre network services, we find that there are many varients of the software. We have IRCServices, Epona, and Anope which has an extra service, HostServ. They are practically the same by architecture, but to force clients to react to different irc environment settings is a little difficult on the behalf of the scripter - not only does it limit the amount of space a developer of a services pseudoserver has to create features, but it could probably also make it difficult for us to create bindings for all the different types.
Its time we admitted that IRC isnt as basic as it used to be - it has become more diverse, the protocol has had many facelifts in different facets thanks to open source. Lets stick to the basics and keep thinking - I just think adding SERVICES= is a lazy move to stop trying to be diverse in our own scripting techniques :P
The Illusion...
