CTCP investigations and client survey

[DanielOaks]

Final thing for the CTCP I-D, working out how spaces interact with all the dang parts of it.

• How are spaces after the delimiter and before the command handled?
• How are spaces between the command and params handled for ACTION?
• How are spaces between the command and params handled for PING?

Bonus question:

• Can we add a general 'if params are given on a query message that does not need any, ignore them'? Is that what clients do today with e.g. FINGER, CLIENTINFO, TIME, VERSION, etc?

note to self: sadie mentioned that the doc should work out the spacing stuff, add to changelog when done

edit: Extra bonus question:

• The original CTCP spec(s) describe querying params for CLIENTINFO, are those supported enough that we should specify them, or maybe we should specify them as a MAY if they do look useful e.g. for providing user-readable text or whatever??? ref provided by koragg: https://github.com/BitchX/BitchX/blob/master/source/ctcp.c#L783-L848

[DanielOaks]

I mostly ran these tests by sending these messages to each client with ircdog and seeing how they responded (adding on the final ctcp delim only if required because less typing):

privmsg clienthere :[[CTCP]]ACTION rolls
privmsg clienthere :[[CTCP]]   ACTION hi there
privmsg clienthere :[[CTCP]]ACTION      rooolls
privmsg clienthere :[[CTCP]]PING     1 2 3 4 5
privmsg clienthere :[[CTCP]]VERSION 1 2 3 4[[CTCP]]

How are spaces after the delimiter and before the command handled?

• mirc silently ignores it
• textual silently ignores it
• hexchat loudly ignores it (shows the user)
• adiirc loudly ignores it (shows the user)
• quassel silently ignores it
• irccloud silently ignores it
• irssi loudly ignores it (shows the user)
• weechat ignores it (shows the user in the status window, not the dm window)
• kiwiirc ignores it (shows the user in the status window, not the dm window)
• kvirc ignores it
• revolution irc for android ignores it
• epic5 loudly ignores it (shows the user)
• bitchx loudly ignores it (shows the user)

conclusion: We don't need to mention them, literally nothing supports that.

How are spaces between the command and params handled for ACTION?

• mirc displays it fully (keeps the params intact)
• textual displays it fully (keeps the params intact)
• hexchat displays it fully (keeps the params intact)
• adiirc displays it fully (keeps the params intact)
• quassel displays it fully (keeps the params intact)
• irccloud displays it fully (keeps the params intact)
• irssi displays it fully (keeps the params intact)
• weechat displays with the leading spaces stripped
• kiwiirc displays it fully (keeps the params intact)
• kvirc displays with the leading spaces stripped
• revolution irc for android displays it fully (keeps the params intact)
• epic5 displays it fully (keeps the params intact)
• bitchx displays it fully (keeps the params intact)

conclusion: leading spaces SHOULD NOT be stripped.

How are spaces between the command and params handled for PING?

• mirc responds with the params intact
• textual responds with the leading spaces stripped
• hexchat responds with the params intact
• adiirc responds with the leading spaces stripped
• quassel responds with the params intact
• irccloud responds with the params intact
• irssi responds with the params intact
• weechat responds with the leading spaces stripped
• kiwiirc doesn't respond to CTCP pings at all and displays them in the status window
• kvirc responds with the leading spaces stripped
• revolution irc for android responds with the params intact
• epic5 responds with the params intact
• bitchx responds with the params intact

conclusion: leading spaces MAY be stripped.

Ignores unknown params on msg queries that don't require params?

• mirc ignores them and responds normally
• textual ignores them and responds normally
• hexchat doesn't respond if unknown params on ctcp version exist
• adiirc ignores them and responds normally
• quassel ignores them and responds normally
• irccloud ignores them and responds normally
• irssi ignores them and responds normally
• weechat ignores them and responds normally
• kiwiirc ignores them and responds normally
• kvirc ignores them and responds normally
• revolution irc for android ignores them and responds normally
• epic5 ignores them and responds normally
• bitchx ignores them and responds normally

conclusion: not for the messages specified here. maybe for new ones.

Final delimiter required? (spec recommends it anyway, this is just for interest and maybe to submit an issue/pr if ACTION is broken here)

• mirc generally doesn't require the final delimiter
• textual generally doesn't require the final delimiter
• hexchat generally requires the final delimiter (see also Be forgiving of a missing ending CTCP delimiter in a truncated message hexchat/hexchat#1457 ACTION displays badly, VERSION doesn't respond)
• adiirc generally doesn't require the final delimiter, but will drop the last character of ctcp messages whether it's the delim or not
• quassel generally requires the final delimiter (ACTION displays badly, VERSION doesn't respond)
• irccloud generally doesn't require the final delimiter
• irssi generally doesn't require the final delimiter
• weechat generally doesn't require the final delimiter
• kiwiirc generally requires the final delimiter (ACTION displays badly, VERSION doesn't respond)
• kvirc generally doesn't require the final delimiter
• revolution irc for android requires the final delimiter
• epic5 generally requires the final delimiter (ACTION displays badly, VERSION doesn't respond)
• bitchx generallyrequires the final delimiter (ACTION displays badly, VERSION doesn't respond)

[DanielOaks]

I've mentioned this in the channel and in #v3 and if anyone has recommendations for other clients to test I'll give 'em a look. But the results here point towards these conclusions being pretty safe, so I'll add 'em to the doc now and change it later (hey who knows, maybe every mobile client does strip spaces before the command????!!!)

edit: KVIrc results reported by Andrio \o/ (Andrio also reported revolution irc for android results)

also suggested: maybe investigate current clients' behaviour when encountering multiple CTCP messages in a privmsg. I'm still gonna recommend clients not do it, but still may be interesting. for reference, KVIrc only recognises the \x01 delim at start+end of the message, nowhere in the middle.

[DanielOaks]

Handling multiple CTCPs in a single privmsg

using the test messages with ircdog:

privmsg clienthere :[[CTCP]]ACTION rolls[[CTCP]]hi there[[CTCP]]ACTION rolls over again[[CTCP]]
privmsg clienthere :[[CTCP]]PING 1 2 3 4[[CTCP]]hi ther2[[CTCP]]PING 5 6 7 8[[CTCP]]

• mirc handles the rest of the privmsg, delims and all (minus the final one) as the params of the first ctcp message
• textual trims at the first delim and ignores the rest of the privmsg
• hexchat trims at the first delim and ignores the rest of the privmsg
• adiirc handles the rest of the privmsg, delims and all (minus the final one) as the params of the first ctcp message
• quassel loudly ignores it (shows the user)
• irccloud shows the ACTION example fine (two separate ACTION lines with the privmsg inbetween) and only responds to the first PING, stopping there and not showing the privmsg
• irssi handles the rest of the privmsg, delims and all (minus the final one) as the params of the first ctcp message
• weechat handles the rest of the privmsg, delims and all (minus the final one) as the params of the first ctcp message
• kiwiirc handles the rest of the privmsg, delims and all (minus the final one) as the params of the first ctcp message
• kvirc doesn't recognise \01 other than at the start and end of the message as delimiters
• revolution irc for android does respond to multiple CTCPs in a single message
• epic5 processes the two ACTION ctcps first, and then afterwards shows the privmsg that was between the two CTCPs and only responds to the first ping but DOES show the privmsg
• bitchx processes the two ACTION ctcps first, and then afterwards shows the privmsg that was between the two CTCPs and only responds to the first ping but DOES show the privmsg

conclusion: yeah spec can't recommend doing this, results speak for themselves

edit: apparently quassel used to support it, but turned it into an off-by-default option after someone kept using it to flood the client off networks and all that

[DanielOaks]

For interest, tried testing out the quoting/dequoting the ctcp spec describes using the test privmsg text :Hi there!\020nHow are you? \\K? (listed in the Canonical CTCP Spec) and yeah nothing supports it (tried out epic5 and bitchx and they don't in normal privmsgs either). not surprising but good to make sure of.

[progval]

For Supybot/Limnoria:

• "How are spaces after the delimiter and before the command handled?" -> silently ignores it, and will fail the detection as CTCP ACTION
• "How are spaces between the command and params handled for ACTION?" -> assuming you mean extra spaces: stripped
• "How are spaces between the command and params handled for PING?" -> responds with the params intact
• "Ignores unknown params on msg queries that don't require params?" -> doesn't respond if unknown params exist (version/userinfo/time/finger/source)
• "Final delimiter required?" -> yes
• "Handling multiple CTCPs in a single privmsg" -> handles the rest of the privmsg, delims and all (minus the final one) as the params of the first ctcp message
• "quoting/dequoting the ctcp spec describes" -> also not supported

[DanielOaks]

Tested by sending the following lines with ircdog:

privmsg clienthere :[[CTCP]]CLIENTINFO[[CTCP]]
privmsg clienthere :[[CTCP]]CLIENTINFO TIME[[CTCP]]

How clients respond to CLIENTINFO TIME

• mirc responds without acknowledging the param at all
• textual responds without acknowledging the param at all
• hexchat doesn't support CLIENTINFO
• adiirc doesn't support CLIENTINFO
• quassel responds without acknowledging the param at all
• irccloud responds without acknowledging the param at all
• irssi responds without acknowledging the param at all
• weechat responds without acknowledging the param at all
• kiwiirc responds without acknowledging the param at all
• epic5 responds with CLIENTINFO TIME tells you the time on the user's host and does NOT have the special :-prefixed message appended to raw CLIENTINFO
• bitchx responds with CLIENTINFO TIME tells you the time on the user's host and has the special :-prefixed message appended to raw CLIENTINFO (... UNBAN IDENT XLINK UPTIME :Use CLIENTINFO <COMMAND> to get more specific information)

I may mention the :-prefixed message, with an example, but I'm gonna leave the actual query variable out of it unless someone convinces me otherwise by getting other clients to adopt it. Unfortunately one or two clients does not a reliable recommendation make when everyone else completely ignores the query param.

[DanielOaks]

Do clients send a reply to an unknown CTCP query (i.e. do they respond with ERRMSG)

• mirc ignores it
• textual ignores it
• hexchat ignores it
• adiirc ignores it
• quassel ignores it
• irccloud ignores it
• irssi ignores it
• weechat ignores it
• kiwiirc ignores it
• epic5 ignores it
• bitchx ignores it

This is basically the only reason I'd consider specifying ERRMSG I think. And I probably wouldn't consider giving 'respond with ERRMSG' as general advice in any case because it creates the possibility of ERRMSG loops and two clients spamming each other to death for no reason and junk like that. Leave it out, etc.
edit: actually, thinking about it those loops prolly wouldn't happen because PRIVMSG vs NOTICE, etc. but yeah, I still don't find any reason to specify it, esp with how freeform it is being basically just a text field.

[digitalcircuit]

Thanks for testing Quassel! I don't think any of this should be impacted by 0.14rc1's changes to IRC parsing (not 100% sure though).

As a community contributor, I'd be in favor of changing Quassel's behavior to not require the final CTCP delimiter - though it makes broken clients rather obvious, having a broken /me ... message shown is not a great user experience for anyone who doesn't desire to contact other IRC developers about their IRC clients 🙂

(No such PR is open right now)

[DanielOaks]

Aha yeah one of those cases where there are... a lot of clients and bots 'n' stuff out there that don't break outgoing /me's properly, easier for receiving clients to accept those messages than to run around trying to tell all the sending clients they need to fix themselves, unfortunately.
No stress, please let me know if there's anything in the spec that looks off or anything like that 😄

[TingPing]

hexchat master now accepts ctcp with missing trailing char: hexchat/hexchat@076b2c1

[DanielOaks]

Yays/Nays on Deprecating CTCP Responses

Proposal in the v3 channel that new clients SHOULD NOT send responses to CTCP requests. Basically, to deprecate all of CTCP apart from parsing CTCP ACTIONs, primarily on the basis that publishing identifying info by default is bad these days.

• bitbot - "count me as a vote for trying to avoid recommending new clients implement CTCP. i don't think it's massively important though"
• catgirl - Yay
• gamja and soju - Yay
• irccloud - "Count me as a vote for clients shouldn’t publish any identifying info by default. But if they want to let users choose to do so fine. And if they don’t want to implement it at all also fine"

[sadiepowell]

Yays/Nays on Deprecating CTCP Responses

InspIRCd also implements the CTCP spec (to the current spec AFAIK) and we have various features which depend on some CTCP responses so it's a no from us.