[Standards-JIG] XMPP bandwidth compression
Fletcher, Boyd C. J9C534
Boyd.Fletcher at je.jfcom.mil
Thu Jul 1 02:16:22 UTC 2004
I just had a long telecon with one of the key players on the W3C Binary XML group. They are looking at a solutions appearing in 18-24 months assuming the W3C board approves going forward. Even then its probably likely the compression will be table lookup based (covert tags to table values) and do some type of data element compression. there are a lot of folks in the W3C that are adamant against having any type of binary translation for XML.
I'm not advocating a method to compress XML specially (like in the expect W3C approach). it would be a stream based compression, similar to the way TLS encrypts a stream of data. it would have essentially no knowledge of what the stream contents are.
> -----Original Message-----
> From: standards-jig-bounces at jabber.org
> [mailto:standards-jig-bounces at jabber.org] On Behalf Of Bob Wyman
> Sent: Wednesday, June 30, 2004 7:26 PM
> To: 'Jabber protocol discussion list'; jean-louis.seguineau at antepo.com
> Subject: RE: [Standards-JIG] XMPP bandwidth compression
> Boyd Fletcher wrote:
> > What does everything think about starting up a small
> working group to
> > small definitely the XMPP compression problem?
> As I mentioned in an earlier mail, W3C is working on
> this issue and there are working groups in ITU/ISO focused on
> the issues as well. The problem is not XMPP specific. These
> problems of size and parsing speed are general to ALL systems
> that use XML. Just as Jabber doesn't define XML, it shouldn't
> be defining "compressed," "binary," or "alternate" forms of XML.
> There should be a division of labor here... It would not be
> good if XMPP ended up defining a non-standard solution
> without some very distinct benefit.
> Something that *would* be useful, is an effort that
> generated a clear description of the requirements and
> constraints that exist in the domain that XMPP addresses.
> Such information would be very helpful in ensuring that XMPP
> issues and needs were understood by others and thus addressed
> in the process of clearing up the general issue. Also, it
> would make a great deal of sense to build up and characterize
> a stream "corpus" or set of them, that represents "streams"
> of XMPP that could be used, when solutions are proposed, as
> test cases. (Basically, all proposed methods should be tested
> against the same streams of information.) We should have a
> basic chat corpus, a MUC corpus, a pubsub corpus, etc. --
> with each being as faithfully representative of real or
> expected streams as possible.
> XMPP should not attempt to "solve" this problem,
> however, the XMPP community should, I think, be active in
> helping to develop the solution to the overall problem.
> bob wyman
> Standards-JIG mailing list
> Standards-JIG at jabber.org
More information about the Standards