[Standards] Proposed XMPP Extension: Stream Compression with Efficient XML Interchange

Tomasz Sterna tomek at xiaoka.com
Sat Feb 16 19:55:36 UTC 2008


Dnia 2008-02-16, So o godzinie 11:18 +0100, Fabio Forno pisze:
> Did some homework about EXI. I don't know if handling it as a
> compression method it's the best way, since it forces the client to
> have both an xml parser just for the first stanzas before features
> (indeed it could be done with some string search, but it's an ugly
> hack) and the exi parser. EXI streams, instead, have a starting header
> whose first two bits allow understanding whether the data is encoded
> with EXI or text xml, so a client wanting to use it could open the
> stream directly with EXI. If the servers doesn't understand it can
> reply with an error.

One does not exclude the other.
Once you have EXI implemented XEP-0138 extension, it would be trivial to
detect EXI header on incoming streams and enable EXI using the same
implementation.

wpjabber server does similiar for SSL. It supports SSL wrapped streams
by detecting compressed stream instead of listening on special wrapper
port.


> AFAIK in RFC 3920 there aren't restrictions in this sense.

And it's good. Transport layer should be transparent.


-- 
  /\_./o__ Tomasz Sterna
 (/^/(_^^' http://www.xiaoka.com/
._.(_.)_   im:smoku at xiaoka.com





More information about the Standards mailing list