[Standards] certification etc.

[Peter Saint-Andre]

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"?

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

> 3) in many environments (particularly with
> SATCOM), the TLS connect/reconnect costs are simply to expensive.

So deploy stream compression in those environments.

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

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/a63edadf/smime.bin