[Standards-JIG] Re: XMPP bandwidth compression
hildjj at gmail.com
Mon Jul 12 00:22:23 UTC 2004
> 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?
I'd be ok with saying that you can't use TLS compression and stream
compression at the same time, and if you use both, you MUST negotiate
TLS first, then negotiate compression, so that you compress, then
encrypt. The mutal exclusion was because getting the specification
for the layering right is going to be a little difficult.
> > 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?)
IANA will probably register stream features in the future. Actually,
IANA will register things that *don't* have an RFC, I believe. At
that point, we can move stream feature registration from the Jabber
Registrar to IANA.
More information about the Standards