-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
strengthen labeled-response guarantee #485
base: master
Are you sure you want to change the base?
Conversation
As a client dev, "exceptional" sounds a lot more reliable than "when feasible". "exceptional" makes it clear that a hard timeout for the pathological cases is enough. Additionally, without this patch it is tempting to add labeled-response support to a bouncer even if the upstream server doesn't support it. The bouncer could have the hardcoded "if I sent a JOIN, the response will be JOIN or ERR_NOSUCHCHANNEL or…" logic and manually insert labels on replies. This doesn't work for echo-message though, and this new wording makes it clear it's a bad idea. tl;dr +1 from me! |
To clarify what's at stake here, we'd want to go through the current support table, which lists (for servers):
and verify that there is no routine circumstance under which they do not label a response. For example, it would be a problem if remote WHOIS is never labeled. |
From discussion with InspIRCd, the stronger version of the guarantee is not supported there, and cannot be for architectural reasons. So this goes back to an approach similar to #422 (adding a new flag for advertising the stricter behavior). However, the guarantee here is weaker than it was on #422; there it was an unconditional MUST, here's it's a MUST modulo "exceptional runtime conditions". |
This feels like a solution in search of a problem. Have any existing client implementations actually asked for this? |
I think this reverses the order of things. Existing client implementations don't need this --- they've already built routing logic for numerics that works around the lack of labeled-response. The objective here is to make possible a greenfield IRCv3 client that relies on labeled-response because it doesn't have those workarounds. |
Those implementations will still have to deal with the reality that:
|
I wonder if an alternative might suffice, where we have an explicit labeled response messages which indicates labeled replies are unsupported for this request. Instead of indicating the implementation is strict, we instead indicate when a message won't get a labeled response clearly and consistently for clients.
Potentially, there could be room for another failure case where we started sending the labeled response but then an error condition occured such as a netsplit
The benefit here, is sometimes the server implementation may be able to provide labeled response (local whois, or no such nick, error cases etc). Ultimately, I think the problem from a client perspective is the lack of uncertainty in the response to labeled requests. Having a strict mode combats knowing the response will always be strict in a subset of servers, but does not solve the complexity of many different fallback branches for different servers that implement differently. Having a clear mechanism in place to expose a reply won't be labeled seems more desirable to me. |
This doesn't really address my main objective for this (making greenfield clients with no fallback routing logic possible). |
@SadieCat So in your opinion, at worst this spec change is at worst useless, right? So, as some other people find it useful, we should probably go forward with this change anyway. |
This seems to be a no brainer - it doesn't invalidate any existing implementations but still provides a way forward for clients that want to work with servers which can provide the strict behaviour. |
I feel that by default the labeled-response spec should be stricter and specific about requiring labels on echo-message. This was a primary motivation for the spec after all. I'd support something along the lines of #528 but on the label spec instead of echo. I have yet to hear a convincing concrete example of how a "full strict" guarantee would help clients. The main argument seems to be for green field clients that have no intention of supporting existing servers that don't support label at all. This feels pretty antithetical to the backwards compatibility ethos of IRCv3 so I don't think it makes sense to enshrine in the spec, even as an optional cap value. |
Next-generation mobile clients (e.g. Goguma) already effectively require a modern server that supports CHATHISTORY. I understand the requirement of strict backwards compatibility to apply to servers rather than clients. I have always seen the goal of building a greenfield modern client that explicitly requires a modern server as valid. |
This follows up from #422. Here's my understanding of the state of play there:
This change does the following:
From discussion, this would be considered an erratum and it would be necessary to confirm that existing server implementations comply with the strengthened guarantee.