View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004519 | unreal | ircd | public | 2015-12-29 05:01 | 2015-12-29 15:17 |
| Reporter | WubTheCaptain | Assigned To | syzop | ||
| Priority | normal | Severity | text | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Product Version | 4.0.0 | ||||
| Summary | 0004519: s_err.c: String 256 (RPL_ADMINME) is non-standard | ||||
| Description | RPL_ADMINME is a response the client receives using the ADMIN command. The RFC 1459 standard [1] says in section "6.2 Command responses.": 256 RPL_ADMINME "<server> :Administrative info" UnrealIRCd implements a non-standard version of this: 256 RPL_ADMINME ":Administrative info about <server>" It is suggested that UnrealIRCd adopts the RFC 1459 standardized version of RPL_ADMINME. [1]: https://tools.ietf.org/html/rfc1459 | ||||
| Steps To Reproduce | A client sends an ADMIN command (usually /admin) to the server and receives an unexpected response. In a client, the unexpected response may look like this: Administrative info about irc2.unrealircd.org Binki [email protected] Expected response: irc2.unrealircd.org :Administrative info Binki [email protected] | ||||
| Additional Information | The offending source code line is as follows in src/s_err.c:288: /* 256 RPL_ADMINME */ ":%s 256 %s :Administrative info about %s", This issue was fixed today in Charybdis, and the developers suggested to contact other IRCd maintainers for consistency. I am not familiar with UnrealIRCd's code, but if I'm not incorrect the following would resolve this issue: /* 256 RPL_ADMINME */ ":%s 256 %s %s :Administrative info", | ||||
| 3rd party modules | |||||
|
|
As a note, irc2.unrealircd.org is running UnrealIRCd 3.2.10.2 like in given example, but this bug exists in 4.0.0 too. |
|
|
Must say I like our numeric better. I say "our" but a lot of IRCds implement it this way. You already get the servername from the prefix anyway so the servername is redundant too. Also doesn't make sense to include it in the 256 reply and not in 257/258/.. - the other admin replies. RFC1459 also expects us to mention the "details of the university and department" via a specific numeric in /ADMIN output. No, I'm not joking. We're not going to do that either. This RFC is highly outdated and pretty much nobody is folowing it strictly. I don't feel we should change this. |
|
|
> I say "our" but a lot of IRCds implement it this way. Charybdis has switched to the the standard one today. InspIRCd is interested to merge this after fixing a parameter issue first. nefarious2 is discussing it. Technically, the standard 256 response is more machine parsable. > RFC1459 also expects us to mention the "details of the university and department" via a specific numeric in /ADMIN output. No, I'm not joking. I'm aware, and frankly I am liberally following this. s/university/organization/, department is NOC (network operation center) for me. As irrelevant as it is, as long as ADMIN is configurable the RFC can be followed. > I don't feel we should change this. I'll leave it up to you how you want to lead this project. |
|
|
nefarious2 merged this right now. |
|
|
For what it's worth I favour the string mentioned in the RFC for the sake that it looks much cleaner. |
|
|
Thanks for the additional information. You say "the standard 256 response is more machine parsable". However, as I already pointed out, the servername is already in the :servername prefix, so it's redundant. The same servername parameter is missing in the other ADMIN replies, and for good reason: because it's unnecessary since it's already in the prefix for each such message. If it was so much better I'd agree and change it straight away but... I don't see why we should revert a 15+ yr practice (by almost everyone) to a 1993 document. Then what's next? I'm sure one can come up with a whole list. We want to move IRC forward, not backward. So I'm closing the issue. Hope I didn't upset anyone :) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-12-29 05:01 | WubTheCaptain | New Issue | |
| 2015-12-29 05:05 | WubTheCaptain | Note Added: 0018977 | |
| 2015-12-29 12:04 | syzop | Note Added: 0018987 | |
| 2015-12-29 13:34 | WubTheCaptain | Note Added: 0018988 | |
| 2015-12-29 13:57 | WubTheCaptain | Note Added: 0018989 | |
| 2015-12-29 14:17 | blank | Note Added: 0018990 | |
| 2015-12-29 15:17 | syzop | Note Added: 0018995 | |
| 2015-12-29 15:17 | syzop | Status | new => closed |
| 2015-12-29 15:17 | syzop | Assigned To | => syzop |
| 2015-12-29 15:17 | syzop | Resolution | open => no change required |
