Re: [Standards] XEP-0198 minor enhancement
On 03.06.2015 01:48, John Williams (johnwi3) wrote: 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. Consider the XMPP user walks into the subway without GSM reception scenario which leads to a failed/ once the user's device is back online. Without 'h' in failed/ the client is unable to tell which messages have been received by the server right before the signal was lost. With 'h', the client is able to display some more visual feedback about the state of outgoing messages. tl;dr: It's useful for mobile clients if you slightly missed the max resumption time. - Florian signature.asc Description: OpenPGP digital signature
Re: [Standards] XEP-0198 minor enhancement
On 3 June 2015 at 00:48, John Williams (johnwi3) john...@cisco.com wrote: 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. So as things stand, if a TCP virtual circuit is lost (due to, for example, wandering out of signal), then the choices are: a) Drop the session (the only option without XEP-0198). b) Keep the session live (with XEP-0198). If a server keeps the session live, it's got to keep the state (things like current presence broadcast, directed presence, and so on). In addition, other users will see the session as live, and while PSA might help indicate this by annotating the presence, it's still a bit weird. Fine for handover periods, but not so good across a half-hour underground train journey. It's worse if the client never resumes, of course. So servers in effect have to timeout such zombie sessions, and it needs to happen within a few minutes before the UX issues pile up. Whether a session is dropped immediately or later, a server can essentially redeliver the outstanding stanzas; risking duplication. On the other hand, when the session is dropped, stanzas that are in flight from the client are lost. Many of these may well be unimportant in a non-resumption case, but it's useful for a client to know if that message saying I'm just jumping on the train, be there in 30 actually got as far as the server. What this minor addition does is allow the server to tell a client, That message got through, but I don't have the rest of your session state - you'll have to start a new one. In principle it could also figure out which of the pending offline messages the client already has and discard them, too. The cost for this is storing one server-chosen string, plus one or two integers - that volume of data can be persisted fairly cheaply, and possibly even offline. Think of it as a failure with benefits. Dave.
Re: [Standards] XEP-0198 minor enhancement
On 29 May 2015, at 21:00, Dave Cridland d...@cridland.net wrote: 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? Sounds eminently sensible. Also, do you think we could add this attribute without a version bump? I’d like to say yes, but I think the answer’s no. /K
[Standards] Proposed XMPP Extension: Nonzas (are not Stanzas)
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Nonzas (are not Stanzas) Abstract: This specification defines the term Nonza, describing every top level stream element that is not a Stanza. URL: http://xmpp.org/extensions/inbox/nonza.html The XMPP Council will decide in the next two weeks whether to accept this proposal as an official XEP.
[Standards] Proposed XMPP Extension: Unique and stable message IDs
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Unique and stable message IDs Abstract: This specification describes unique and stable IDs for message stanzas. URL: http://xmpp.org/extensions/inbox/mid.html The XMPP Council will decide in the next two weeks whether to accept this proposal as an official XEP.
Re: [Standards] XEP-0198 minor enhancement
Thanks Florian Dave, I made a major misunderstanding, and this now makes good sense. I was thinking the 'h' value in the failed stanza was the servers count of stanzas received by the session for delivery **to** the client. That is to say a resume using that value would require re-transmission of zero stanzas. I thought you were trying to make resume work with dropped packets - which could open up a can of worms. What you have in mind is that’s oldh is the servers count of packets received by the session **from** the client. As such it's just a way of allowing the client to know which stanzas made it to the server before the connection dropped. I can see that could be a useful enhancement. == John (Jock) Williams == -Original Message- From: Standards [mailto:standards-boun...@xmpp.org] On Behalf Of Florian Schmaus Sent: Wednesday, June 03, 2015 12:35 AM To: XMPP Standards Subject: Re: [Standards] XEP-0198 minor enhancement On 03.06.2015 01:48, John Williams (johnwi3) wrote: 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. Consider the XMPP user walks into the subway without GSM reception scenario which leads to a failed/ once the user's device is back online. Without 'h' in failed/ the client is unable to tell which messages have been received by the server right before the signal was lost. With 'h', the client is able to display some more visual feedback about the state of outgoing messages. tl;dr: It's useful for mobile clients if you slightly missed the max resumption time. - Florian
