Am Samstag, 19. November 2022, 20:08:17 CET schrieb Dave Cridland: > > 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.
I'd argue that this makes things even clearer rather than more complicated, because it clearly states that these stream features could be inlined into SASL2 by logically moving them into the SASL2 hierarchy. Suppose, for example, we'd have something like SASL3, also supporting inlining. That would list 3 stream features all beneath each other. Their naming would have to be such that it would be clear if they belonged to SASL2, SASL3 or the old non-inlining way of SASL1. Moving them logically into the SASL2 (or SASL3) elements releases you from the burden to invent new names for the same thing over and over again. -tmolitor _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
