While there is not much use in bringing this up for certain individuals on this list which still think the aging RFC is worth anything to any of the major networks, IRC is changing and belive it or not, its really not that difficult to support the wide varity of channel modes or channel access modes out there. mIRC does it, and have done for some time.
Undernet supports the 005 numeric in reporting both channel access prefixes and channelmodes. And as all IRCd's it also reports the channelmodes the server supports and also tells the connecting client how to interpret the various channel modes: <<Server>> washington.dc.us.undernet.org u2.10.10.pl20.(release) dioswkg biklmnopstv <<Server>> SILENCE=15 WHOX WALLCHOPS USERIP CPRIVMSG CNOTICE MODES=6 MAXCHANNELS=10 MAXBANS=30 NICKLEN=9 TOPICLEN=160 KICKLEN=160 CHANTYPES=+#& :are supported by this server <<Server>> PREFIX=(ov)@+ CHANMODES=b,k,l,imnpst CHARSET=rfc1459 NETWORK=Undernet :are supported by this server EFnet supports this, and even introduce the by now well known HalfOp in the next server release (7.0) <<Server>> irc.theflux.no 2.8/hybrid-6.3 oOiwszcrkfydnxb biklmnopstve <<Server>> WALLCHOPS PREFIX=(ov)@+ CHANTYPES=#& MAXCHANNELS=20 MAXBANS=25 NICKLEN=9 TOPICLEN=120 KICKLEN=90 NETWORK=Hybnet CHANMODES=be,k,l,imnpst EXCEPTS KNOCK MODES=4 :are supported by this server IRCNet supports this: <<Server>> irc.powertech.no 2.10.3p3+hemp+r aoOirw abeiIklmnoOpqrstv <<Server>> MAP PREFIX=(ov)@+ MODES=3 CHANTYPES=#&!+ MAXCHANNELS=10 NICKLEN=9 TOPICLEN=160 KICKLEN=160 NETWORK=IRCNet CHANMODES=beI,k,l,imnpsaqr :are supported by this server DALnet supports this: <<Server>> pizza-e.ca.us.dal.net bahamut-1.4(34).rhashfix oiwscrknfydaAbghe biklLmMnoprRstvc <<Server>> NOQUIT WATCH=128 SAFELIST MODES=13 MAXCHANNELS=10 MAXBANS=100 NICKLEN=30 TOPICLEN=307 KICKLEN=307 CHANTYPES=&# PREFIX=(ov)@+ NETWORK=DALnet SILENCE=10 CASEMAPPING=ascii :are available on this server UnrealIRCd, and the countless of networks using it, supports this. Dont take my word for it, go see http://irc.netsplit.de/networks/daemons.var <<Server>> irc.moocows.dk Unreal3.2-Selene[beta11] iowghraAsORVSxNCWqBzvdHtG lvhopsmntikrRcaqOALQbSeKVfHCuzN <<Server>> MAP KNOCK SAFELIST HCN MAXCHANNELS=10 MAXBANS=60 NICKLEN=30 TOPICLEN=307 KICKLEN=307 MAXTARGETS=20 AWAYLEN=307 :are supported by this server <<Server>> WALLCHOPS WATCH=128 SILENCE=5 MODES=13 CHANTYPES=# PREFIX=(ohv)@%+ CHANMODES=ohvbeqa,kfL,l,psmntirRcOAQKVHGCuzN NETWORK=IRCsystems :are supported by this server This is how the CHANMODES and PREFIX are parsed by mIRC to allow it to support more or less anything that is thrown at them: 37.mIRC now supports the numeric 005 tokens: CHANTYPES=# and PREFIX=(ohv)@%+ and can handle a dynamic set of channel and nick prefixes. mIRC assumes that @ is supported on all networks, any mode left of @ is assumed to have at least equal power to @, and any mode right of @ has less power. mIRC has internal support for @%+ modes. $nick() can now handle all mode letters listed in PREFIX. Also added support for CHANMODES=A,B,C,D token (not currently supported by any servers), which lists all modes supported by a channel, where: A = modes that take a parameter, and add or remove nicks or addresses to a list, such as +bIe for the ban, invite, and exception lists. B = modes that change channel settings, but which take a parameter when they are set and unset, such as +k key, and -k key. C = modes that change channel settings, but which take a parameter only when they are set, such as +l N, and -l. D = modes that change channel settings, such as +imnpst and take no parameters. All unknown/unlisted modes are treated as type D. When not connected to a server, mIRC uses default values of CHANTYPES=#& PREFIX=(ohv)@%+ CHANMODES=bIe,k,l Also added identifiers $chantypes $prefix $chanmodes. Notes: 1. mIRC doesn't support @ or $ as a channel prefix, or $ as a nickname prefix, these are used internally by mIRC. 2. Ircd coders should be aware that prefixes can change the way an IRC client behaves. eg. If a server uses the same prefixes for channels and nicknames, this could cause certain features in mIRC to behave oddly, eg. scripts, hotlinks, tab completion, etc. which, depending on the prefix, provide a different behaviour or interface in non-context situations. Now, fine.. continue arguing that its in violation of the RFC which no one on this planet actually follow anymore. There are however users of AmIRC out there which wouldnt mind seeing their client being able to handle how IRC actually work today, and the major IRCd coding teams have worked out a way to make easy to support for client authors. All im trying to point out here is that its possible to do, the tool the client need to support this is there. There wont be any updated RFC anytime soon, not to mention that the RFC in question isnt even a finalized protocol, its an experimental protocol so refering to it as a standard can be argued. Anyways, just a tired rant. I still have my AmIRC 3.0 key, although i was driven away from AmIRC due to the lack of support for even outputting mode changes sent from the server properly, making it impossible to see when users where given halfop status for example. Flames may be directed to /dev/null, the world isnt black and white.. and the RFC some people hold to be the bible isnt being followed by a single major IRC network apart from the most basic client <-> server protocol. -- Yours Sincerely Thomas Juberg Stens�s -- What we do in life echoes in eternity ___________________________________________________________________ AmIRC Mailing List - http://www.vapor.com/amirc/ AmIRC FAQ......: http://faq.vapor.com/amirc/ Listserver Help: mailto:[EMAIL PROTECTED]?Subject=HELP Unsubscribe....: mailto:[EMAIL PROTECTED]?Subject=UNSUBSCRIBE
