View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004111 | unreal | ircd | public | 2012-06-03 02:24 | 2015-08-08 16:53 |
| Reporter | warg | Assigned To | syzop | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Product Version | 3.2.9 | ||||
| Summary | 0004111: Channel names are not RFC compliant. | ||||
| Description | UnrealIRCd seems to restrict channel names to 32 characters, including the # prefix. According to RFC1459 section 1.3 channel names should be restricted to 200 characters, including the # prefix. | ||||
| 3rd party modules | |||||
|
|
Hi warg, ehm.. what do you intend to say with this bug report? ;) I'm sure you know that we don't follow RFC1459 on everything. We use CHANNELLEN=32 and advertise this in RPL_ISUPPORT (005). I would not recommend changing it. |
|
|
In my opinion, ./Config should ask about what NICKLEN/TOPICLEN/CHANNELLEN should be. |
|
|
Whats not recommended about channels names longer that 32 characters?? Also, rfc1459 should be followed as much as possible. Granted, there are places where there are better solutions but this isnt one of them. Rfc also says there should be local channels too. I guess those are harmful as well :( Before someone brings up the usefulness of local channels, please bear in mind that some people do actually use them and do infact find them useful .. sorry you disagree. |
|
|
What I intended to say, Syzop is exactly what I said, so I'm confused by your question. Also, I am ofc aware that Unreal doesn't follow the RFC on many things. I agree with nenolod and katslaw. Also, katsklaw, though it's off the current subject, I think it's relevant, and I have to agree w/ your position on local channels, though they're not useful to me. I don't know what harm local channels could possibly be. |
|
|
I'm not sure where the hostility is coming from. Perhaps it was my comment which started this? Could be, I can only say that when I made that comment I was genuinely surprised and wondering what you meant with the bug report. Now next I say will probably not make it much better, but here we go. I'll clarify: in general when you make a feature suggestion you tell us what you want to see changed/added and why. RFC1459 is from long before the birth of UnrealIRCd, so when UnrealIRCd was made we were aware of using a different channel length limit. There's CHANNELLEN= in 005 exactly to communicate this for the client. If it was always 200 then this 005 token would not even exist. There are enough IRCd's that don't use 200. Apparently developers chose a length of 32. Again.. knowing the text of RFC.. it was all there, so the question is: WHY do you now to raise it? The only thing you said is: in unreal we do 32, RFC said 200, this is a bug (with severity minor). Again, I'd like to hear WHY you would want to see this changed. Is it just to conform to this RFC? Is it because you actually sense a need for this from your users? Would anything below 200 (such as 64) suffice to fulfill your need, or does it have to be 200 due to RFC? For everyone who has a new bugreport in mind like 'RFC states <this>, Unreal must conform to it' in cases where a clear choice has been made not to (so not just a possible mistake, but a clear choice.. like this, see 005 CHANNELLEN), then I'd urge you to add an explanation as to WHY. Just saying RFC1459 does this or that, won't do. Then we would have to strip like 80% out of UnrealIRCd. UnrealIRCd has many modes and commands never mentioned in RFC1459. Nobody conforms 100% to RFC1459 anymore, perhaps IRCNet, but few other major IRCds. This is actually one of the reasons for the existence of the 005 numeric: to communicate our extensions, new features, and different limits. So.. now let's get on-topic, I hope any future comments will be on that: We should always be careful about changing any limits. It's (often) not just changing a number and then all is okay. It's just unfortunate that it seems nowadays there are few people around knowing the code and/or foreseeing the consequences (code-wise but also protocol-wise), making me always the guy having to say: STOP.. THINK.. Actually you don't always need to know the code, sometimes even the protocol would do.. there used to be services coders around here that would understand. I'll probably step on peoples toes by this comment, but what I want to say is that a small change can have major consequences if you look at the protocol and the code and it's just sad to see that people who previously understood this are rarely around anymore so this makes it look like I'm the bad guy stopping all the joy! A channel of 200 characters is just plain silly, it's ridiculously large and it leaves room for messages of only like 300 characters. Well not just messages, it also impact modes, topic, etc. The limits are all set in include/struct.h, as you probably all know. Some limits have no real impact when enlarged, such as TOPICLEN and REALLEN. They get truncated if too large (such as in client to server or server to server traffic), and in the IRC protocol (client & server) they always are at the END of a line, so when they get truncated they don't take any parameters with them. Also they are merely text fields, they don't have a technical meaning, so they are OK if truncated. This is different than with nick & channel names, they appear usually before other arguments.. if they would ever cause truncation then arguments AFTER it may be truncated which may be a real issue if they are important. Also, nick & channel names do have a meaning in the protocol, even one character being chopped off a nick is a real issue. EDIT: I thought this would be obvious, but let me explain some more just to be sure: if even one single character of a nick is truncated or from a ban or something important.. for example client->server and locally it goes fine but the limit is exceeded when server to server traffic (for example in a mode because the mode timestamp enlarges the message) then this will lead to a desynch where users on one server would think, say, a ban is in place but on the other side the ban is in place minus 1 character so it's not effective. same for kick, if one character is missing in server to server traffic the user will seem kicked from the 'sending server' but on the 'recipient server' it will still be there (these are just examples, I'm not saying there are specific issues with these.. though there might). So, as said earlier, limits should be treated with care, especially when you make a bump from 32 to 200. I'd like to have them in './Config -advanced' too, it's nice if they are configurable... but ONLY after (and really only after!) there has been a convincing full audit on the consequences of *each* raise. Yes, that's a process that will take many hours for some items (like NICKLEN and CHANNELLEN) when taken seriously, much more than just a patch to move it to config.h or ./Config -advanced, but it's my role to guard the stability of the IRCd and I *do* take that seriously :) |
|
|
I updated previous message with some more details. Sorry, I sometimes think something is 'obvious' when it's probably not to others. I hope this will make everyone understand the potential issues involved :) |
|
|
I wasn't being hostile in the slightest. I just didn't understand your question. |
|
|
Okay, good :) |
|
|
no hostility here either, just a touchy subject for me ;) @warg: Agreed, it's barely on topic. ;) |
|
|
As said we don't follow the RFC on every place, and advertise CHANNELLEN nicely. A channel length of 200 is a REALLY bad idea. Closing this... |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-06-03 02:24 | warg | New Issue | |
| 2012-06-06 18:33 | syzop | Note Added: 0017014 | |
| 2012-06-09 09:12 |
|
Note Added: 0017017 | |
| 2012-07-07 21:08 | katsklaw | Note Added: 0017034 | |
| 2012-07-07 21:12 | katsklaw | Note Edited: 0017034 | |
| 2012-07-08 13:39 | warg | Note Added: 0017036 | |
| 2012-07-08 16:17 | syzop | Note Added: 0017037 | |
| 2012-07-08 16:23 | syzop | Note Edited: 0017037 | |
| 2012-07-08 16:27 | syzop | Note Added: 0017038 | |
| 2012-07-09 06:30 | warg | Note Added: 0017039 | |
| 2012-07-09 15:14 | syzop | Note Added: 0017040 | |
| 2012-07-09 22:15 | katsklaw | Note Added: 0017041 | |
| 2015-08-08 16:53 | syzop | Note Added: 0018625 | |
| 2015-08-08 16:53 | syzop | Status | new => closed |
| 2015-08-08 16:53 | syzop | Assigned To | => syzop |
| 2015-08-08 16:53 | syzop | Resolution | open => no change required |
