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-boun...@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) <john...@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. Regards, Matthew
