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
