[Standards] certification etc.

[Peter Saint-Andre]

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
> members.)

 > 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. :)

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20070327/2d737be7/smime-0001.bin