Again, MattJ already explained this well: 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. 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. > 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: [email protected] _______________________________________________
