bug#51342: 29.0.50; remove non-CAPs from rcirc capability list

["J.P." <jp@neverwas.me>]

Philip Kaludercic <philipk@posteo.net> writes:

> What confuses me is how standard-replies doesn't have to be requested.
> message-ids is clear, because they rely on message-tags and if a that is
> provided, sending message IDs even if they were not requested wouldn't
> pose any issues.  The thing is that standard-replies introduces new
> types, that the client must be able to parse.  Just sending them to any
> non IRCv3-capable client would presumable confuse it.  From reading the
> spec, I don't immediately see that it says the capability should be
> requested.  Could you explain this?

Standard replies are quite mysterious. From what I can gather:

  - Future extensions are to favor this form of reply whenever possible.
  - These *aren't* for recasting existing replies.

So there's no need to explicitly request them because support is implied
when asking for an extension that uses them, much like with message IDs.

However, I *have* noticed at least one progressive IRCd sending standard
replies not defined in any spec [1]. I can only guess they assume
clients not privy to the new syntax are resilient enough to take these
in stride [2]. And while being privy does buy a client more useful info
for presenting to the user, it's still the particulars, like the
specific reply code and the shape/meaning of the "context params", that
allow it to respond decisively to a given situation (IMO). Thanks.


[1] https://github.com/ircv3/ircv3-specifications/pull/276

[2] As in recognize these messages as at least adhering to the standard
    IRC format and therefore capable of withstanding whatever treatment
    is normally reserved for extracting the most degenerate
    understanding (like simply printing the message to the server buffer
    as a quasi error), in much the same way Libera likely doesn't worry
    much about its nonstandard numerics 479 and 435(?) causing much of a
    stir.