I missed that XEP-0273 as it is Deferred, Is it Deferred for any particular reason or just because of inactivity?
Regards Spencer On Mon, Oct 28, 2013 at 3:47 PM, Peter Waher <[email protected]>wrote: > Hello Spencer**** > > ** ** > > As Joachim mentioned, there is interest from the Internet of Things (IoT) > community to create such a XEP. In fact, it is already planned because > there’s a need, but it is yet to be written. Anybody interested in > co-authoring such a XEP is welcome to contact me.**** > > ** ** > > The envisioned XEP however is not IOS specific, but rather concerns > battery-powered sensors, but can be applied to sensors in resource > constrained networks (where bandwidth is constrained). The same solutions > can be applied in the IOS case you mentioned, since it can be seen as a > resource constrained device, when the application runs in the background.* > *** > > ** ** > > Peter Saint-André mentioned that the deferred XEP 0273 could solve part of > this issue, by permitting the filtering of certain messages.**** > > ** ** > > Forwarding of offline stanzas (XEP-0160) can also be used. I.e. the > bandwidth can be controlled by the device, using the presence as an > indication when the server can send information. (Here battery powered > sensors often go into sleep mode and wake up regularly to perform a task. > They can only receive messages when awake.)**** > > ** ** > > Other solutions can be envisioned, for instance using presence=away to > signal clients restricting them to send important messages only, queuing > not as important messages for later when online, etc.**** > > ** ** > > Ideas are welcome.**** > > ** ** > > Best regards,**** > > Peter Waher**** > > ** ** > > ** ** > > *From:* Spencer MacDonald [mailto:[email protected]] > *Sent:* den 27 oktober 2013 13:17 > *To:* XMPP Standards > *Subject:* [Standards] Standard for Throttling/Queueing Stanzas**** > > ** ** > > I have observed from the XMPPFramework mailing list and Github issues, > that one of the biggest problems that iOS Developers have with including > XMPP (alongside VoIP) in their iOS apps, is that their apps get terminated > for receiving to much data while in the background.**** > > ** ** > > There are proprietary solutions that allow an XMPP client to inform the > XMPP Server that the app is going to be put in the background. The XMPP > Server then queues the stanzas until the client in with the XMPP Server, > which on iOS is less than or equal to 10 minutes. Some solutions also > filter out presence packets so only the most recent one is queued for each > jid.**** > > ** ** > > I appreciate that the problem is iOS specific, but the solution can be > generic.**** > > ** ** > > Is this something that should be incorporated into an XEP? or is there > already a solution for this issue?**** > > ** ** > > Regards**** > > ** ** > > Spencer**** >
