[Standards] XEP-0322: EXI for constrained processing environments

Peter Waher Peter.Waher at clayster.com
Tue Jun 30 17:40:39 UTC 2015

Hello Rick

Thanks for your input. For small devices, that do not wish to (or cannot)
perform a dynamic handshake, there's the concept of quick configurations
(§2.6). With a quick configuration ID, the entire setup is predefined. It
can be defined, either in-band using a normal handshake, as described
earlier, perhaps by a more powerful device, or out-of-band, by manual
configuration of the server.

Best regards,
Peter Waher

-----Ursprungligt meddelande-----
Från: Rick van Rein [mailto:rick at openfortress.nl] 
Skickat: den 26 juni 2015 01:42
Till: XMPP Standards
Ämne: [Standards] XEP-0322: EXI for constrained processing environments


I was happy to run into XEP-0322, explaining a path of integration for the
compact XML representation of EXI.

The fully specified path assumes starting off with fullblown XML and then
switching to EXI; this is a scenario that would work when the viewpoint is
saving bandwidth.  Another usecase, where EXI serves the relative simplicity
of a client, is not really dealt with under the usual clarity.

I am thinking of constrained processing environments, such as clients on
microcontrollers.  These may want to use EXI to avoid having to deal with
the full XML notation, and they would most certainly not be serviced if they
have to go through an initial handshake based on XML. 
Although 2.4 gives some ideas and possibilities, its style sounds
informative ("ex." and "e.g.") rather than normative, which means that there
is non real certainty to be drawn.  I am writing to emphasise that this
should IMHO be cleared up before finalising this XEP.

As for the EXI cookie, is it an idea to use a processing instruction and/or
XML declaration that would be sent to the server?  That would be in line
with common XML syntax without adding the burden of XML parsing onto the
(constrained) client.  A few forms could be used, and in all honesty, may be
better standardised as part of EXI than as part of
XEP-0322 because it would occur everywhere EXI is used:

<?xml version="1.0" syntax="exi"?>     (illegal 1.0 syntax)
<?xml version="1.0-exi"?>   (illegal 1.0 syntax)
<?xml version="1.0" exi="1.0"?>    (illegal 1.0 syntax)
<?xml version="1.1"?>    (breaks with 1.0 requirements)
<?exi version="1.0"?>     (after <?xml...?> -- upon recognition, respond
with the same string, would otherwise ignored?)

Ref: http://www.w3.org/TR/REC-xml/#sec-pi and

This approach would save from specifying another port, and it would be easy
to send/process in a constrained environment.  Adding NS negotiation might
be possible along the same lines, but would already be more complex.  Still,
not having to build an XML processor to be able to switch to EXI seems like
a really good usecase to me.

I hope this is useful!


More information about the Standards mailing list