As someone who also implemented SASL2, Bind2, FAST & SM as a SASL2 features, I do think that wrapping subsequent stream features in <inline/> makes a lot of sense. It is not only convenient for developers (as they need to pass just <inline/> element as Daniel mentioned), but it also makes it easier to understand which features are available after SASL2 and Bind2. It is the same as in the classic XMPP stream establishment process when subsequent stream openings a different set of features is advertised (separate in a separate stream features element). With <inline/> element we have the same separation which will not be achieved if we would just inline those features directly in the stream features (even if we would make a way to distinguish features available after SASL2 from other stream features).
Moreover, from my understanding of RFC 6120 (I know it may not be written anywhere), I would always assume that each feature advertised in the stream features sent by the server may always be used just after receiving this stream features set and I do not need to do any other establishment before being able to use any of those new features. That is something which would change if we would inline features from <inline/> directly into stream features. Regards, Andrzej Wójcik _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
