[Standards-JIG] Re: XMPP bandwidth compression

Tijl Houtbeckers thoutbeckers at splendo.com
Fri Jul 9 22:02:56 UTC 2004


On Fri, 09 Jul 2004 11:15:08 -0600, Peter Saint-Andre <stpeter at jabber.org>  
wrote:

>
> Joe has submitted a proposal for stream compression here:
>
> http://www.jabber.org/jeps/inbox/compress.html
>

 From the (proposed) JEP:

"If TLS is used, stream compression MUST NOT be used and the receiving  
entity (typically a server) MUST NOT offer the stream compression feature  
after TLS is negotiated. Similarly, if stream compression is used, TLS  
MUST NOT be used and the receiving entity (typically a server) MUST NOT  
offer the TLS feature after stream compression is negotiated."

I assume this is done because TLS compression and zlib compression are  
very simulair. However in other cases, such as fast-infoset, (other)  
XML-aware compressors or more efficient character-based compressors, you  
might still want to use TLS security features (and in some cases even TLS  
compression). Is there a reason why this should be forbidden?

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

Is this a permanent situation? As XMPP will become more accepted and  
important is it possible that IANA will register stream features? (and  
perhaps some streamfeatures will be standerdized too, such as this one?)



More information about the Standards mailing list