Skip to content
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

Pre-connection-registration ISUPPORT #124

Open
emersion opened this issue May 23, 2024 · 7 comments
Open

Pre-connection-registration ISUPPORT #124

emersion opened this issue May 23, 2024 · 7 comments

Comments

@emersion
Copy link

Various pieces of information would be nice to receive before connection registration, for instance the name of the network or the nickname length limit.

We could have a cap which allows servers to send ISUPPORT before connection registration.

(While at it, we could also add a new message indicating the end of an ISUPPORT burst, the lack thereof is causing a bit of pain in my clients as well.)

@SadieCat
Copy link

I think we should introduce a cap-3.3 specification that enables ISUPPORT in response to CAP LS.

It would also allow us to do some extra things like define a formal key/value system for cap values and move some stuff out of cap like only exists for informational purposes.

@slingamn
Copy link

My client implementation takes either RPL_ENDOFMOTD or ERR_NOMOTD to indicate the end of the ISUPPORT burst (and of registration more generally), but that's not applicable in the pre-registration context, so +1 for adding an explicit end-of-burst command.

@emersion
Copy link
Author

That works for the initial burst, but doesn't work for subsequent bursts. It would help me a lot to be able to buffer the new ISUPPORT tokens and apply them in one go when receiving an "end of ISUPPORT" indication, instead of having complicated/fragile logic to handle that.

@slingamn
Copy link

That works for the initial burst, but doesn't work for subsequent bursts. It would help me a lot to be able to buffer the new ISUPPORT tokens and apply them in one go when receiving an "end of ISUPPORT" indication, instead of having complicated/fragile logic to handle that.

I've gotten pushback even against the idea of using RPL_ENDOFMOTD / ERR_NOMOTD for this purpose, based on the idea that the "true" semantics of 005 shouldn't require it. AIUI the intended semantics of 005 are basically that the client maintains an associative array, and the server operates on it:

  1. BAR=baz is an upsert to the key BAZ of the value baz
  2. -QUX is a delete of the key QUX

each of these operations being individually atomic and logically independent.

AFAIK there are two kinds of post-registration burst:

  1. In response to VERSION
  2. As Modern says: "If the value of a parameter changes, the server SHOULD re-advertise the parameter with the new value in an RPL_ISUPPORT reply. An example of this is a client becoming an IRC operator and their CHANLIMIT changing."

The convention is for VERSION to send the entire current state of the 005, but in the second case it's normal to send only the changed keys, in which case there's seemingly no advantage to having a explicit end-of-burst indicator.

If the end-of-burst indicator (370 in the initial draft) actually ends up being helpful to client implementations nonetheless, the spec should probably clarify that it doesn't indicate that a complete set of 005 was transmitted, just that the server is temporarily done sending 005 updates. (But again, the end-of-burst indicator has no clear semantic content here, since the server can asynchronously send another burst at any time.)

@emersion
Copy link
Author

I've gotten pushback even against the idea of using RPL_ENDOFMOTD / ERR_NOMOTD for this purpose, based on the idea that the "true" semantics of 005 shouldn't require it.

But then clients end up with a glitchy UI. For instance in my client I don't know when I'll be getting a NETWORK in the ISUPPORT list, or if I'll get one at all. So the user sees a placeholder for a bit and then sees the real network name. If I could wait for the end of the ISUPPORT I could hide the thing until I'm sure the server has sent all information it has and avoid the glitch.

ISUPPORT is one of the very few cases in the IRC protocol where a list has no indication of end. The capability list could be seen as similar in this regard, yet has an end-of-list indication.

each of these operations being individually atomic and logically independent

I think there might be cases where this falls apart, e.g. when two ISUPPORT parameters depend on each other. For instance PREFIX, CHANMODES and STATUSMSG. The specs have some MUST requirements that might be broken if one parameter is updated without the other.

it's normal to send only the changed keys, in which case there's seemingly no advantage to having a explicit end-of-burst indicator

There is still an upside: the updates can be applied together. Right now I update my client state each time I get an RPL_ISUPPORT, if I had an end-of-list indication I could do it once only. Another upside as mentioned above is that I don' need to have two codepaths in my clients (initial ISUPPORT vs. ISUPPORT update) - everything is handled in the same spot.

the spec should probably clarify that it doesn't indicate that a complete set of 005 was transmitted, just that the server is temporarily done sending 005 updates

Indeed.

@slingamn
Copy link

That all makes sense, thanks. I think the practical issues you're describing (making a decision on displaying NETWORK, and processing PREFIX and CHANMODES together) are all adequately addressed by waiting for RPL_ENDOFMOTD / ERR_NOMOTD as the end of connection registration. But as you point out, it's cleaner to have a single indication for the end of the burst in all cases (pre-registration, end of registration, and post-registration).

@emersion
Copy link
Author

Also since the extension adds a way for ISUPPORT to be sent before connection registration, there is no RPL_ENDOFMOTD/ERR_NOMOTD to wait for at this point :P

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants