On Sat, 19 Nov 2022 at 18:31, Dave Cridland <[email protected]> wrote: > 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.
I agree, you cannot just advertise anything in an <inline/> block and expect it to work. Nobody thinks that. Every protocol that supports inlining has specified exactly what that means. E.g. XEP-0198 has been updated with an additional section to cover this. Now I'll add that your suggestion also doesn't work: you can't just spec something and then expect it to work. Just because we update XEP-0198 with a section that describes how it can be inlined, that doesn't mean every server supporting SASL2 automatically understands XEP-0198 inlining. And as you pointed out, things may change over time. In other words, we *need* advertisement and discovery for this feature. >> 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. 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. > 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. There's no rule that you have to repeat the same stream feature inside <inline/>. > 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 don't see how <inline/> adds any need for repetition. If <inline/> didn't exist, everything still has to indicate in some way whether it can be inlined or not. Sure, we can have <compression> and <compression-inline> features perhaps, but I find <inline> is a much cleaner and more logically obvious solution to this issue. Regards, Matthew _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
