[Standards] certification etc.
stpeter at jabber.org
Wed Mar 28 04:48:08 UTC 2007
Gosh can you stop top-posting, it's confusing. :)
Fletcher, Boyd C. CIV US USJFCOM JFL J9935 wrote:
> -----Original Message----- From: standards-bounces at xmpp.org on behalf
> of Peter Saint-Andre Sent: Tue 3/27/07 11:31 PM To: XMPP Extension
> Discussion List Subject: Re: [Standards] certification etc.
> Fletcher, Boyd C. CIV US USJFCOM JFL J9935 wrote:
>> there are several reasons why stream compression is a better
>> approach that TLS:
>> 1) TLS with compression uses much more bandwidth that XMPP with
>> just stream compression
> Has anyone studied this? Do we have numbers? What is "much more"?
> 1) we did some calculations and testing a year or two ago. but we
> didn't do a report.
Wasn't asking for a report necessarily, just something more than bare
assertions. We like numbers around here. :)
>> 2) With TLS compression you can use something like the new
>> Efficient XML spec coming out of the W3.org which is better than
>> zlib (and faster!)
> That seems to be a vote for TLS compression?
> IMHO, Efficient XML = broccoli ice cream. :)
> What are we optimizing for here? What are the metrics? Did the W3C
> folks include XMPP use cases? (They asked me about it once but that
> was several years ago, and we don't have enough money to be W3C
> 2) why would that be a vote for TLS compression?
It seemed like you were saying "with TLS we can use Efficient XML and
that's a beautiful thing".
> Efficent XML is
> better than TLS compression and ZLIB. I'm hoping to add Efficient XML
> to the XEP for stream compression
Probably a separate spec, no? Especially since Efficient XML is not XML.
Or do you see it as an option for XEP-0138?
> onces its officially adopted by
> w3.org (which will be this year). Yes XMPP data was provided to
> w3.org for testing.
Cool. I have not followed that effort. Too much to do.
>> 3) in many environments (particularly with SATCOM), the TLS
>> connect/reconnect costs are simply to expensive.
> So deploy stream compression in those environments.
> 3) we do already ;)
So you're smart. But that doesn't mean it needs to be required in the
Basic protocol suite, which we want to apply to all manner of clients.
>> thus stream compression should be required for client and servers
>> in the intermediate specfiication.
> Not so fast with the "thuses". :) The consensus of those posting on
> the list so far seems to be for making stream compression recommended
> (or possibly required) for servers in Basic. But further discussion
> will lead to enlightenment, I presume.
> 4) agree further discussion is needed but i haven't heard any
> technical arguments on why stream compression should not be required
> for clients.
First, we will update the levels every year. So perhaps we will make
XEP-0138 support required in XMPP Server Basic 2008 and recommended in
XMPP Client Basic 2008, then required in XMPP Client Basic 2009 or whatever.
Second, I leave it up to the client authors to talk about technical
aspects of client development. I'm just the documentation guy. :)
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards