This is also needed in the IoT world when small devices are connected.
where we have low level of computational power or are battery operated.
Also co posting to the IOT list
2013/10/27 Peter Saint-Andre <stpeter(a)stpeter.im>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/27/2013 10:16 AM, Spencer MacDonald wrote:
> > 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?
>
> This is one reason we defined SIFT:
>
> http://xmpp.org/extensions/xep-0273.html
>
> However, that might be more than we need. Perhaps something simpler
> would be of interest?
>
> Peter
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJSbZGaAAoJEOoGpJErxa2pg6UP/1PYUTvCcKo1kP5+7G+vRmkC
> h573r1zTOJg4qJQfUKs1I46tzkBmbL5295owf80KH0SsKJ5KTd2f+eqtOcJhj6w2
> 8PxYIFKkxj9uo4ToMlnv7SJHcl5dTIIQphrg4KxTUbf8VJ0G8KJz3zRw1hiHz2aM
> etiroiDL84KXLastoQnKKcpFleQfbhWHeSt9udvNSbWY7o+ySdOMfAUYZpfgy56+
> amYG1PDC9KPr32TEXzukoawdv/ILVrS51RGFsfMjTyaAKhIrhIEa3xm7+8IDlb1k
> kicuImmibo1Yd7kg+SD3ZVvSeR7yeYb6ENfHboLxIsxcPbzOg6PSVb1GQ0qYzEnE
> vZ5Z3wp2uvGt7HuedxXucbqHfJ+Io/oYId/d0n/fG8NXl+xWPa+Pb5+nkmD8zCa1
> l5pmHQkqAfVnvFItOEcYGi0whj9BXU1fngxAVRfHKfEMpFHPhd+XOLfOY9OzNgqw
> V5In7hT1yrtTUB9HMb3jeXUHNXb8aL26vI82MGKgXzUkm9+mprGVb4dcl1PMsizt
> 7QngxEX86rhUP2ByIQLxYW+9ptZ2B9xxkaHSnEFSZYKN/3Yo6ToEp8WwXGpDGbTD
> h0DUsdnpD8yO3IvzhfwW1pS3XQiE44x2/QsxjX9lrTIc0xCdbguotOWGIvM5HVfb
> ZMh/Yz5+oEaZTtFwX8FG
> =AyEt
> -----END PGP SIGNATURE-----
>
--
*Regards*
Joachim Lindborg
CTO, systems architect
*Keynote speaker at GoGonet live IPv6 conferens 12-14
november<http://gogonetlive.com/gogonetlive-agenda.asp>
*
Sustainable Innovation AB
Adress: Box 55998 102 16 Stockholm
Besöksadress: Storgatan 31 (Malmgården)
Email: Joachim.lindborg(a)sust.se, www.sust.se
linkedin: http://www.linkedin.com/in/joachimlindborg
Tel +46 706-442270
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
Hello
Here's a XMPP & IoT presentation I held at IEEE WG meeting. Extensions for safe and interoperable communications for the Internet of Things:
http://prezi.com/esosntqhewhs/
The aim was to discuss the Interoperability XEP (work in progress), but previous IoT-related XEPs were also presented.
Best regards,
Peter Waher
Peter Waher, Gerente General
[cid:image001.png@01CED18C.B11FC900]
Clayster Chile S.A.
Calle Blanco 1623, oficina 1402
Valparaíso, Chile
Teléfono: +56-32-2122533, +56-9-64324113
Nextel CD: 46*206*14419
Skype: peter.waher
Correo electrónico: peter.waher(a)clayster.com<mailto:peter.waher@clayster.com>
Twitter: https://twitter.com/ClaysterLabs, https://twitter.com/PeterWaher
LinkedIn: http://se.linkedin.com/in/peterwaher/
La información contenida en esta transmisión es confidencial y propietaria y no puede ser utilizada por personas distintas a su(s) destinatario(s). La utilización no autorizada de la información contenida en este correo por cualquier forma puede ser sancionada criminalmente de conformidad con la Ley Chilena e infringir normas sobre propiedad intelectual, propiedad industrial o secretos comerciales. Si ha recibido esta transmisión por error, por favor destrúyala y notifique al remitente telefónicamente, con cobro revertido o vía e-mail. Atendido que no existe certidumbre que el presente mensaje no será modificado como resultado de su transmisión por correo electrónico CLAYSTER Laboratorios Chile Limitada, no será responsable si el contenido del mismo ha sido modificado. Visite nuestra página WEB www.clayster.com<http://www.clayster.com/>.
The information contained in this transmission is confidential and proprietary and it cannot be used by any person other than its addressee(s). Unauthorized use of the information contained in this transmission in any form may be punished under Chilean Law and be considered a copyright, industrial property or trade secrets infringement. If received in error, please destroy it and notify the sender by calling collect or e-mail. As there can be no certainty that this message will not be modified as a result of its transmission via e-mail, CLAYSTER Laboratorios Chile Limitada shall not be responsible if the content of the same has been modified. Visit www.clayster.com<http://www.clayster.com/>.
FYI
-------- Original Message --------
Subject: [FOSDEM] CFP for Internet of Things Devroom
Date: Fri, 11 Oct 2013 12:18:17 +0200
From: Pieter Hintjens <ph(a)imatix.com>
To: fosdem(a)lists.fosdem.org, devroom-managers(a)lists.fosdem.org
Next February 2nd, we're organizing a [http://fosdem.org FOSDEM]
devroom for the Internet of Things. We're now calling for proposals.
Do you have an interesting project you'd like to present to 5,000+
free and open source developers?
If you have a project you'd like to present, or a talk you want to
give, please submit it via [https://penta.fosdem.org/submission
FOSDEM's Pentabarf] web tool. You will create an account (if you don't
have one from a previous year), and select the "Internet of Things
devroom" as the track.
We'll discuss and select talks on
[https://groups.google.com/forum/?hl=en#!forum/iot-devroom the Google
iot-devroom group]. Anyone who wants to join in the review process,
please just join that group. The organizers will take the final
decision on talks if there is no consensus.
We'll look for talks that include a technical/developer oriented
discussion or showcase covering one or more of the following topics:
* FOSS solutions for machine-to-machine communication on small embedded
devices.
* Distributed FOSS applications in any field of interest for
autonomous/self-controlled devices, (e.g. domotics, automotive, etc.
* Presentation of embedded devices with one or more possibilities to
join a network.
* Infrastructure related (TCP/IP, mesh networking, message queuing,
cross-layer solutions).
* Real-life problematics and their solution (Cost of maintenance,
power management, reachability).
* Interoperability solutions for heterogeneous applications, devices,
protocols, media.
All presentations must be fully FOSS, and related to software development.
The devroom will last one day, with a welcome at 9:45, and talks from
10:00 to 17:00. Provisionally, talks will last 25 minutes each, and we
will have a brainstorming / hacking session from 15:30 to 17:00.
The goal is to make this devroom as interesting and diverse as
possible, which means we will favor talks that contrast each other.
For the hacking session, proposals are welcome. We will consider
running multiple parallel hacking sessions during the same time.
The deadline for submissions is December 1st. If you submit late, your
talk may still be considered but will have to be exceptionally
interesting. The program will be finalized by December 30th.
_______________________________________________
FOSDEM mailing list
FOSDEM(a)lists.fosdem.org
https://lists.fosdem.org/listinfo/fosdem
