Pre-connection-registration ISUPPORT

[emersion]

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.)

[sadiepowell]

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]

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]

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]

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]

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]

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]

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