Ratify labeled-response

[DanielOaks]

There's been a few server implementations of this and it looks pretty well stable from everything I've seen.

---

updated 2020-01-17 by @jwheare to add new blocker PR

• Label revisions #385 Label revisions (merged)
• ACK command for empty labeled responses #386 ACK command for empty labeled responses
• [labeled-response] Make batch a hard dependency #400 Make batch a hard dependency

---

Known implementations

Unchecked means incomplete or an intent to implement has been expressed. The numbers indicate minimum requirements. Any others?

Server (2/2)

• InspIRCd: (@SaberUK) https://github.com/SaberUK/inspircd/tree/insp3%2Bircv3-ctctags ircs://testnet.inspircd.org:6697
• IRCCloud teams (@jwheare)
• oragono (@DanielOaks) https://oragono.io/specs.html ircs://testnet.oragono.io:6697
• UnrealIRCd (@syzop)

Client (2/2)

• IRCCloud (@jwheare)
• Palaver https://cocode.org/blog/palaver-26/ (@kylef)

Bouncer

• IRCCloud bouncer (@jwheare)

Bots

• Bitbot (@jesopo)

Networks

• ircs://irc.irc.com:6697
• https://darwin.network

[jwheare]

Still need to resolve this ircv3/ircv3-ideas#37

[jwheare]

Added PRs to address the blockers: #385 #386

[jesopo]

Both blockers are now merged

[jwheare]

0.2 needs more implementations, I'll update the checkboxes.

[sadiepowell]

I have a 0.2 implementation for InspIRCd I just need to fix a few minor issues with it.

Update InspIRCd's implementation is now updated to 0.2, will be on the testnet shortly.

[slingamn]

I implemented this as ergochat/ergo#557, but it missed the freeze deadline for our upcoming release (v1.1.0), so it'll have to go in after that. I can put it on darwin as soon as it hits the master branch.

[RyanSquared]

With regards to which sections of a batch should include a label, either the start, or the whole message:

07:04 <LordRyan> i think it would probably be better to say "clients shouldn't rely on messages inside the batch being tagged" because i have a feeling some server implementation is going to just tag all the messages, then wrap it in a batch and tag that batch as well
07:05 <LordRyan> so it wouldn't be a good idea to say something like "servers should not include label tags inside the batch", but it's important for clients to be capable of handling the behavior just in case

[jesopo]

If batch has not been enabled, the tag MAY be included on only one of the messages in the response.

I am quite uncomfortable with this. Can't we just demand that labeled-response comes with batch support?

<LordRyan> everyone who supports labeled-response supports batch (server-side), so I'd be comfortable with that

[jwheare]

From what I can tell, there's still an unresolved decision around this. Should batch be a hard requirement for this to be enabled, or do we need more clarity around where tags are sent and how they fallback.

In the past, we've tries to resist too many hard requirements on other specs, but is this a case where it would save a lot of uncertainty of implementation? Thoughts from tech board members please.

[kylef]

I've implemented draft/labeled-response-0.2 in Palaver, I've discovered a couple of problems along the way:

• IRCCloud Teams (Using the recommended steps to connect third party client from the UI). When draft/labeled-response-0.2 is enabled without echo-message, I do not receive ACK for my labeled PRIVMSG (further details at https://gist.github.com/kylef/5a2021524b2d68d5cc5975245bd47657)
• InspIRCd batch response with labeled-response contain label on all batch lines which is different to how the labeled-response examples show it (filled: batch response with labeled-response contain label on all batch lines inspircd/inspircd#1710)
  • The link for implementation in issue description is 404 (https://github.com/SaberUK/inspircd/tree/insp3%2Bircv3-ctctags)
  • InspIRCd test net no longer lists the capability

[jwheare]

@kylef thanks for the report. ACKs should be working on bnc now as expected.

[syzop]

Figured I would re-visit this issue after a while. First of all, UnrealIRCd 5.0.0 (released Dec 13, 2019) ships with draft/labeled-response-0.2 enabled by default.

From what I can tell, there's still an unresolved decision around this. Should batch be a hard requirement for this to be enabled, or do we need more clarity around where tags are sent and how they fallback.
In the past, we've tries to resist too many hard requirements on other specs, but is this a case where it would save a lot of uncertainty of implementation? Thoughts from tech board members please.

Indeed, and I am thankful for not making too many hard requirements. I think that's a good thing.

In this particular case, I think batch should be a hard requirement because without BATCH the labeled-response functionality cannot work properly. It pretty much means multi-line response is broken without BATCH. So, for that reason I would think BATCH should be a hard requirement.

What did others say?

[jwheare]

No other opinions expressed fwict. But I'm happy to go forward with hard requiring BATCH for this.

[slingamn]

I agree.

I think there is no need to police this requirement (e.g., by having the server demand that batch is requested before labeled-response, or on the same CAP REQ line), but message-tags and batch are basic infrastructure that I think we should be comfortable in requiring people to build on top of.

[sadiepowell]

I've updated the InspIRCd implementation to require batch.

[DarthGandalf]

What should happen in the following scenario?

1. Client sends a labeled message to bouncer, e.g. WHOIS foo
2. Bouncer sends it to server
3. Server times out

Should bouncer reply to WHOIS with ACK?

[syzop]

I think that is a similar case of what we (including you) discussed in #380 where I describe a hypothetical case of a remote server disconnecting half-way causing a BATCH never to end.
The way I would summarize that thread - although it might not have been written in there as such - is that it is a corner case and it's OK for these to sometimes be unhandled.

[DarthGandalf]

Ah, while rereading the doc today, I've missed the "where it is feasible to do so" part.

[jwheare]

Once #400 is merged this should be ready to ratify. Any final thoughts from anyone?

[jwheare]

I merged #400. I'll take a look at #401 tomorrow then when should be good to go.

[jwheare]

This was reopened in #403