Re: [Standards] XEP-0138 vs. TLS compression

Peter Saint-Andre wrote: > Boyd Fletcher wrote: >> +1 for adding to the registry but we should remove LZW from XEP-138 and move >> its description text to registry. > > +1 to specifying the LZW usage in a separate spec, -1 to adding lots of > text to the registry. http://www.xmpp.org/extensions/i

Re: [Standards] XEP-0138 vs. TLS compression

On Thu Aug 30 21:29:13 2007, Jonathan Chayce Dickinson wrote: "EXI compression *combines* knowledge of XML with a *widely adopted, standard compression algorithm* to achieve higher compression ratios than would be achievable by applying compression to the entire stream." "which are individual

Re: [Standards] XEP-0138 vs. TLS compression

"EXI compression *combines* knowledge of XML with a *widely adopted, standard compression algorithm* to achieve higher compression ratios than would be achievable by applying compression to the entire stream." "which are individually well suited for standard compression algorithms" If EXI comp

Re: [Standards] XEP-0138 vs. TLS compression

Peter Saint-Andre wrote: Boyd Fletcher wrote: *SNIP* As far as I understand it, Efficient XML is more than just a compression algorithm. In order to prevent developer confusion, I think it might be helpful to write a XEP that describes how Efficient XML is to be used in the context of XMPP app

Re: [Standards] XEP-0138 vs. TLS compression

On 8/30/07 4:14 PM, "Peter Saint-Andre" <[EMAIL PROTECTED]> wrote: > Boyd Fletcher wrote: >> >> >> On 8/30/07 1:50 PM, "Peter Saint-Andre" <[EMAIL PROTECTED]> wrote: >> >> >> >> +1 for adding to the registry but we should remove LZW from XEP-138 and move >> its description text to registry

Re: [Standards] XEP-0138 vs. TLS compression

Boyd Fletcher wrote: > > > On 8/30/07 1:50 PM, "Peter Saint-Andre" <[EMAIL PROTECTED]> wrote: > >> Boyd Fletcher wrote: >>> I strongly disagree. I think that sends a confusing message to developers. >> How so? We have a registry. Refer to the registry. Do you think the XMPP >> Registrar creates

Re: [Standards] XEP-0138 vs. TLS compression

On 8/30/07 1:50 PM, "Peter Saint-Andre" <[EMAIL PROTECTED]> wrote: > Boyd Fletcher wrote: >> I strongly disagree. I think that sends a confusing message to developers. > > How so? We have a registry. Refer to the registry. Do you think the XMPP > Registrar creates these things for fun? ;-) >

Re: [Standards] XEP-0138 vs. TLS compression

nope. would result in larger message sizes in most cases On 8/30/07 2:56 PM, "Justin Karneges" <[EMAIL PROTECTED]> wrote: > On Thursday 30 August 2007 10:50 am, Peter Saint-Andre wrote: >> > As far as I understand it, Efficient XML is more than just a compression >> > algorithm. In order to prev

Re: [Standards] XEP-0138 vs. TLS compression

On Thursday 30 August 2007 10:50 am, Peter Saint-Andre wrote: > As far as I understand it, Efficient XML is more than just a compression > algorithm. In order to prevent developer confusion, I think it might be > helpful to write a XEP that describes how Efficient XML is to be used in > the context

Re: [Standards] XEP-0138 vs. TLS compression

Boyd Fletcher wrote: > I strongly disagree. I think that sends a confusing message to developers. How so? We have a registry. Refer to the registry. Do you think the XMPP Registrar creates these things for fun? ;-) > Perhaps, we should remove all the compression algorithm references XEP-138 > and

Re: [Standards] XEP-0138 vs. TLS compression

I strongly disagree. I think that sends a confusing message to developers. Perhaps, we should remove all the compression algorithm references XEP-138 and have it only specify the core approach. Then create new XEPs for specific implementations: ZLIB, LZW, EXI, etc That is analogous to how the

Re: [Standards] XEP-0138 vs. TLS compression

On Aug 30, 2007, at 9:46 AM, Peter Saint-Andre wrote: we can add a reference from XEP-0138 to the new spec. We already will. 138 has a reference to the registry. The registry will have a reference to the new XEP. 138 should not be changed at all.

Re: [Standards] XEP-0138 vs. TLS compression

Joe Hildebrand wrote: > > On Aug 29, 2007, at 7:03 PM, Boyd Fletcher wrote: > >> I was thinking we would just add it to XEP-138 instead of writing a >> new XEP. > > I'm really opposed to changing XEPs to add new features, particularly > ones that are: > a) widely deployed > b) designed to be ext

