PROTOCTL CHANMODES Issue?

[Medy]

I recently discovered an interesting issue with the CHANMODES that is sent with PROTOCTL on server to server connections.

When prefix_aq is enabled the normal CHANMODES that is sent should look something like this:

CHANMODES=beI,kfL,lj,psmntirRcOAQKVCuzNSMTG

However when prefix_aq is disabled the CHANMODES that is sent is like this:

CHANMODES=beIqa,kfL,lj,psmntirRcOAQKVCuzNSMTG

In the second case qa are added to the Class A section of the mode listing
Class A as far as I know is specifically intended for mask modes.

In the client reply "005" it is sent the same, which is correct, because for clients q and a are treated exactly like mask modes when prefix_aq is disabled.

However for server to server communication, one command that is sent "SJOIN" treats q and a as prefix modes (such as ohv) whether prefix_aq is enabled or disabled.

As stated in serverprotocol.html

Memberlist is a series of users (all of which must at least be behind the server sending the SJOIN), each user is prefixed with one or more characters indicating their status. Owners (+q) are prefixed with *, admins (+a) ~, ops (+o) @, halfops (+h) %, voices (+v) +. Normal users are not prefixed with anything. Ban, ban exception, and invite exception masks are also included, with bans prefixed with &, ban exceptions prefixed with ", and invite exceptions with '. Note that when a &, " or ' is encountered as the first character, further processing of ~, *, @, %, or + characters must not continue because ban, exempt, and invite masks can contain any of those characters. (Plus it's just not right for a ban mask to be marked as a channel admin...)

This clearly states that mask modes like b and e should not be mixed with channel status (prefix) modes. However a and q are sent in the same grouping as ohv and are treated like status (prefix) modes, even though CHANMODES as classified them as being mask modes.

This is not only confusing, but could cause problems in software (services) that treat all mask modes exactly the same, when unreal wants the server to treat the mask modes q and a as prefix modes in SJOIN.

Any information regaurding the subject, and whether or not this is a bug would be very helpfull

P.S. If this should be reported as a bug, and should have been reported to the bug tracker, I appoligize.

[aquanight]

You should look at how SJOIN deals with the other mask modes (+b, +e, +I). Even though prefix_aq are reported as "mask modes", they are still part of the user status. I think it'd look silly to have to do @someuser *someuser in an SJOIN when *@someuser really works quite well... (and sticking it in the normal mode area is REALLY silly because then you can't do more than ~ 10 or 11 at once).

Really, PREFIX_AQ is more for the benefit of clients that can't handle anything other than op/halfop/voice. While it does have a few effects internally (ie: without it you need +o to do anything with your +q privs), that's likely because you don't want to look wierd having unmarked clients doing things (setting mode/topic, kicking) they shouldn't be able to do normally (else less-informed people start thinking you're an ircop, blablabla "oper abuse", etc... course if you really ARE an ircop that'd be ok :P).

[Syzop]

Regarding CHANMODES, you say "mask modes" all the time but class A is about list modes, and yes... qa belongs there IF prefixes are not enabled.
The only thing I can think of right now is that I remember that it would be a good idea to also send PREFIX= in PROTOCTL.

Regarding SJOIN, I don't see any problem. aka.. see aquanight.

[Medy]

Oh sorry, I ment mask modes as list modes :\

Anyways thanks for the reply, and PREFIX would be nice to have PROTOCTL