CAP 302: ambiguous existence of multiline ACK replies

[0x5c]

Everywhere in the capability negotiation spec where version 302's multiline replies are mentioned, it's only for LS and LIST subcommands. They're the only ones listed in the effects of version 302, the only ones with multiline format specifications and examples, and the only ones in the "Multiline replies to CAP LS and CAP LIST" section.

...except for this paragraph in the description of ACK:

If an ACK reply originating from the server is spread across multiple lines, a client MUST NOT change capabilities until the last ACK of the set is received. Equally, a server MUST NOT change the capabilities of the client until the last ACK of the set has been sent.

Contrasting that, REQ specifies:

Clients SHOULD ensure that their list of requested capabilities is not too long to be replied to with a single ACK or NAK message. If a REQ’s final parameter gets sufficiently large (approaching the 510 byte limit), clients SHOULD instead send multiple REQ subcommands.

Is a multiline ACK possible and should clients expect it as a possibility? To me it seems like old wording that fell in the cracks as the spec was developed -especially since NAK has the same constraints but no mentions of a multiline reply-, but maybe a multiline ACK makes sense to others.
Speaking of NAK, surely the answer to that question would apply to it too, right?

[ValwareIRC]

I don't see any contrast, but maybe I'm too sleepy.

The first talks about that you must not consider (from a client or server perspective) that the client has any capabilities until after the final ACK.

The second talks about we need to split up outgoing REQ buffers to not be longer than 510 and send them over multiple REQ requests.

Is a multiline ACK possible and should clients expect it as a possibility

Here's the thing, what do you mean by multiline? As in a batch? If you meant as a batch, then no, multliline ACKs are not possible.

If you meant by a case where a user "should" not sends a CAP REQ which is over 510, I believe the rest is implementation specific/undefined behavior. Aside from the slightly broken client, I believe servers may either NAK the whole thing or ACK a truncated version, or, yeah, send multiple ACK but not in a multiline batch. I think most servers would just swallow anything after 510.

Follow-up: I think it would be reasonable for this to happen:

C: CAP REQ :long line of caps at exactly 510
S: :irc.server.com CAP * ACK :long line of caps at
S: :irc.server.com CAP * ACK :exactly 510

So, in such a case, yes, I would say multiple-lined ACK are possible, since the server is sending lines longer than what was recvd.

[0x5c]

By digging through crosslinks in issues here I found #359 asking the same thing, and where it seems the consensus was no.
#371 was made to address the lack of guidance on REQ splitting, but it did not include clarification on multiline ACK (left the paragraph intact).

It seems like the paragraph should be removed or clarified as a SHOULD NOT

[0x5c]

Here's the thing, what do you mean by multiline? As in a batch? If you meant as a batch, then no, multliline ACKs are not possible.

Multiline is a specific and well-defined concept in the context of capability negotiation (ie this context here).