On Sat, 19 Nov 2022 at 19:09, Dave Cridland <d...@cridland.net> wrote: > On Sat, 19 Nov 2022 at 18:50, Matthew Wild <mwi...@gmail.com> wrote: >> > But supposing that the SASL2 extension part needs changing - in that case, >> > we need to bump the namespace of that - but we don't want to break >> > compatibility with the old-style stream feature. So now we have to >> > advertise a different stream feature if you're inlineing it, and then if >> > the main one changes but the ... you get the drift, I hope.
We've never bumped the SASL namespace that RFC 6120 defines. I think it is unlikely we will ever want to bump SASL2's namespace once it is widely deployed either. The extensibility SASL2 brings only makes it even less likely that we'll ever want to do so. If regularly bumping SASL2 *is* something we want to do, then we would probably also want to split out things like the mechanism list, since that is likely to be common across the different versions. We could define a separate namespace for <inline> (and <mechanisms>?!) that stays stable even if we change the SASL2 namespace/syntax/semantics. But this all seems very hypothetical and not realistic. >> I don't really understand this concern. A XEP can specify anything to >> be contained in <inline/>. If the inlining portion of a XEP (only) >> needs to change, then of course it will need to advertise that >> somehow. <inline> doesn't change that either way. >> > > It means the features advertised in the <inline/> block are not simple > restatements of the same features outside; they are themselves distinct > features with a distinct lifecycle, only now we're advertising stream > features in multiple places. > > In effect, you're reinventing the stream feature mechanism inside another > stream feature. Yes and no. <inline> does not quite have the same semantics as <stream:features>. >> > Incidentally, if SASL2+BIND2+etc take over the world, then you'll be >> > repeating all these stream features and/or having all stream features >> > nesting eternally inside each other. I'm not sure what you mean by "nesting eternally inside each other". We need to advertise that a server supports inlining stream management, and not just traditional stream management negotiation. I think we're all agreed that this needs signalling of some kind. You seem to prefer every extension defining an arbitrary new feature (e.g. XEP-0198 could define <enable-sasl2-inline xmlns="urn:xmpp:sm:3">) and the current proposal is that we group these features (which pertain only to SASL 2 and/or Bind 2), and that also frees us from having to invent new elements for all the existing extensions. > I find advertising some stream features only inside other stream features an > additional complexity that's not warranted. These are not just more "stream features", but specifically a description of the things that are supported for inlining. Having this presented in one place is more convenient than having the elements mixed up with other (actual) stream features. Regards, Matthew _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
