CHANMODEPRIV syntax: chanmodetoken = "CHANMODEPRIV=" chantype level ":" modes [,chantype level ":" modes[,...]] chantype = character defined in CHANTYPES 005 token level = mode character defined in PREFIX 005 token modes = mode character(s) defined in CHANMODES 005 token with the addition of "+","-","*","/"
CHANMODEPRIV informs the client who can use what channel modes, and in what types of channels. I came up with the idea for this token while talking to the author of the IRC client Babbel (Robert J. C. Ivens) about him adding support for PREFIX and other tokens. He said he liked those tokens but that it would be nice if the client could know who can do things. In the original RFC1459 type IRCds, this is not necessary, the answer is simple, ops (+o) can use every mode, and no one else can. However, IRC has changed dramatically. Even on networks that don't implement any new levels, you have servers that use IRC services which have a services-only mode of +r to indicate registered channels. This feature goes back to at least Dreamforge. So even back then there were already things that ops couldn't do. More recently things have gotten even a bit more complex with the addition of halfops. Halfops is not always implemented the same way on all networks. On some networks for example, Halfops have the ability to give/take halfop status from another user, on some networks they don't. There are also some networks that added an addition to allow voiced (+v) users to set -v on users. These are clearly deviations from the way a client is going to expect IRC servers to act. So you're probably wondering, why exactly does a client need this information? Other than simply it's nice to know what you have access to, it can be used to control some client features. For example, since the proposed CHANMODEPRIV allows CHANTYPE specific configuration, a client could be made aware that internal features (say flood kick/banning) shouldn't be triggered in +channels (modeless) to avoid an error. CHANTYPES tells you that +channels are supported, but it doesn't tell you whether they are modeless or not. Additionally, clients (I'm mainly familiar with mIRC so I'll use that as my reference) have "channel central" features. Where they generally have checkboxes indicating modes that can be set. If you are not +o, these checkboxes are usually disabled (greyed out). Now some clients are smart enough that +h users do not have the checkboxes greyed out, but since halfops are a non-standard extension, it is very possible that only some or even none of the channel modes are actually available to the +h user on a particular implementation. Also, while halfops may be "standard enough" to include adding a method to specially support non-greyed checkboxes for halfops, other modes are not. Clients may also be smart enough to realize things that are in PREFIX and listed as higher precedence (to the left of) +o should also have mode changing access, but what about other levels? For example if I made a level that is lower than +h but higher than +v, does this level have mode changing access? There really is no way to make such an assumption with the current implementation. The CHANMODEPRIV numeric 005 token attempts to correct these problems and others. A brief explanation of the syntax of CHANMODEPRIV gives a bit more insight into how it will work. The chantype part is a character that must be mentioned in the CHANTYPES token. This defines which type of channel the given set of modes will apply to. The level parameter defines the level, defined by the mode character specified in the PREFIX token, the given mode set refers to. The modes are a little bit deceiving as they do not function as a standard normal mode string, that is the use of the + and - characters does not distribute to all modes following that character and preceeding the next + or - character. The + or - character only applys to the mode it immediately preceeds. The purpose of this is to try and keep the size of the token's string at a minimum. If a mode character is preceeded by a + it means that the given level (on the given chantype) only has access to set that mode. Similarly, if it is prefixed with a - then it means the given level (on the given chantype) only has access to unset the mode character it preceeds. Additionally, two other flags are introduced that act similarly to + and -. TO keep with the idea of mathmatical symbols, I have chosen * and /. The * character means "set on me" and the / character means "unset on me". This is designed to take into account the IRCds that allow users, for example, who are +v to set -v, but not on anyone, just on themselves. If * is specified it means the given level (on the given chantype) can only set this mode him him/herself, and if / is specified it means the inverse, that is the user can only unset it on him/herself. And just a note, to my knowledge, no IRCds have any modes that a user can set on him/herself without being able to unset it as well, but since the opposite does exist, in the interest of completeness and expandability it seems like a good idea to include the possibility that such a feature may be used sometime in the future. In order to add this token and try and maintain a reasonable degree of backwards compatibility there are some assumptions that I believe are consistent with the way current clients work and try to adhere to RFC1459 as much as possible. These assumptions make use of the requirment levels defined by RFC2119. The first assumption is if the server does not specify a CHANMODEPRIV, the client SHOULD assume +o users, and any higher levels as defined by PREFIX (if present), have the ability to set and unset all modes. The client MAY assume that +h users have the ability to change modes. The client SHOULD NOT assume clients below halfops have the ability to change any modes. The client MAY make any inferences about the type of channels if CHANMODEPRIV is not present, i.e., that +channels do not allow any users to change modes, however the client SHOULD NOT make any assumptions about channel types other than "#" "&" (defined in RFC1549), and "+" "!" (defined in RFC2811). There is still one issue that arrises that I've yet to come up with a good solution for, and it is for modes that require a specific usermode (not "channel userlevel", a regular usermode), to set. For example some servers now have a +O mode to indicate an IRCOp only channel. Obviously such a mode would not make sense if people other than IRC Operators could set such a mode. If anyone has any suggestions on how such a problem could be addressed, I'd certainly be happy to listen. Also one note, this token deviates from the Internet Draft draft-brocklesby-irc-isupport-02 in one known respect. This draft states that the value of a numeric 005 token (the part after the "=") may not exceed 20 characters. It is worthy to point out however that this document is a work in progress and it is my belief that this is more a problem with the isupport draft than it is with CHANMODEPRIV. The reason I regard this as a flaw in the draft is it can cause problems. The one coming to mind is with the CHANMODES token. RFC1459 does not specify any limit on the number of channel modes that may exist, as a result some IRCds have more than 17 channel modes (only 17 are needed to exceed the 20 character limit due to the 3 commas). To allow for compatibility it would seem that the number of characters allowed as per that draft should be increased. Examples: CHANMODEPRIV=#o:tomlipskvn,&o:tomlipskvn Allows ops to set +/-tomlipskvn on # and & channels but not on others (ie +). CHANMODEPRIV=#o:tomlipskhvn,#h:+htmlipskvn Allows ops to set +/-tomlipskhvn on # channels and halfops to set +h and +/-tmlipskvn on # channels CHANMODEPRIV=#o:tomlipskvn,#v:/v Allows ops to set +/-tomlipskvn on # channels and voices to set -v on # channels (but only on him/herself). I am certainly looking for comments and suggestions about this token, and I hope people will consider it to be useful.
