[Standards-JIG] Re: XMPP bandwidth compression

Joe Hildebrand hildjj at gmail.com
Thu Jul 15 06:41:30 UTC 2004


Maybe.  Using x:data is a layering violation, but if it's needed, it's
as good as anything else.

Do we need to negotiate anything for zlib?  If not, then we can wait
to add this on a per-method basis.


On Mon, 12 Jul 2004 21:26:34 -0700, JD Conley <jconley at winfessor.com> wrote:
> My idea of using an x:data configuration form hasn't received any
> comments.  :)  Most network applications that do compression (SSH, etc)
> allow you to set the compression level as to optimize for your
> particular environment.  X:data seems like a very easy way to accomplish
> that for the incoming stream, if the receiver allows it.
> 
> JD
> 
> 
> 
> > -----Original Message-----
> > From: Joe Hildebrand [mailto:hildjj at gmail.com]
> > Sent: Monday, July 12, 2004 4:54 PM
> > To: jean-louis.seguineau at antepo.com; Jabber protocol discussion list
> > Subject: Re: [Standards-JIG] Re: XMPP bandwidth compression
> >
> > Isn't Zip a TM?  ZLIB is a compression algorithm defined in RFC 1950,
> > so it should be fine to use.
> >
> > The compression -> compress -> compressed modulation is exactly what I
> > intended.  This was to make each state in the transition explicit,
> > with no possible ambiguity.
> >
> > On Mon, 12 Jul 2004 18:59:14 -0400, Jean-Louis Seguineau/EXC/ENG
> > <jean-louis.seguineau at antepo.com> wrote:
> > > Joe,
> > >
> > > Good starting point. In addition to the first comments you already
> > received,
> > > there seams to be some inconsistency in the examples where some use
> > > <compression> and some use <compress>. I believe you meant to use
> > <compress>
> > > everywhere?
> > >
> > > IFAIC I have some difficulty with using zlib as the name of the
> > compression
> > > method. I would be more inclined to use a more generic name such as
> zip.
> > > Zlib has a connotation to the library, not really the method, if you
> see
> > > what I mean.
> > >
> > > I believe that we do not need much more than that to get going.
> > >
> > > Jean-Louis
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > >
> > > Message: 1
> > > Date: Fri, 09 Jul 2004 11:15:08 -0600
> > > From: Peter Saint-Andre <stpeter at jabber.org>
> > > Subject: [Standards-JIG] Re: XMPP bandwidth compression
> > > To: standards-jig at jabber.org
> > > Message-ID: <pan.2004.07.09.17.15.06.398937 at jabber.org>
> > > Content-Type: text/plain; charset=ISO-8859-1
> > >
> > > On Wed, 07 Jul 2004 15:52:42 -0600, Peter Millard wrote:
> > >
> > > > On Wed, 7 Jul 2004 14:46:18 -0400, Fletcher, Boyd C. J9C534
> > > > <boyd.fletcher at je.jfcom.mil> wrote:
> > > >> yes. "now" would be an understatement. we trying to replace IRC's
> use
> > in
> > > >> DOD with a next generation protocol. The two obvious replacements
> are
> > > >> SIMPLE and XMPP. I'm rather partial to XMPP for a variety reasons
> but
> > we
> > > >> are running into bandwidth issues.
> > > >
> > > > Aren't the bandwidth issues even worse for SIMPLE? From the sample
> > packets
> > > > that I've seen, it would surely seem so.
> > >
> > > SIMPLE's bandwidth requirements are at least 3 or 4 times larger
> than
> > > XMPP's, and it will be a while before those folks have a protocol
> (let
> > > alone implementations) that will replace IRC.
> > >
> > > >> Since there seems to be two "camps" with respect to compression
> of
> > > >> XMPP, how about we use an approach like what Joe Hildebrand
> suggested
> > > >> for selecting the method then work on two JEPs for block
> compression
> > > >> and fast infosets?
> > >
> > > Joe has submitted a proposal for stream compression here:
> > >
> > > http://www.jabber.org/jeps/inbox/compress.html
> > >
> > > If the Council does not object, this will be published as a JEP in 7
> > days.
> > >
> > > > The drafts WILL not change at this poinrt (I'm talking about -core
> and
> > > > -im) as they have completed the IESG review, etc.
> > >
> > > Absolutely no more changes to those documents, other than nits that
> can
> > be
> > > addressed in Author's 48 hours.
> > >
> > > > I'm not sure how new
> > > > stream-features get registered. I presume this is handled by IANA
> now
> > > > (stpeter??).
> > >
> > > There is no IANA registry for this. However, the Jabber Registrar is
> > > maintaining such a registry:
> > >
> > > http://www.jabber.org/registrar/stream-features.html
> > >
> > > > This would have to be a new I-D, or just simply use a JEP
> > > > to document your own extensions. ie, there is nothing preventing
> you
> > > > from using a stream feature which is in your own (or the DOD's
> > > > namespace), and then documenting it someplace.
> > >
> > > See above for Joe's proposal. If someone wants to submit one for
> fast
> > > infosets, feel free.
> > >
> > > /psa
> > >
> > > _______________________________________________
> > > Standards-JIG mailing list
> > > Standards-JIG at jabber.org
> > > https://jabberstudio.org/mailman/listinfo/standards-jig
> > >
> >
> >
> > --
> > Joe Hildebrand
> > _______________________________________________
> > 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
> 


-- 
Joe Hildebrand



More information about the Standards mailing list