Re: [Standards] XEP-0138 vs. TLS compression

On Aug 29, 2007, at 7:03 PM, Boyd Fletcher wrote: I was thinking we would just add it to XEP-138 instead of writing a new XEP. I'm really opposed to changing XEPs to add new features, particularly ones that are: a) widely deployed b) designed to be extensible, with a registry to define th

Re: [Standards] XEP-0138 vs. TLS compression

They do have a testing framework out, I'm not sure what that is. It's too big for me to download. Maybe someone could download it and evaluate how well the format works. Boyd Fletcher wrote: I was thinking we would just add it to XEP-138 ins

Re: [Standards] XEP-0138 vs. TLS compression

I was thinking we would just add it to XEP-138 instead of writing a new XEP. I believe some of the folks on the W3 committee are working on an implementation of EXI. On 8/29/07 6:52 PM, "Joe Hildebrand" <[EMAIL PROTECTED]> wrote: > > > On Aug 29, 2007, at 7:00 AM, Fletcher, Boyd C. CIV US USJ

Re: [Standards] XEP-0138 vs. TLS compression

Joe Hildebrand wrote: On Aug 29, 2007, at 7:00 AM, Fletcher, Boyd C. CIV US USJFCOM JFL J9935 wrote: *snip* Off-topic: are there any open source implementations of EXI yet? Because it's hot out the bakery and still warm and frothy: waiting for hungry developers to get a poke at it. I

Re: [Standards] XEP-0138 vs. TLS compression

On Aug 29, 2007, at 7:00 AM, Fletcher, Boyd C. CIV US USJFCOM JFL J9935 wrote: Speaking of compression, I think we should consider adding the w3's efficient xml interchange (exi) support to xep-138. The testing results I've seen for EXI indicate that in many circumstances it is quite a

Re: [Standards] XEP-0138 vs. TLS compression

Mridul Muralidharan wrote: Jonathan Chayce Dickinson wrote: *snip* There are enough extensions to supporting binary content inband in xml, the point is about interoperability & adoption - not whether it can or cant be done. A few specs have pulled this off like wbxml, etc ... and have wider

Re: [Standards] XEP-0138 vs. TLS compression

Jonathan Chayce Dickinson wrote: Fletcher, Boyd C. CIV US USJFCOM JFL J9935 wrote: Speaking of compression, I think we should consider adding the w3's efficient xml interchange (exi) support to xep-138. The testing results I've seen for EXI indicate that in many circumstances it is quite a bit

Re: [Standards] XEP-0138 vs. TLS compression

Fletcher, Boyd C. CIV US USJFCOM JFL J9935 wrote: Speaking of compression, I think we should consider adding the w3's efficient xml interchange (exi) support to xep-138. The testing results I've seen for EXI indicate that in many circumstances it is quite a bit better than zlib or tls compress

Re: [Standards] XEP-0138 vs. TLS compression

excuse my typos. -Original Message- From: [EMAIL PROTECTED] <[EMAIL PROTECTED]> To: XMPP Extension Discussion List Sent: Tue Aug 28 18:01:07 2007 Subject: Re: [Standards] XEP-0138 vs. TLS compression Tomasz Sterna wrote: > While implementing XEP-0138 for jabberd2 I have disco

Re: [Standards] XEP-0138 vs. TLS compression

On Tue Aug 28 21:13:03 2007, Tomasz Sterna wrote: The TLS standard (or SSLv3) allows the integration of compression methods into the communication. The TLS RFC does however not specify compression methods or their corresponding identifiers, so there is currently no compatible way to integrate com

Re: [Standards] XEP-0138 vs. TLS compression

It should offer stream compression anyway since its own support for TLS compression doesn't help a lot if the connecting server doesn't support it or has it implemented otherwise. Like the openssl page said, compression is not described in the RFC so it's up to the implementations to deal with it a

Re: [Standards] XEP-0138 vs. TLS compression

Tomasz Sterna wrote: > While implementing XEP-0138 for jabberd2 I have discovered the following > note: > > http://www.openssl.org/docs/ssl/SSL_COMP_add_compression_method.html > > NOTES > The TLS standard (or SSLv3) allows the integration of compression > methods into the communication. The TLS

[Standards] XEP-0138 vs. TLS compression

While implementing XEP-0138 for jabberd2 I have discovered the following note: http://www.openssl.org/docs/ssl/SSL_COMP_add_compression_method.html NOTES The TLS standard (or SSLv3) allows the integration of compression methods into the communication. The TLS RFC does however not specify compress