* 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. > I’m not sure I like <no-archive/> on its own I'm not particularly attached to <no-archive/>, I'd rather prefer <transient/> or some other semantic hint unrelated to the storage tech below. > (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. > 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? > Probably if we had some simple rule (I think <transient/> might be > better than <no-archive/>, for semantics) where <transient/> is used > for anything without ‘content’, but only metadata, then we can > probably converge on the same routing rules for carbons and MAM. +1 > 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. 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. Georg -- || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y? || ++ IRCnet OFTC OPN ||_________________________________________________||
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
