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:[email protected]] Skickat: den 26 juni 2015 01:42 Till: XMPP Standards Ämne: [Standards] XEP-0322: EXI for constrained processing environments Hello, 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 http://www.w3.org/TR/REC-xml/#sec-prolog-dtd 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! Cheers, -Rick
