Hi Yes...I understood from the previous message that, for a constrained device, the implementation would essentially be locked down, to support only the specific xml protocol snippets that the device would support, which could significantly reduce the code ROM requirements, compared with a full EXI implementation that could support a more dynamic and flexible xml/schema processing model
Sent from my Verizon Wireless 4G LTE Smartphone -------- Original message -------- From: Peter Waher <[email protected]> Date: 03/15/2013 11:09 AM (GMT-08:00) To: XMPP Standards <[email protected]> Cc: [email protected],Randy Turner <[email protected]> Subject: RE: [Standards] Proposal for including EXI in XMPP Dear Randy Constrained here, apart from the normal English definition, could mean any reason why they would not otherwise be able to use XMPP as a transport protocol. One constraint could be allowable packet size. Wireless sensor networks (for example over 6LowPan) can only send small packets. So, it might well be that compressing the stanzas would enable them to send control messages vs. not being able to send them (successfully). Partitioning small messages into several parts in otherwise congested WSN might not be a practical option. Another constraint may be available RAM for buffers. While they may actually have plenty of ROM to store code, schema files, etc., RAM might be limited. Furthermore, efficient code can be automatically generated from schema files, so writing and reading EXI can be surprisingly efficient (both in size and processing power), if strict schema compression is used. Sincerely, Peter Waher -----Original Message----- From: Randy Turner [mailto:[email protected]] Sent: den 15 mars 2013 12:08 To: XMPP Standards Cc: [email protected] Subject: Re: [Standards] Proposal for including EXI in XMPP I was curious what the definition of "constrained" is ? EXI does produce a compact representation of XML (which is good if "constrained" is meant to apply to the amount of any output XML representation) But I think the executable code size of an EXI implementation might not be appropriate for a "light switch", "low-power sensor" or other similarly constrained memory device. But I guess it depends on the definition of "constrained" memory? (both RAM and non-volatile code space) -- especially since there may be a dual-stack IPv4/IPv6 stack, HTTP module, operating system, and other code already assumed to be on the constrained device. Randy On Mar 15, 2013, at 3:39 AM, Peter Saint-Andre <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 3/14/13 6:50 PM, John Schneider wrote: >> Peter, >> >> Its really great to see some momentum on this! Thanks very much for >> the energy you are putting into it. This is something in which I've >> had a long-running interest. In fact, I think Peter and I first >> talked about it back in 2005 (yikes!). Although I'm not sure Peter >> was completely sold on the idea at the time (broccoli ice cream >> anyone? [1]), he was gracious enough to help us get the XMPP EXI use >> case together [2] and even started an early draft [3]. Thanks Peter! >> ;-) > > One must keep an open mind. > >> Here at work, we have incorporated EXI into various XMPP solutions to >> support our Efficient XML users (e.g., to enable XMPP on aircraft). >> So, I'm very interested in following your progress. >> Please keep me in the loop as you move forward. I'd be very happy to >> help if I can. > > Yesterday at IETF 86 I had a productive chat with Yusuke Doi on this > topic. He helped me see that, just as we've defined HTTP bindings > (BOSH / WebSocket) for web endpoints like browsers, an EXI binding > would expand the universe of XMPP usage to constrained devices of the > kind that might otherwise use protocols like CoAP. > > Although I've not yet had time to read the new EXI proposal in detail, > I shall do so as soon as possible and provide comments on the > [email protected] list. > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJRQvpOAAoJEOoGpJErxa2pcfMQAKPeGWf+02AZmrGff3hA+H+I > g9INO8/62pukrj7utK1BuBRkersMXLxJUm3TIWnfQuqBXe/zgbkcvms42GHvu9+R > J5/37i4Mq+lKHdI/XyPtLnn6/3YjriotGwl2ZKpvxvD4b66F0BL0jUaCoZx6jpPm > N7QNYtX51uzpU7ofWfWf/IhzXOKNgFaB4u/EVcJp4+Gu8UInnualtkeq/ZHQwEiG > SkpE36LfuCy31cXEd4Oankv30ywOwUmh2ETwzLyeDPzPfhFVdjgNkabnJr1J/H/n > 8GnZNIEgzx/hFTGUetHkhMaHQfqGAVtEjWsFIYStugQnBRS6pP/V+fEME4DEMw64 > FLf9sF8sJBSP4/e62Z8myog/eVWrYiGNjGRu8qvo+fNmD4Fn+/qhHA/SvYcN+ZXN > yqeqzAJty+A+oxduPCN+bbP93grroSjs1qmN7ybsu+bO9hJiDCs3IIsJPOBZrr9Y > uQ+an33QWIAEsPRO4VKQlFYxHmh6QRjUPTCeFyFemuD7dyLk3UBXNikMUrvcFwBa > uj0jAyC0tIf0w/Qm5RPtzVIV02On1jKRjHGoNLjEnjf0nusmdqzEZMq3mIL95PzL > g1WYu5ASmDVAzWUuwvhYYMGraAQbqrnj5+QgiaAEHulpjl43ut7FHYslD7uyPvFp > E8efql+LqrpSRCjgvZ8e > =jNUK > -----END PGP SIGNATURE----- >
