IrcJr: message parsing issue

[LLG]

When receiving single-word PRIVMSGs that do not have the colon 

before the last parameter, they are shown without its first character.

All parameters in IRC messages are equal, there is no obligation

to put a colon before the last one.

[Michael Brutman]

What exactly are you doing to get this result?

Looking at the BNF for the message format, the one word message you are sending is clearly part of the params of the command.  And the params always starts with a colon.  See section 2.3.1 of https://www.ietf.org/rfc/rfc1459.txt for the BNF representation of a message.

-Mike

[Michael Brutman]

Let me rephrase that as I phrased it poorly. 

Based on the BNF

<message> ::= [':' <prefix> <SPACE> ] <command> <params> <crlf> <prefix> ::= <servername> | <nick> [ '!' <user> ] [ '@' <host> ] <command> ::= <letter> { <letter> } | <number> <number> <number> <SPACE> ::= ' ' { ' ' } <params> ::= <SPACE> [ ':' <trailing> | <middle> <params> ]

The *last* (trailing) param always starts with a colon.  And for the PRIVMSG command the text of the message is always the last param, so the message is always preceded with a colon.

-Mike

[LLG]

> What exactly are you doing to get this result?

I know at least two clients that send 1-word messages in this way. The RFC also says:

"After extracting the parameter list, all parameters are equal whether matched by <middle> or <trailing>. <trailing> is just a syntactic trick to allow SPACE within the parameter."

Apparently people take it that the ':'-syntax is optional if there is no spaces to escape.

[Michael Brutman]

I looked some more and it's interesting, but I think it's a bug in those clients.

By the original RFC (1459, May 1993) there is no room for interpretation of how params are constructed.  Params are repeated.  Params in the "middle" (not the trailing param) must not have spaces and can not start with a colon.  The last param (trailing) is always preceded by a colon and can have any char except space in it.  That last bit is important because it implies that if the command needs a param that starts with a colon it has to be the last param, and it is still prefaced with a colon.

RFC 2812 (April 2000) has a much better defined BNF describing the message syntax.  As I interpret it, you can have a varying number of params (up to 14) then you use the first rule and the last param must be marked with a colon, as per RFC 1459.  But they also provide an alternative rule that says if you have exactly 14 params then the colon marking the last param is optional, as you already know it's the last param because params are limited to 14.

The PRIVMSG command only has two params - the target and the text to be sent.  There is no interpretation of either the original RFC or the newer RFC that allow for an optional colon before the 2nd (and trailing) param which is the message text.

What exact clients are doing this?  I'm happy to investigate further, but if these are obscure clients then I'm suspicious.  There have been no reports of bad behavior from people using the well known mainstream clients.  (Then again, I don't get bug reports too often because people often won't bother.)  One could take advantage of knowing that PRIVMSG only has two params and bend the rules to help out other broken clients, but then that opens a different can of worms - what happens when somebody sends a one word message that starts with a colon?  That case would be ambiguous.

(At some point we should probably take the discussion offline, as it is probably not of interest to the other subscribers.

-Mike