STATUSMSG for IRCv3 about ircv3-specifications HOT 7 OPEN

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.

from ircv3-specifications.

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.

from ircv3-specifications.

@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.

from ircv3-specifications.

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

from ircv3-specifications.

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...

from ircv3-specifications.

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.

from ircv3-specifications.

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

from ircv3-specifications.