[Standards-JIG] XMPP bandwidth compression

Fletcher, Boyd C. J9C534 Boyd.Fletcher at je.jfcom.mil
Thu Jul 1 02:24:06 UTC 2004


almost forgot, one of the problems with table based lookup compression for XML is that advance knowledge of the xml schema is required. this isn't practical in XMPP since the server generally has little knowledge of the schema beyond the basic tags and sending the schema at the start of the transmission is too costly.

boyd 

> -----Original Message-----
> From: standards-jig-bounces at jabber.org 
> [mailto:standards-jig-bounces at jabber.org] On Behalf Of 
> Fletcher, Boyd C. J9C534
> Sent: Wednesday, June 30, 2004 10:16 PM
> To: bob at wyman.us; Jabber protocol discussion list; 
> jean-louis.seguineau at antepo.com
> Subject: RE: [Standards-JIG] XMPP bandwidth compression
> 
> 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.
> 
> boyd
> 
> 
> 
>  
> 
> > -----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
> > https://jabberstudio.org/mailman/listinfo/standards-jig
> > 
> > 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> https://jabberstudio.org/mailman/listinfo/standards-jig
> 
> 



More information about the Standards mailing list