On Sat, 22 Oct 2022 at 22:29, Thilo Molitor <th...@eightysoft.de> wrote:
> Again, MattJ already explained this well: > https://mail.jabber.org/pipermail/ > standards/2022-October/038998.html > <https://mail.jabber.org/pipermail/standards/2022-October/038998.html> > > SASL2 allows for inlining additional elements into the authentication flow. > That, like pipelining, reduces round-trip-times. > To let clients distinguish, which features can be inlined into the SASL2 > authentication flow and which features are supported by the server but can > not > be inlined, a new "namespace" for inlinable features is needed. > > When I designed SASL2, I designed it such that arbitrary elements could be introduced anywhere in the flow by having them within SASL2 top-level elements. I certainly didn't intend to imply that this meant that clients could inject top-level-elements from other extensions that happened to be supported without negotiation. I'm not sure where that came from. > As MattJ says: > > It's important to stress that, despite calling out XEP-0198 and Bind 2 > > in the changelog and text, this is intended for example purposes only. > > There is no intention to increase the scope of XEP-0388 to cover which > > specific protocols can be negotiated (in fact this is the whole reason > > for introducing <inline/> as an extension point). > > The Bind2 update already in our pipeline as well as the XEP-0198 update > use > that <inline/> element as specified in our SASL2 update. > > In fact, Bind2 has it's own <inline/> element, too. > ISR, for example - XEP-0397 - doesn't need the <inline/> element at all to handle XEP-0198. You can argue it's too tied into HT-* or whatever, but the framework for adding extensions into SASL2 exists already and I'm honestly confused as to why a further <inline/> is needed here. > > The split is between things that are enabled before resource binding, > > and those that are enabled after resource binding. You can see an > > example here: https://matthewwild.co.uk/uploads/xeps-tmp/ > xep-0386.html#example-1 > > -tmolitor > > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
