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:spencer.macdonald.other@gmail.com]
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