[Standards] certification etc.
stpeter at jabber.org
Thu Mar 29 01:24:11 UTC 2007
Robin Redeker wrote:
> On Tue, Mar 27, 2007 at 01:41:02PM -0700, Rachel Blackman wrote:
>>> Well stream compression isn't practical for some (otherwise
>>> intermediate-compliant) clients running in constrained
>>> environments. For example, Flash clients. So, if stream compression
>>> was added to the requirements, there would probably need to be an
>>> exception for constrained clients.
>> I think stream compression should only be a required element on the
>> server side, honestly, for the sake of clients that can't do
>> encryption and are bandwidth limited. Clients in general are better
>> off doing TLS where available, rather than doing compressed
>> unencrypted streams.
> Well, at least according to the RFC 3920 Clients which don't support
> TLS are already tapping into a gray area with regard to compliance.
> Will clients be compliant if they don't support SHOULDs from the
> RFC3920 (and RFC3921)?
Right. Unfortunately, it seems that some (many? most?) TLS
implementations do not support the compression option, so even if the
XMPP client and XMPP server support TLS, if their underlying TLS library
lacks support for compression there's not much they can do.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards