-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ambiguity surrounding trailing lists #205
Comments
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 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.
It mostly broke clients on MODE, because it sent: |
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? |
I feel it's already clear enough; but go ahead and we'ill discuss it there |
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: