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.
boyd -----Original Message----- From: [EMAIL PROTECTED] <[EMAIL PROTECTED]> To: XMPP Extension Discussion List <[email protected]> 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 <[EMAIL PROTECTED]> 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: _xmpp-client-exi._tcp.example.com Peter -- Peter Saint-Andre https://stpeter.im/
