[Standards] XEP-0198 minor enhancement

John Williams (johnwi3) johnwi3 at cisco.com
Tue Jun 2 23:48:28 UTC 2015

Thanks for the clarification.
Hum,.. not sure how useful this is, since a lot of stanzas are of little long term interest (eg: chatstates), but as you describe it seems pretty harmless.

== John (Jock) Williams ==

-----Original Message-----
From: Standards [mailto:standards-bounces at xmpp.org] On Behalf Of Matthew Wild
Sent: Tuesday, June 02, 2015 3:24 PM
To: XMPP Standards
Subject: Re: [Standards] XEP-0198 minor enhancement

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, 
> Jock> 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 
> Jock> <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 
> Jock> 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 mailing list