You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In UnrealIRCd 4.0.16 we send a CAP DEL sasl when services disconnect and CAP NEW sasl when they re-appear. This because the 'sasl' capability, after all, disappears when services are offline and reappears when they come back online.
Also, I figured it would give the opportunity for clients to (re-)authenticate if they see services (re)connect. For already authenticated clients most services won't ask to re-identify (due to svsid) but a user may get connected while services were offline, so then this would be useful when they must identify x time later when services come online.
Is the sending of CAP DEL / CAP NEW in this case acceptable behavior?
I thought so, of course, that's why it was added. But a client dev said he didn't really expect this (but can live with it).
Do you think any clarification is necessary in the spec? Or can this just be closed after answering the question?
The text was updated successfully, but these errors were encountered:
The sasl capability is integrated with the new cap-notify framework, such that if cap-notify is an active capability, the client will be notified about status changes concerning the availability of sasl authentication.
Servers MUST advertise availability of the sasl capability to any clients which have requested the cap-notify notification.
So yes this is expected behaviour, just make sure to include the mechs list in the value on CAP NEW.
Ah, yes, that sounds very clear. Good!
Sorry, I guess we were both only looking at the cap-notify spec, not the sasl spec.
Can be closed as far as I'm concerned.
In UnrealIRCd 4.0.16 we send a
CAP DEL sasl
when services disconnect andCAP NEW sasl
when they re-appear. This because the 'sasl' capability, after all, disappears when services are offline and reappears when they come back online.Also, I figured it would give the opportunity for clients to (re-)authenticate if they see services (re)connect. For already authenticated clients most services won't ask to re-identify (due to svsid) but a user may get connected while services were offline, so then this would be useful when they must identify x time later when services come online.
Is the sending of CAP DEL / CAP NEW in this case acceptable behavior?
I thought so, of course, that's why it was added. But a client dev said he didn't really expect this (but can live with it).
Do you think any clarification is necessary in the spec? Or can this just be closed after answering the question?
The text was updated successfully, but these errors were encountered: