[Standards] Call for Experience: XEP-0198: Stream Management

Jonas Schäfer jonas at wielicki.name
Sat Feb 22 09:49:33 UTC 2020

On Donnerstag, 20. Februar 2020 20:57:48 CET Andrew Nenakhov wrote:
> What other problems we have with reconnection? Roster and presences. Roster
> is mostly not a problem thanks to roster versioning. Presences. It's a big
> problem I'm still on the fence for this one. Receiving all presence
> information on each reconnect is not the ideal solution. I'm thinking of
> using a presence versioning, akin to roster versioning, or maybe to
> eschewing presences at all. The idea of 'always on' messaging has some
> merit to it with always connected modern mobile devices, however,
> personally, I am not ready to give up on green light bulbs on contacts just
> yet.

Interestingly, stream management can be thought of as a kind of presence, 
message and even IQ "versioning". If we think of stanzas as transferral of 
state, the initial state before the stream was established + the counters 
define the state at resumption on both sides.

The re-transmission of lost stanzas during resumption is catching up on lost 

Instead of dropping SM and introducing explicit versioning protocols 
everywhere, wouldn’t it make more sense to increase SM timeouts to something 
useful for mobile clients? 

That leaves the problem that a server may not want to hold an indefinitely 
growing stanza queue for a client for a long time. To make this less 
expensive, we could define a sloppy fallback version of SM which the server is 
allowed to degrade to once it lost its patience with the client. That sloppy 
version could have relaxed requirements compared to normal SM or even normal 
XMPP streams, but in a way which isn’t hurtful (i.e. delivers an experience 
similar to a full reconnect, but potentially faster and with less traffic). 
For example:

- Deduplicate presence stanzas
- Relax stanza ordering requirements between presences and message stanzas, so 
that message stanzas can be replayed from an archive on resumption
- Reply to IQ requests as well as XEP-0409 directly-addressed (ephemeral) 
messages with an error once the sloppy period starts

Much of this sounds familiar to thoughts I think MattJ had about per-device 
offline messages, just plus some defined handling of offline sessions and 
presence replay.

kind regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200222/9345567a/attachment.sig>

More information about the Standards mailing list