[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.
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:
More information about the Standards