modern-irc icon indicating copy to clipboard operation
modern-irc copied to clipboard

Ambiguity surrounding trailing lists

Open ejmount opened this issue 2 years ago • 3 comments

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?

ejmount avatar Mar 22 '23 00:03 ejmount

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

progval avatar Mar 22 '23 06:03 progval

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?

ejmount avatar Apr 01 '23 01:04 ejmount

I feel it's already clear enough; but go ahead and we'ill discuss it there

progval avatar Apr 01 '23 05:04 progval