On 11 Nov 2017, at 11:01, Georg Lukas <ge...@op-co.de> wrote: > > * Kevin Smith <kevin.sm...@isode.com> [2017-11-10 21:31]: >> I don’t think this needs a new session type. It would be sufficient to >> enable these rules when clients enable ‘mamsub’ (for want of a better >> term). > > You are probably right, but my ideas about mamsub so far involve > changing the routing behavior for messages, including for offline > message delivery, so bundling all of that into a new session type that > doesn't attempt to send you offline messages, carbons or somesuch makes > sense in my eyes.
Tying all this into bind2 was my original intention. So we don’t need to rewrite any core protocol, or have a new stream version, or anything like that. Just that if you use bind2 (which probably should be bundled into sasl2), you get “XMPP 2.0” behaviour. >> (e.g. if you have a <body/> and <no-archive/> don’t show the message > > Very good point. With <transient/>, a client could also alternatively > display that this message will vanish very soon. Possibly. The important thing, I think, is that we don’t have a situation where someone can make archives contain different messages from those the user saw. > >> We still probably want resource-locking in the short term, but nothing >> stops us resource locking for iqs while continuing to bare-jid >> messages. > > Resource-locking for messages is incompatible with my proposal. Are you > suggesting there are reasons to keep it, or do you propose to limit it > to IQs right now? I meant that (although I think long-term it should go away), we need iq resource locking for the moment, for some things. I’m suggesting we could limit resource locking to only affect iqs, and all chat messages can/should be sent bare-JID (that is, I think we’re largely in agreement). >> This is, incidentally, exactly why I wanted Carbons to have weasel >> words - because it lets us sort these things out later without >> breaking anything, and we can just add a new feature somewhere to tie >> it all together. > > I have to admit that blocking my last proposals to "improve" the Carbons > rules was good indeed. Still, Carbons exists since 2010, and we are > living with the weasel words and their fallout for all this time > already, and this is causing many minor frustrations to many people > along the way. I had hoped we’d have moved faster towards the ‘right’ solution, yes. > It is reasonable to figure out how to do things right after initially > publishing an XEP, but we shouldn't need so many years for that every > time. I can’t argue with this. /K _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
