On Sat, 19 Nov 2022 at 16:33, Daniel Gultsch <[email protected]> wrote:
> The <inline/> stream feature wrapper is just a neat wrapper for all > stream features that can be inlined into SASL to announce themselves. > Yes ISR works without inline but that's not the point. > > Well, that wasn't in fact the point I was making there - I meant the <inline/> element within the TLEs. But you're right, neither adds any actionable information whatsoever, so isn't useful and therefore should not be added. > Imagine we want to make compression inline-able. Simply by looking at > the <compression/> stream feature a client doesn’t know if compression > can be inlined into SASL. So if we want to make compression inlinable > the new XEP (or an amendment to the existing XEP) would have to either > announce a new stream feature called <compression-inline/> (This is > kind of - but not really - what ISR is doing) or place itself in the > <inline> wrapper like this: <inline><compression/></inline> > > OK, so compression, let's take that as a worked example. A client absolutely knows that XEP-0138 isn't a XEP-0388 extension, because it isn't. You cannot simply advertise it in an <inline/> block and expect it to work, either. When would compression kick in? There's no specification that tells you. It might be obvious to you - it might even be obvious to me - but it's not specified, and my obvious may not match yours. So you need to define what that means, and it's a change in wire protocol, so implicitly that means that something new has to be advertised. So, as you note, either way something new has to be advertised, so the <inline/> there is just additional cruft. But once negotiated, there's no need to put it in an <inline/> element in the messages anyway - what value does that add? The entire syntax of SASL2 was explicitly designed to handle extension, that was literally a stated goal. > It's just a syntax modification that some people find more pleasent; > not a new addition to the XEP to achieve something that wasn’t > possible before. Oh, but it carries all manner of implications. Supposing that we change the wire protocol of XEP-0198 to support directly using it as a SASL2 extension. So that means advertising the same stream feature under <inline/>, by this design. So far, so good. 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. So repeating the same stream feature inside a SASL2 stream feature as <inline/> isn't actually what you want. You do, genuinely, just want a new stream feature. 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. Dave.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
