[Standards-JIG] Re: XMPP bandwidth compression

Jean-Louis Seguineau/EXC/ENG jean-louis.seguineau at antepo.com
Tue Jul 13 11:56:11 UTC 2004


1/ Correct, and it is slightly extended in RFC 1951. I do  not have any real
problem with the name, just sounded odd to me.

2/ What I meant with inconsistency is 

<stream:features>
  <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
  <compression xmlns='http://jabber.org/features/compress'>
    <method>zlib</method>
  </compress>
</stream:features>

Where the opening tag and the closing tags are different. From what you
said, I suppose the closing tag must be </compression> then.

I'm OK with the rest.

Jean-Louis

-----Original Message-----
From: Joe Hildebrand [mailto:hildjj at gmail.com] 
Sent: Monday, July 12, 2004 7: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




More information about the Standards mailing list