[Standards] XEP-0198 minor enhancement
mwild1 at gmail.com
Tue Jun 2 22:23:47 UTC 2015
On 2 June 2015 at 22:11, John Williams (johnwi3) <johnwi3 at cisco.com> wrote:
> 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.
The use-case is: allowing the client to know which stanzas the server
received/didn't receive from a previous session (that has timed out).
The only state the server needs to store is the 'h' value (and
remember, this is an optional feature).
> 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.
No, resumption failed. The client has to start a new session.
> 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?
None of this. The modification Dave is proposing has no bearing on the
state of the stream. It is merely informative to the client, if
present. It allows the client to display to the user, or possibly
automatically re-send, messages that failed to be delivered.
Currently this is only possible to do accurately if the client resumed
before the server timed out the session.
More information about the Standards