[Standards] XEP-0198 minor enhancement

John Williams (johnwi3) johnwi3 at cisco.com
Tue Jun 2 21:11:27 UTC 2015


Comments inline

== John (Jock) Williams ==

From: Standards [mailto:standards-bounces at xmpp.org] On Behalf Of Dave Cridland
Sent: Friday, May 29, 2015 1:01 PM
To: XMPP Standards
Subject: [Standards] XEP-0198 minor enhancement

What if, on a resumption failure, a server could include the 'h' attribute, to mean "I can't actually resume your state, but I did get all the stanzas up until H".

I think this allows servers to hold onto this small amount of state for considerably longer than it's desirable to keep a disconnected session live, and it also makes a halfway house between ack-only and full resumption possible for other servers.

Thoughts?

Jock>  Dave, could you provide some clarification on the use cases, and what the expectations should be if the server supports this new feature and a client choses to take advantage of it.

Jock> when a <resume> response comes back as <failed>, the client can <bind> and start a new session (with today’s xep-0198). With this addition are you giving the client the opportunity to retry the resume this time using the server supplied ‘h’? Doing so means the client is resuming knowing there are dropped stanzas.

Jock> Dropped stanzas imply missed messages, and missed state changes (eg: contacts & presence, chatroom rosters, pubsub nodes updates).

Jock> Are you thinking of tolerating any consequences of these state errors in exchange for a faster re-connect (and less buffering overhead in the server)? Are expecting the client to make efforts to validate it’s state? Would you anticipate smarter servers that can orchestrate protocol soon after the resume, such that the clients state becomes current. Is this aimed at specialized xmpp applications?


Also, do you think we could add this attribute without a version bump?

Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150602/95187a3c/attachment.html>


More information about the Standards mailing list