View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001769 | unreal | ircd | public | 2004-04-30 08:49 | 2007-04-27 05:45 |
| Reporter | vonitsanet | Assigned To | |||
| Priority | normal | Severity | text | Reproducibility | always |
| Status | closed | Resolution | wont fix | ||
| Product Version | 3.2 | ||||
| Summary | 0001769: Notices & error replies [Was: None Message] | ||||
| Description | I've created a channel with modes +MT When a non oper tried to "/notice #channel ...." server was not said anything at all (no error messages)... | ||||
| Steps To Reproduce | 1) Set +M+T on a channel 2) With a unregistred nick try to notice the channel | ||||
| 3rd party modules | |||||
|
|
The RFC says that NOTICE commands are not to generate any automatic reply from the server. This goes for error replies too. |
|
|
aquanight try this: Set only +T (without +M) on a channel then remove all modes (@ etc) from yourself and try to /notice #channel. You will see a notice "Channel Notices Are Not Permitted...." |
|
|
What aquanight said is correct, but.. as you noticed we usually DO send error messages/etc. If this is 'bad' is another question, I always hated it on ircnet if I did /notice somenikc bla and I made a typo in the nick but no error was giving, or /notice #chan blasjfds and no 'channel is +m blabla' thing was sent back... usually I only found out after 15 minutes or even longer ;). So this probably will stay as-is :p. Which brings us back to the original bugreport... |
|
|
Well, the idea with the RFC saying NOTICEs should not generate automatic replies is this: NOTICE is there to be used by automatons (aka bots) to transport status messages, etc. Granted some automatons, most notably Epona/Anope and possibly Auspice, don't follow this convention, using PRIVMSG for greet messages, and also allowing users to set the mode of communication. Mind you, I don't mind services using PRIVMSG cause then I can use my query window(s) as (a) command prompt(s) ;) . Also if a bot is to make a ping/version/etc request against a new client, it _must_ use PRIVMSG per the CTCP protocol. Anyway, per the RFC, automatons _should_ (not to say must) use NOTICE for messages. Since automatons could possibly be coded to report errors by NOTICE'ing any bot masters/operators that are online, we wouldn't want the bot to get an error message, try to NOTICE the master, get another error message from the NOTICE command, try to NOTICE the master about it, basically infinite loop (== bad). So in addition to fixing this thing, maybe a [configuration] option to make NOTICE RFC-compliant is possible? Like set::notice-noerrors or something? |
|
|
Would we rather the bot continue to try and notice the master when it will always fail? |
|
|
>Would we rather the bot continue to try and notice the master when it will >always fail? Well, if the bot does gets itself tied up in an infinite loop because NOTICE is sending error replies it's partly the bot's fault for not being "ready" for error replies from NOTICE and partly the server's fault because it sent an automatic reply for NOTICE, against the RFC. Not to say that Unreal is RFC compliant for anything else. How can you be compliant to a document as old as that ;) ? It's like a program wanting to use Windows XP features, but trying to conform to the standards of Windows 95. If the RFC was the final say on what a server can and cannot do, then hybrid would probably be the only IRCd in existance right now (and services would be only a dream - No SVSNICK!). PROTOCTL most definately illustrates this, being a command never mentioned in the RFC, and indicating the presence of other "RFC-noncompliances." |
|
|
Hybrid... RFC compliant? Nothing in RFC1459 about virtual channels, halfops, ban exceptions, etc. I mean, even IPv6 support alone is enough to be breaking RFC1459! Maybe we could make a 005 token? "ERRNOTC" or something, to indicate that we return errors for notices. |
|
|
>Hybrid... RFC compliant? Maybe the really, _really_, _*!@really@!*_ old version of Hybrid... ;) >even IPv6 support alone is enough to be breaking RFC1459 I think the RFC mentions that other protocols could be used instead of TCP+IPv4. (E.G. UDP+IPv4, [TCP|UDP]+IPv6, IPX/SPX, (warning: overkill) DirectPlay, etc) >we could make a 005 token? "ERRNOTC" or something Sounds like a good idea, but bots won't necessarily recognize it. Maybe... < 001 Blah < 002 Blah < 003 Blah < 004 Blah < 005 ERRNOTC MAP Blah > PROTOCTL ERRNOTC < 304 NOTICE error messages enabled. > NOTICE UnusedNick :Blah < {RPL_NOSUCHNICK} UnusedNick :No such nick/channel. etc. But w/o the PROTOCTL from the client you would just drop bad NOTICEs like in RFC. (Using this in mIRC is as easy as a simple script.) This means accepting PROTOCTLs from fully-established connections (which could be useful to allow clients/servers to add features with DLLs/modules and then indicate these features w/o having to relink). BTW: mIRC Script I mentioned: raw 5:ERRNOTC:raw -q PROTOCTL ERRNOTC |
|
|
rofl... where the .. is this going ;)) |
|
|
Seriously, who the heck uses notice?!... Anyway, personal opinions aside, why do we need to create a numeric and use a PROTOCTL for it..? |
|
|
>Seriously, who the heck uses notice?! Bots. Services. Servers. >why do we need to create a numeric and use a PROTOCTL for it..? Not creating a numeric. Both 005 (RPL_PROTOCTL) and 304 (RPL_TEXT) already exist :P . As for creating a PROTOCTL for it... well, why not? |
|
|
Because I'm not about to #1.) use PROTOCOL as a client<->server negotiation feature. That's more RFC-non-compliant than the notice thing! #2.) I'm not going to write several hundreds of lines of code for this (adding a 005 token is 1 line of code, adding what you want is MUCH MUCH more), #3.) The only reason I suggested a 005 is to humour you; if it were completely up to me, I'd say screw it. We've done this for years and not a single bot coder has ever complained to us. At *most* the 005 token will be added, but even that's not a guarantee. The PROTOCTL stuff will *not* be added. There are currently several competing proposals for client<->server negotiation, PROTOCTL is not one of them. |
|
|
Woah. Well, yeah, there was that big argument about NAMESX or something... /me scratches another stupid idea off his list. |
|
|
w00t 2004-05-04 19:42 Seriously, who the heck uses notice?!... Anyway, personal opinions aside, why do we need to create a numeric and use a PROTOCTL for it..? - I do for making mIRC bots, I make the bots run off server notices or "raws" (numerics) along side the channel modes +q and +a the bot stores who has which mode (q or a), and if the bot has q or a, then the outcome of events is detremined by tyhe modes it has on the channel (if any). it maybe doesnt like nothing much but give a bot oper, code it to understand and react to server notices, globals, and modual things - the effects r very powerfull LOL @ Syzop (rofl... where the .. is this going ;))) |
|
|
I mean, who sends notices. Apart from servers. Personally, I would much prefer privmsg... but thats just me. |
|
|
I just played around and noticed it's a bit inconsistent: /notice target blabla 1. If target does not exist (nick/channel) we send an error 2. For channel target, for +m/+M/+b/+n/+c we don't[*], for +T we do (but if we didn't do it for +T I think users would be very confused). 3. For user target, +R sends an error, +G [w/'block'] does not. [*: my mistake.. I thought it did send an error] I think currently it's a step in the good direction, but as you can see this is quite inconsistent behavior so perhaps it's better to choose either A or B right now instead of something between it ;P. IMO the 'NOTICE' stuff in RFC is pretty outdated, quoting the whole relevant part: ' The NOTICE message is used similarly to PRIVMSG. The difference between NOTICE and PRIVMSG is that automatic replies must never be sent in response to a NOTICE message. This rule applies to servers too - they must not send any error reply back to the client on receipt of a notice. The object of this rule is to avoid loops between a client automatically sending something in response to something it received. This is typically used by automatons (clients with either an AI or other interactive program controlling their actions) which are always seen to be replying lest they end up in a loop with another automaton.' Well, fact is several clients/scripts/bots DO take automatic action [send something] upon notices, most obvious/common example is the 'your nickname is registered please identify blablabla' from NickServ triggering a /MSG nickserv identify <pass> (or /NS, whatever). Plus, I think it's unlikely for any program/script that if it would for example receive a 'cannot send to #chan due to XXX' numeric it would send another notice. And even if it did.. then it probably already had problems before. Let's take a few examples: announcer-alike-thingies and on-join senders.. like people with a script that if they (themselves) join a channel, it notices the channel 'HI HERE IS TEH LEET IDIOT' etc.. they will then see an error in their window if they are unable to send.. but whether this is bad?? For on-join scripts doing /notice justjoinedperson.. they would already had to deal with umode +R anyway. As mentioned before, the advantages are there.. users (and actually bots/whatever too, as said by codemastr) can see when they cannot send messages so they wouldn't have to keep sending/trying without knowing what's going on. |
|
|
Well, if you do make NOTICE return errors all the time, then the server basically now sees NOTICE == PRIVMSG and thus NOTICE may as well be deleted from existance ;) . If both are to have meaningful existance, there needs to be some difference server-side. Clients treating NOTICE differently from PRIVMSG is just an appearance thing. One could easily script/program an IRC client to make NOTICE == PRIVMSG, so there should be some form of distinction server-side: be it that NOTICE never returns errors, returns errors only some of the time, or maybe something else entirely. I agree that it is nice to know why a message can't be delivered, but having two commands that are effectively the exact same thing just doesn't make sense ;) . |
|
|
Well, I wouldn't call it 'just appearance thing'.. I'm pretty sure 99% of the people choose to use NOTICEs *exactly* because of the way they appear in most clients (= does not open up a new query window). Take UnrealHelper@#unreal-support for example.. for people who are not recognized it msgs them (so it opens up a new window), other messages (like 'current helpers online: ..') that are less important or responses to triggers in the channel ('!services') are send as NOTICE (so do not suddenly open a new window). Notice certainly has still it's use these days. |
|
|
I agree, saying just because it returns error messages means it should be deleted is not at all valid. There are other differences. You're just focusing on this one. For example, there is channel mode +T. If that is set, PRIVMSG still works, but NOTICE doesn't. There is a difference. |
|
|
From 0002003 : [Syzop] >Funny, seeing you in 0001769 being so in favor of that ;). a CTCP REPLY is a >notice, and as you said... error replies should not be sent for notices.. great, >isn't it? Well, since my last post on this bug... I've kinda done a bit of thinking, and I guess maybe it is a good idea for numeric replies to be sent. The RFC is indeed outdated, and chances are things that do stuff like NOTICEing in response to something else have probably gotten more intelligent between the time the RFC was written and now :) (and if they haven't, then boo for them :P ). So yeah, I can't really see any reason why not. So now adding to the list, +C also does not cause an error to be sent... On a side note: the point about not sending errors to avoid loops... why not do +B checking? Like if the client is +B, don't send errors... Clients would be -B, and see why notices don't get sent... bots that don't care about errors just put +B and they don't see errors anymore. I don't know of any bot that really cares if a notice gets sent or not... (then again, I don't know of very many bots :P ). |
|
|
Please re-submit for 3.3 or 3.2.6/7 instead if this issue still exists. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-04-30 08:49 | vonitsanet | New Issue | |
| 2004-04-30 13:36 | aquanight | Note Added: 0005964 | |
| 2004-05-03 11:21 | vonitsanet | Note Added: 0006001 | |
| 2004-05-04 00:55 | syzop | Note Added: 0006031 | |
| 2004-05-04 12:14 | aquanight | Note Added: 0006039 | |
| 2004-05-04 12:44 |
|
Note Added: 0006040 | |
| 2004-05-04 17:58 | aquanight | Note Added: 0006061 | |
| 2004-05-04 18:04 |
|
Note Added: 0006063 | |
| 2004-05-04 18:14 | aquanight | Note Added: 0006064 | |
| 2004-05-04 18:18 | syzop | Note Added: 0006066 | |
| 2004-05-04 18:42 | w00t | Note Added: 0006068 | |
| 2004-05-04 18:45 | aquanight | Note Added: 0006069 | |
| 2004-05-04 21:02 |
|
Note Added: 0006078 | |
| 2004-05-04 21:12 | aquanight | Note Added: 0006082 | |
| 2004-05-07 10:37 | White_Magic | Note Added: 0006119 | |
| 2004-05-10 22:15 | w00t | Note Added: 0006156 | |
| 2004-05-18 12:24 | syzop | Note Added: 0006313 | |
| 2004-05-18 13:19 | aquanight | Note Added: 0006314 | |
| 2004-05-18 13:57 | syzop | Note Added: 0006318 | |
| 2004-05-18 17:07 |
|
Note Added: 0006325 | |
| 2004-05-18 18:58 | syzop | Summary | None Message => Notices & error replies [Was: None Message] |
| 2004-08-04 05:21 | aquanight | Note Added: 0007307 | |
| 2007-04-27 05:45 |
|
Status | new => closed |
| 2007-04-27 05:45 |
|
Note Added: 0013837 | |
| 2007-04-27 05:45 |
|
Resolution | open => wont fix |
