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

Fletcher, Boyd C. CIV US USJFCOM JFL J9935 Boyd.Fletcher at je.jfcom.mil
Mon Feb 18 13:23:21 UTC 2008

I'm not sure adding another is politically a good idea. Many large organizations (like governments) migrating to xmpp have complex rules and regs related to TCPIP ports and if non standard ports are used it causes big headaches.


-----Original Message-----
From: standards-bounces at xmpp.org <standards-bounces at xmpp.org>
To: XMPP Extension Discussion List <standards at xmpp.org>
Sent: Sun Feb 17 22:56:07 2008
Subject: Re: [Standards] Proposed XMPP Extension: Stream Compression with Efficient XML Interchange

Fabio Forno wrote:
> On Feb 15, 2008 11:21 PM, XMPP Extensions Editor <editor at xmpp.org> wrote:
>> The XMPP Extensions Editor has received a proposal for a new XEP.
>> Title: Stream Compression with Efficient XML Interchange
>> Abstract: This document specifies how to use Efficient XML Interchange (EXI) in XML stream compression.
>> URL: http://www.xmpp.org/extensions/inbox/compress-exi.html
>> The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP.
> 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.

Alternatively, we could define a new SRV record that would enable a
deployment to advertise a different port for the EXI service, such as:



Peter Saint-Andre

More information about the Standards mailing list