[Standards-JIG] Re: XMPP bandwidth compression

Jean-Louis Seguineau/EXC/ENG jean-louis.seguineau at antepo.com
Mon Jul 12 22:59:14 UTC 2004


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





More information about the Standards mailing list