[Standards] Problems with IM Message Routing: Message Types

Georg Lukas georg at op-co.de
Sat Nov 11 11:01:04 UTC 2017

* Kevin Smith <kevin.smith at 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

> (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.


> 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

|| 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 ||_________________________________________________||
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20171111/a68e8053/attachment.sig>

More information about the Standards mailing list