Re: [Standards] XEP-0198 minor enhancement
Comments inline == John (Jock) Williams == From: Standards [mailto:standards-boun...@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.
Re: [Standards] XEP-0198 minor enhancement
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
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, 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. Regards, Matthew
