Forums Feature Suggestions More precise recognition of mode on user

I hesitated which forum to post my request, here or "bug" section, but eventually came here as my request is about non-standard things.

I'm developing an IRC server for Windows, called DICE, and it has mode +d/-d, and it applies not to channel, but to a user in the same manner as +o/-o or +v/-v. +d/+o/+v are mutually exclusive.
It's not a problem mIRC doesn't add something like @ or + to nicks of those with +d, but mIRC takes it wrong and adds +d to the title bar of a channel window. If your channel is "+im" and once some op does
/mode #chan +d FooUser
the title bar of the channel changes to "+dim".

Other IRC clients I tested don't make this mistake. I suppose it's easy to implement function to check whether /mode command operand is channel or user, therefore I request this enhancement or small fix.

Have you specified mode d correctly in the CHANMODES token of raw 005?

>Have you specified mode d correctly in the CHANMODES token of raw 005?

No, not at all now, but maybe in near future. What "correctly" means?
I know CHANMODES is in
http://www.ietf.org/internet-drafts/draft-brocklesby-irc-isupport-01.txt
http://www.irc.org/tech_docs/005.html
but they are draft, not standard, at this time, though I don't like IRC RFC not much either.
Rather, I'd like to suggest here what *mIRC can* programatically, as default behaviour.

Your mode is unknown to mIRC. It's not in 'default' chanmodes (bIe,k,l) nor in your 005 numeric (RPL_PROTOCTL or RPL_ISUPPORT).
Just read section 3.3 in the first link you posted or take a look at the current implementations in onther IRCds, like Unreal or Ultimate.

Whether it's an official standard or not, CHANMODES is the adopted standard supported by all modern IRCd's and clients. If you don't use CHANMODES then how would mIRC 'know' that mode d takes a parameter? Things like that can't (and shouldn't) be hard-coded into mIRC for every version of every IRCd - which is why CHANMODES exists.

starbucks_mafia:
In real world, there are non-standard, or ambiguous way, and I thought mIRC was such a robust tool that can guess and choose best possible interpretation. it's unexpected for me that mIRC took behaviour like that.

On servers without 005, it's natural to guess it's not channel when parameter doesn't have channel prefix defined in RFC. I agree if you say it's too trivial point to enhance, but it's job for programmer to expect all unexpected things and add extra security. I don't think it causes considerable degradation in performance to check #/&/!/+ prefix in parameter. In current implementation of mIRC, it blindly adds all those are not +o/+v to title bar of channel window when there are no CHANMODES - yes it's hardcoded, +o/+v, in mIRC as you know. So I 'd like to suggest adding some elaboration to it. Oh I'll add 005 to my server pretty soon to make it modern, thank you for advice

MonoSex:
Then when 'd' is not in 'default' chanmodes, why mIRC interpret it as channel mode? Adding it into title bar of channel window is wrong, you will say, so you have the same opinion as me, don't you?

I disagree. The "best possible interpretation" imo is mirc being consistent, ie behave the same way in every case. If you read item 37 of v5.9 versions.txt (you can get the full versions.txt from here) you'll notice the line:

All unknown/unlisted modes are treated as type D.

Obviously, unknown modes are deliberately considered type D. Before you disagree with Khaled's decision on this, consider this example: I make an ircd that supports modes +d and +z. +d is a mode of type A, just like in your ircd. +z is of type D (ie doesn't accept any parameter). Neither of them is listed in CHANMODES. Consider the server sending this to mirc:
:qwerty!qwerty@blah.com MODE #somechannel +zd somenick
What should mirc do in this case? Assume that "somenick" belongs to +z? Or maybe +d? Let's say it does the 1st (since this is truly 50-50), so it thinks "somenick" has mode +z in #somechannel. It also puts "+d" in the titlebar, as it considers it a mode of type D since there is no third parameter.

Now consider the server sending this one after a while:
:qwerty!qwerty@blah.com MODE #somechannel +d someothernick
Oops! Looks like +d is the one that's of type A after all, not +z! What should mirc do now? Set someothernick to +d? Remove the +z from somenick (from the previous command) too? Remove +d from the titlebar too (since it's not a type D mode apparently)?

To avoid this mess, mirc adopts a standard behaviour, the one described in item 37 of v5.9 versions.txt. This is wiser than trying to be smart and "figure out" the mode type by the rest of the parameters, imo: it's better to have a standard way of dealing with ambiguous things than doing 'guesswork', which some users could find smart while others stupid.

What would be even better is to add that damn 005 numeric to your server It won't break any client, on the contrary, it will make some clients (including the most popular one in the world) work correctly.

Yay I added RPL_ISUPPORT to my server this morning

>If you read item 37 of v5.9 versions.txt (you can get the full
>versions.txt from here) you'll notice the line:
>All unknown/unlisted modes are treated as type D.

>Consider the server sending this to mirc:
>:qwerty!qwerty@blah.com MODE #somechannel +zd somenick
>What should mirc do in this case?

Hmm, quite persuasive and perfectly ambiguous example, that's what I forgot

>:qwerty!qwerty@blah.com MODE #somechannel +zd somenick
>What should mirc do in this case?

It all depends on what you want those mode letters to support. I know +z to be a room encryption mode and +d to block namechanges whilst in the room. On other IRCd's they may do other things. How mIRC reacts, if at all, will depend entirely on this.