You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current grammar for the parameters in a message coming from the client says that everything following a colon is treated as a single parameter, since trailing has no further structure beyond the individual characters making it up.
However, the section describing parameter lists could be to read to suggest that in something like JOIN <channel>{,<channel>}, the channel parameter should be read as appearing multiple times. The language about the Join message itself explicitly refers to the Nth <channel>, suggesting the same thing, rather than attempting to interpret the entire list as a single paramter that then gets interpreted later.
However, that implies JOIN :#a,#b will be read as attempting to join a single channel called #a,#b, which will presumably fail. I've been talking to @jesopo (@\jess on #libera) about this while developing a server, as she mentioned that inspircd changing behaviour had broken clients when it added a colon where it wasn't needed. We both agree that clients could plausibly send a message like that and expect to join two channels, but the example grammar does not appear to allow for it.
Could this be clarified?
The text was updated successfully, but these errors were encountered:
These are two separate layers of the specification.
The grammar is low-level explains how to tokenize messages independently of the commands. So if you were to translate JOIN :#channel1,#channel2 to JSON, it would be: {"command": "JOIN", params: ["#channel1,#channel2"]}.
So it is, at the grammar level, a single parameter.
Now the semantics of JOIN say that this last parameter should get extra parsing when it is a JOIN command. But this doesn't contract the grammar because it is done after messages are tokenized.
as she mentioned that inspircd changing behaviour had broken clients
It mostly broke clients on MODE, because it sent: MODE +oo nick1 :nick2 while buggy clients expected MODE +oo nick1 nick2
Thanks for the explanation, I understand now. However, I still feel this ought to be clarified in the document itself, probably in the parameter list section. I'm happy to try making that clarification myself though, should I raise a PR?
The current grammar for the parameters in a message coming from the client says that everything following a colon is treated as a single parameter, since
trailing
has no further structure beyond the individual characters making it up.However, the section describing parameter lists could be to read to suggest that in something like
JOIN <channel>{,<channel>}
, thechannel
parameter should be read as appearing multiple times. The language about the Join message itself explicitly refers to the Nth<channel>
, suggesting the same thing, rather than attempting to interpret the entire list as a single paramter that then gets interpreted later.However, that implies
JOIN :#a,#b
will be read as attempting to join a single channel called#a,#b
, which will presumably fail. I've been talking to @jesopo (@\jess on #libera) about this while developing a server, as she mentioned thatinspircd
changing behaviour had broken clients when it added a colon where it wasn't needed. We both agree that clients could plausibly send a message like that and expect to join two channels, but the example grammar does not appear to allow for it.Could this be clarified?
The text was updated successfully, but these errors were encountered: