On Sat, 19 Nov 2022 at 18:50, Matthew Wild <[email protected]> wrote: > 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. > > Yes, of course.
So we agree that a SASL2 variant of an existing extension has to have a stream 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. > > 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. > 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. > I find advertising some stream features only inside other stream features an additional complexity that's not warranted. Dave.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
