[Members] Stream compression (JEP-138) and notification of failure or success

Gaston Dombiak gaston at jivesoftware.com
Wed Jan 11 10:12:32 CST 2006

Hey guys,

When implementing JEP-138: Stream compression my initially understanding
was that <compressed> was being sent by the server once he was able to
switch to compression mode and all validations have passed (e.g.
compression is available, compression is not already in use, etc.).
However, when testing against Pandion I found that Pandion was waiting
for the <compressed> notification to be sent before compression is

The reason for that is that the client was expecting a confirmation from
the server saying that there was no <failure> and that compression can
be established. And if a <failure> stanza was sent to the client then
the client will still be able to parse it since compression is still not
active. In other words, <compressed> is being used just like <proceed>
in TLS.

After chatting with Sebastiaan Deckers (author of Pandion) I decided to
change Wildfire implementation and follow the way Pandion was using it
since the explanation seemed logical to me. Moreover, Soapbox is also
following this idea. I wanted to test wildfire with Exodus in order to
confirm that exodus is also following this approach but until now I was
not able to obtain a binary version of Exodus that supports stream

Since we now have 2 servers and 1 confirmed client that are using
<compressed> as <proceed> in TLS, I was thinking that we might need to
make a few small changes to the JEP. We would need to change
<compressed> to <compress> and also make it more clear that <compress>
should be sent before compression is active and after all validations
have passed (i.e. no <failure>)

What do you think?


  -- Gato

More information about the Members mailing list