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
Add sasl-ir extension #520
base: master
Are you sure you want to change the base?
Conversation
Implemented in Matrix2051: progval/matrix2051@e03f2be |
Co-authored-by: dgw <dgw@technobabbl.es>
Independently of this spec, thoughts on adding a non-normative caution to the SASL spec, recommending that unrecognized mechanisms should not be logged? |
Done here: #522 |
could there be some guidance regarding mechanisms that are server-first? e.g. should the server explicitly abort if IR is used but the server's initial challenge is not empty (i.e. if it's not "AUTHENTICATE +") I don't remember such mechanisms offhand (and the existing ones wouldn't be relevant for IRC to be fair) but afaik they do exist |
Co-authored-by: Sadie Powell <sadie@witchery.services>
Summarizing some discussion from #ircv3, it seems like in order for this extension to provide a speedup, the client has to cheat slightly (by caching a previous |
The goal of this extension is not to provide a speedup (clients can already do it), it's to make the protocol more reliable. If the client caches |
Are we talking about a TOCTOU race between the server sending a CAP LS 302 response including Or is the idea that a cached cross-session observation of |
The idea of this extension is to make it safer to pipeline |
Maybe stop using the same keyword |
If we want to make bigger changes, I'd suggest adding a
|
This issue would still exist for line continuations, right? It seems to me that the concerns here don't really justify adding complexity to one of the most widely implemented and deployed IRCv3 specs. (For what it's worth, the draft as written still has a performance rationale in the introduction section. I think I understand most of the robustness rationale now, but I'm still not really convinced.) |
Pretty similar to the IMAP SASL-IR extension.