STATUSMSG for IRCv3

[aquanight]

Currently, there is some disparity in client support of the STATUSMSG extension. I would like to include provisions for STATUSMSG in IRCv3.The current "IRCv2" STATUSMSG implementation has a 005 token advertise that STATUSMSG is supported, and a client sends a STATUSMSG by prefixing a channel name with one of the characters found in the value of STATUSMSG, which corresponds to a PREFIX flag. This same construct is then sent to those clients that receive the message, but not all clients correctly handle all such cases.

I would like a CAP token be added for covering STATUSMSG support, with the following effects:

• The capability token for STATUSMSG merely indicates support or no support: the actual prefixes in question would stay in 005 as they are now.
• If a client requests the STATUSMSG capability, it MUST correctly handle any channel name prefixed with any STATUSMSG character in any PRIVMSG or NOTICE message, treating them the same as normal channel messages. The server shall send these STATUSMSG prefixed messages, basically exactly as it does currently.
• A server MUST NOT support a character as both a STATUSMSG prefix and as a CHANTYPE.
• If a client that negotiates capabilities does NOT negotiate the STATUSMSG capability, then the server SHALL NOT send any channel name prefixed with any STATUSMSG characters. The server will still deliver messages sent this way, just the client would not be able to distinguish them. The server SHOULD reject any such message sent by the client.
• A server is NOT required to remove STATUSMG from its 005 if a client negotiates no support for STATUSMSG.

For clients that do not negotiate capabilities, IRCv2 fallback basically has us treating the client as if it had sent the token.

[kaniini]

Interpretation response

Consensus has been established that a STATUSMSG capability which behaves as above is acceptable, except with the following modification:

At paragraph 6, sentence 1, the wording will be changed to:

If a client which performs capability negotiation explicitly negates the STATUSMSG capability, then the server SHALL NOT send any channel name prefixed with any STATUSMSG characters.

Rationale

It is desirable for the IRCv3 STATUSMSG capability to behave in a way that allows graceful compatibility with clients not yet compatible with version 3.2 of the specification. Specification versions 3.0 and 3.1 do not define the STATUSMSG capability, thusly, the change would subtly break compatibility with those clients. Additionally, it would make implementation of the IRCv2 compatibility requirement mentioned in paragraph 8, sentence 1:

For clients that do not negotiate capabilities, IRCv2 fallback basically has us treating the client as if it had sent the token.

Interpretation of other concerns

Paragraph 5, sentence 1:

A server MUST NOT support a character as both a STATUSMSG prefix and as a CHANTYPE.

This interpretation is upheld as valid.

STATUSMSG may only:

• Contain characters that are valid prefixes as documented by the RPL_ISUPPORT PREFIX token, and;
• Contain characters that are NOT channel-type prefixes.

Suggested action

Write a formal specification for STATUSMSG and add it to the extension registry as statusmsg-3.2.

[jillest]

It looks like this will break STATUSMSG if an existing client that already supports STATUSMSG is upgraded with CAP support. I don't like that.

[Elizafox]

@jillest STATUSMSG is so little used I don't think that's much of a concern. Clients will have to be fixed at the same time, I guess.

[jillest]

I don't like breaking compatibility anyway. Channels that use STATUSMSG often use it quite a bit.

[Elizafox]

This is really quite a mess. Here are my ideas:

1. disabling STATUSMSG by default without CAP. This disables statusmsg for clients, even if it already works with it (I personally am more for this solution because it's a non-standard extension, little-used except for some nichés, and a lot of clients are already broken due to being unaware of its existence since it's non-standard). The workaround is if the client doesn't have tge CAP, just send it as a normal PRIVMSG.

1a) Potentially use a message tag to mark STATUSMSG messages.

2. Making it part of the standard, always unconditionally enabled. I don't know if I like this (I don't use it, I don't know anyone who does).

Unless anyone has a better idea...

[kaniini]

We could just leave it alone, which was my proposal. As in, the only option if you didn't want to sanely implement STATUSMSG, but implement other parts of IRCv3 would be explicit optout, i.e. CAP REQ ~statusmsg.

[Elizafox]

Sure, but it still needs to be documented and standardised then. I'm for opting-out as sort of an anti-CAP.