View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002778 | unreal | documentation | public | 2006-01-28 02:10 | 2006-01-28 19:13 |
| Reporter | tabrisnet | Assigned To | syzop | ||
| Priority | normal | Severity | text | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | Linux/x86 | OS | Debian Linux | OS Version | testing |
| Product Version | 3.2.4 | ||||
| Fixed in Version | 3.2.4 | ||||
| Summary | 0002778: serverprotocol.html | ||||
| Description | 5.2 - JOIN 0 is sent inter-server. This was a bug in SurrealServices for a while until I noticed it. general issue: I understand that you might want to use @numeric, but a) it may be a :servername or @numeric b) not all services imps will care to use numerics c) it feels slightly obtuse to document it that way. afaik, any case where you can see a :servername it may be replaced by a @servernumeric. Please correct me if I am wrong. is 2.4 EOS considered 'mandatory' ? It seems that some packages such as NeoStats do not use it. 8.1 TKL - Might this be listed as to what it stands for? I assume something along the line of Timed K:Line. Please consider documenting the base64 table used. Especially the fact that, afaict, there is a different table used for NICKIP vs the other SJB64 usages. This one threw me for a loop when I tried to implement NICKIP. | ||||
| Additional Information | Thank you for this document, I only wish it had existed a year or two ago. Up until this point I have had to read what few docs exist and reverse-engineer, or emulate from other services, the rest. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
Also would be nice if the serverprotocol doc would explain what changes between different versions of the protocol. Aparrently there will be yet _another_ change in the protocol version for 3.2.4. |
|
|
Just to answer some of your questions (I actually have not read the document fully and have some small remarks as well but..in general I'm glad there's some documentation now): - For info on numerics you can take a look at doc/technical/protoctl.txt (and compare/synch it with this document). It says, if NS [numeric servernames] are enabled, you can use @numeric instead of the servername both in the source of all messages (:@blah PRIVMSG...etc) and in the NICK message (the servername field). Actually _exactly_ this is documented in section 2.2 ;p. Though, I think it might be a good idea to mention which PROTOCTL's you assume in the text that follows (the syntax/examples, etc), it seems you at least assume NS (which is fine, but I also agree with tabrisnet that it should be mentioned that this is not mandatory or anything). - For ulines (services), EOS is not mandatory, but completely optional. - Sounds good idea @ base64 (yes the other SJB64 stuff uses a weird base64 table, we decided to use REAL base64 [except padding] for NICKIP and such). Just to add something: Some stuff should just not be in documentation, such as phrases like: "Unreal currently does both in all cases, although this may not be the best approach." (the latter part). Cricicism, fine, but discuss so at the right place and not in the docs... On the other hand, if there's a bug which the reader has to know about - like.. a message that is sometimes sent with a parameter missing - then feel free to document.. that's not a problem. (+ report ;p) Release isn't too far off though, so don't be surprised if aquanight can not upadte everything before then ;p. As for the protocol version, I think nothing important changed, so really nothing to worry about -- this time ;p. We simply decided to version bump the protocol version upon every stable release. |
|
|
Well, as far as protoctl assumptions, EOS, and the bit about nick colliding (which is probably already reported somewhere btw?), should be fixed now. As for the base64 table, I'll have to do some figuring out there :P . |
|
|
ok. as for base64: - unreal's base64 for SJB64 etc, see the table in doc/technical/base64.txt - and for "real" base64: http://www.faqs.org/rfcs/rfc1421.html section 4.3.2.4 (aka: ctrl+f, Value Encoding). [the "=" padding is unused] |
|
|
Syzop: Erm... I loaded anope in debug mode for some of this... my (LAN) IP came out as wKgCYQ== (ie: with the = padding). |
|
|
hmmm ok, odd..... |
|
|
Base64 "tables" should now be there. Hopefully my math came out right for everything ;P . |
|
|
JOIN 0 thing also corrected. |
|
|
hmm :P I don't find the explanation for the base64 stuff very clear, I'm sure your intentions were ok but in my opinion the explanation is only making things _less_ clear :P I would suggest just to use 2 tables (_real_ tables) and keep it at a short technical note about byte order. Basically, it doesn't have to be a hex/decimal/binary class :P. |
|
|
Looks all fine now, if you ask me ;) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-01-28 02:10 | tabrisnet | New Issue | |
| 2006-01-28 02:25 | tabrisnet | Note Added: 0011085 | |
| 2006-01-28 08:31 | syzop | Note Added: 0011086 | |
| 2006-01-28 12:13 | aquanight | Note Added: 0011087 | |
| 2006-01-28 12:32 | syzop | Note Added: 0011088 | |
| 2006-01-28 13:45 | aquanight | Note Added: 0011089 | |
| 2006-01-28 14:09 | syzop | Note Added: 0011090 | |
| 2006-01-28 14:32 | aquanight | Note Added: 0011091 | |
| 2006-01-28 14:50 | aquanight | Note Added: 0011092 | |
| 2006-01-28 15:44 | syzop | Note Added: 0011093 | |
| 2006-01-28 19:13 | syzop | Status | new => resolved |
| 2006-01-28 19:13 | syzop | Fixed in Version | => 3.2.4 |
| 2006-01-28 19:13 | syzop | Resolution | open => fixed |
| 2006-01-28 19:13 | syzop | Assigned To | => syzop |
| 2006-01-28 19:13 | syzop | Note Added: 0011095 |
